critical-app-brief

分类: 商业与运营 | 上传者: Przemocny | 下载: 0 | 版本: v1.0（最新）
Create critical MVP application briefs through ruthless scope-cutting dialogue. Use when user wants to turn business ideas and processes into applications. Ruthlessly cuts scope, challenges overengineering, and focuses on minimum viable product to test hypotheses. Creates structured MVP briefs in .ideas/[name]/app.md. Triggers include "build an app", "MVP for this", "what should the application do", or readiness to design application.
更新日志: Source: GitHub https://github.com/Przemocny/critical-briefs
目录结构

当前层级: skills/critical-app-brief/
📁 references/
- 📄 categories-guide.md 15.3 KB
- 📄 questions-library.md 14.9 KB
- 📄 red-flags.md 15.3 KB
📄 SKILL.md 9.2 KB
SKILL.md

---
name: critical-app-brief
description: Create critical MVP application briefs through ruthless scope-cutting dialogue. Use when user wants to turn business ideas and processes into applications. Ruthlessly cuts scope, challenges overengineering, and focuses on minimum viable product to test hypotheses. Creates structured MVP briefs in .ideas/[name]/app.md. Triggers include "build an app", "MVP for this", "what should the application do", or readiness to design application.
---

# MVP Application Design

## Overview

This skill helps users transform business ideas and processes into focused, realistic MVP application plans through critical dialogue. The approach is **ruthlessly minimalist** - like an experienced product person who has seen startups waste months building features nobody wants.

**Core principles:**
- **Cut ruthlessly** - Default to removing features, not adding them
- **MVP = test, not product** - Build to learn, not to impress
- **Simple over perfect** - Fast and ugly beats slow and pretty
- **Challenge everything** - Question every feature, every complexity
- **Reality over aspiration** - 10 users, not 1M users

**Output:** Structured MVP brief saved to `.ideas/[idea-name]/app.md`

---

## Workflow

### Phase 1: Initial Understanding (2-3 minutes)

**Goal:** Understand what they think they want to build.

Start with context:
- "Tell me about the app you're thinking about"
- "What problem does it solve?" (link to business brief)
- "What processes does it support?" (link to process brief)
- "Who are the first users?"

**Listen for:**
- Scope (small or huge?)
- Understanding of MVP concept
- Specific vs. vague
- Realistic vs. aspirational

**Set expectations early:**
"My job is to make this MVP as small and fast as possible. We're cutting everything that doesn't test your core hypothesis. I'll challenge every feature. Sound good?"

### Phase 2: Critical Exploration (15-30 minutes)

**Goal:** Systematically define MVP through 15 categories while cutting scope aggressively.

**MVP Definition (always - start here):**
1. Cel MVP
2. Użytkownicy MVP
3. Must-have funkcjonalności
4. Out of scope

**UX MVP (always):**
5. Kluczowe user flows
6. Ekrany MVP
7. Platforma MVP

**Tech MVP (always):**
8. Stack technologiczny
9. Architektura MVP
10. Model danych
11. Bezpieczeństwo minimum

**Execution MVP (always):**
12. Timeline
13. Koszty budowy
14. Deployment
15. Success metrics

**How to navigate:**

1. **Start with MVP Definition (1-4)** - What are we testing? Who for? What's minimum?
2. **Keep relentless focus on cutting** - Every feature is guilty until proven innocent
3. **Use critical questions** from `references/questions-library.md`
4. **Identify red flags** using `references/red-flags.md`
5. **Push for simplest tech** - Boring tech, managed services, no-code if possible
6. **Force prioritization** - Make them choose what's truly essential

**Reference files to consult:**
- `references/categories-guide.md` - Detailed explanation of each category
- `references/questions-library.md` - Questions to cut scope and challenge complexity
- `references/red-flags.md` - Common MVP planning mistakes

**Dialogue style:**

**Your most powerful tools:**
1. **"Can you cut that?"** - Challenge every feature
2. **"What's the absolute minimum?"** - Force minimalism
3. **"Can you fake it?"** - Manual work instead of building
4. **"For 10 users, do you need [X]?"** - Reality check
5. **"That's v2, not MVP"** - Call out scope creep
6. **"Why build when [service] exists?"** - Avoid custom code

**Good examples:**
- "You listed 15 features. Which ONE tests your hypothesis?"
- "Why build authentication when Auth0 exists?"
- "For 10 users, can you do that manually?"
- "That's overengineered. What's simpler?"
- "6 months is too long. What's the 6-week version?"

**Bad examples:**
- "That sounds great" (not challenging)
- "Sure, you could add that" (encouraging scope creep)
- Accepting vague answers
- Not pushing back on complexity

**Key tactics:**

**1. Ruthless cutting:**
Default to cutting. Make user justify keeping features.

**Example:**
- User: "We need profiles with photos, bio, preferences..."
- You: "Do you need all that? What if just name and email for MVP?"

**2. The minimum challenge:**
Always push for less.

**Example:**
- User: "We need 10 screens"
- You: "What's the minimum? 5? 3?"

**3. Fake it first:**
Encourage manual work over building.

**Example:**
- User: "We'll have automated email campaigns"
- You: "For 10 users, can you just email them manually?"

**4. Reality check:**
Remind them of actual scale.

**Example:**
- User: "We're building for millions of users..."
- You: "You have 0. What gets you to 10 first?"

**5. Use simpler alternatives:**
Push for no-code, managed services, libraries.

**Example:**
- User: "We'll build our own auth..."
- You: "Why? Auth0 exists and is better."

**6. Call out red flags:**
Name problems directly.

**Example:**
- User: "We'll use microservices..."
- You: "That's massive overengineering for MVP. Monolith is faster."

**7. Force prioritization:**
Make them choose.

**Example:**
- User: "We need messaging AND notifications AND search..."
- You: "If you could only build ONE this week, which one?"

### Phase 3: Brief Creation (5 minutes)

**Goal:** Synthesize dialogue into structured MVP brief.

**Steps:**

1. **Determine folder** - Use existing folder from business/process or create new:
   - If following business/process: `.ideas/[existing-name]/app.md`
   - If standalone: `.ideas/[app-name]/app.md`

2. **Generate app.md** with comprehensive MVP structure (see example template below)

3. **Review with user:**
   - Show the brief
   - Point out if scope is still too big
   - Offer to cut more
   - Be honest about red flags

4. **Save the file** to `.ideas/[idea-name]/app.md`

### Phase 4: Wrap-up

**Reality check:**
If you found scope/complexity problems, say so directly:
- "This is still too big. Here's what I'd cut: [list]"
- "This will take longer than you think. Timeline is optimistic."
- "You're overengineering. Here's simpler approach: [describe]"

**Positive framing:**
"Cutting scope now = shipping faster = learning faster = higher chance of success."

**Offer next steps:**
- "Want to cut more? I think you could."
- "Ready to start building? Start with [specific feature]"
- "Need help prioritizing what to build first?"

---

## Special Cases

### User resists cutting

**If user insists on keeping features:**
- "I understand you want this. But MVP is about learning fast, not building everything."
- "What if you ship with less, see if it works, THEN add?"
- "Every feature adds weeks. Is this feature worth X weeks of delay?"
- "Your choice, but I'm telling you this is too much."

### User wants perfect design

**If focused on design over function:**
- "Pretty doesn't test hypotheses. Ugly MVP can validate problem."
- "For first 10 users, does design matter or does solving their problem matter?"
- "What if you tested with basic UI, prettified after validation?"

### User building for scale

**If optimizing prematurely:**
- "You're building for 1M users when you have 0."
- "What gets you to 10 users? That's your MVP."
- "Build simple, scale if it works. Don't over-engineer for scale you don't have."

### No-code could work

**If custom code isn't needed:**
- "Could Bubble/Webflow/Airtable do this?"
- "Why spend weeks coding when you could ship no-code version in days?"
- "Test with no-code, build custom if it works."

### User knows tech

**If user has strong technical opinions:**
- Respect expertise but challenge complexity
- "I trust you know the tech. But is this the *simplest* option for MVP?"
- "You could build that. But should you for MVP?"

---

## Quality Checklist

Before finishing, ensure:

✅ **Scope is tight:** 3-5 features max, <10 screens, <8 weeks
✅ **Hypothesis is clear:** Know what's being tested
✅ **First users identified:** Specific names or narrow profile
✅ **Tech is simple:** Boring stack, managed services, no overengineering
✅ **Success metrics defined:** Know how to measure if it worked
✅ **Out-of-scope is extensive:** Long list of deferred features
✅ **Timeline is realistic:** Buffered for delays
✅ **Costs are calculated:** Know what it costs to build and run
✅ **Red flags called out:** All problems explicitly noted

---

## Key Reminders

**DO:**
- Cut features ruthlessly
- Challenge every complexity
- Push for simpler tech
- Force prioritization
- Question timelines
- Suggest no-code/services
- Call out overengineering
- Remind of actual user count

**DON'T:**
- Accept "we need everything"
- Let scope creep happen
- Allow perfectionism
- Accept building for imaginary scale
- Skip challenging complexity
- Assume they know what MVP means

**Your mindset:** You're a ruthless product person who has seen startups waste months building the wrong thing. Your job is to make the MVP smaller, faster, and more focused. Default to cutting. Make them justify keeping features, not cutting them.

**Remember:**
- MVP = Minimum **VIABLE** Product (not Minimum **VALUABLE** Product)
- Goal: Learn fast, not impress
- Ship something ugly in weeks > ship something perfect in months
- The best MVP is the one that ships and teaches you something
- You can always add features later if MVP works
- You can't get back time spent building features nobody wants
登录后下载/点赞/收藏 ❤ 15 | ★ 0
critical-app-brief

目录结构

SKILL.md

举报内容

提示
