product-concept

When this skill is invoked:

1. Parse Arguments & Check Track

Resolve the review mode (once, store for all gate spawns this run):

1. If --review [full|lean|solo] was passed → use that
2. Else read production/review-mode.txt → use that value
3. Else → default to lean

Confirm the track before writing anything. This skill produces a product concept. If PROJECT_TYPE is game, stop and route to /brainstorm instead — the two documents are not interchangeable and design/gdd/game-concept.md is what the game track's gates look for. If PROJECT_TYPE is unknown, ask which one the project is before proceeding.

If product/prd/product-concept.md already exists, do not overwrite. Read it, identify missing or placeholder sections, and offer to fill only those. Never touch section content that is already written.

2. Gather Context (Read Phase)

Read before asking the user anything:

• Stack pin: .claude/docs/technical-preferences.md — platform and framework constrain what the product can be. If missing, note it; the concept can be written first, but say so rather than assuming a stack.
• Existing PRDs: Glob product/prd/prd-*.md. On a project that grew feature PRDs before anyone wrote the concept, those PRDs are the evidence of what the product actually became. Read them and reconcile — do not invent a concept that contradicts shipped features.
• Prior exploration: any /brainstorm output or discovery notes the user points at.

3. Author Section by Section (Write Phase)

Walk the user through each section in order, one at a time: propose a draft from what you read, ask for corrections, then move on. Do not generate the whole document silently — this is the one document where a wrong assumption propagates into every downstream PRD.

Use AskUserQuestion for constrained choices (target segment, scope tier boundaries, monetization posture). Ask open questions as plain text so the user can answer freely.

Required sections:

1. One-line definition — what this is, in a sentence a stranger understands.
2. Problem & opportunity — whose problem, how they solve it today, why that is bad enough to change. A problem statement with no current alternative is a warning sign, not a green field: it usually means the problem is not felt.
3. Target users — primary segment first, with the situation they are in when they would reach for this. Secondary segments are explicitly secondary.
4. Value proposition & differentiation — what this does that the existing options do not. Name the alternatives, including "do nothing manually in a spreadsheet", which is the most common competitor and the most often ignored.
5. Core loop — the repeating user action that makes the product work. If the product has no repeat use, say so explicitly and state what replaces retention.
6. Scope tiers — MVP / next / later. The MVP tier is what you would ship if you had to ship in a third of the planned time.
7. Success metrics — how you will know it worked, and the threshold that would make you stop. Apply rules/claim-confidence.md § 3.1: at launch sample sizes, name raw counts, not ratios.
8. Risks & assumptions — the assumptions that, if wrong, invalidate the concept. Mark each as verified, estimated, or unverified per rules/claim-confidence.md.
9. Out of scope — what this product is deliberately not. A concept with no out-of-scope section has not made any decisions yet.

Any market size, competitor fact, pricing, or regulatory claim follows rules/claim-confidence.md: cite the source, or mark (추정) with the arithmetic, or [확인 필요]. Do not write these from memory. If the user can answer it faster than a search, ask the user.

4. Director Gate

See .claude/docs/director-gates.md for the full check pattern.

• full → spawn product-manager via Task to review the concept for internal consistency (does the core loop serve the stated problem, do the scope tiers hold the value proposition) before writing.
• lean / solo → skip. Note the skip in the output.

5. Write Approval

Use AskUserQuestion:

• Prompt: "Product concept is ready. May I write it to product/prd/product-concept.md?"
• Options: [A] Yes — write it / [B] Not yet — revise a section first

If [B]: ask which section using AskUserQuestion with the section names from § 3. Show the revised section as a clear before/after, then ask again. Repeat until the user selects [A].

On approval, write product/prd/product-concept.md, creating the directory if needed.

6. Report the Verdict

After writing, state one of these — the downstream skills and /gate-check architecture depend on knowing which:

• COMPLETE — all nine sections written, every claim either sourced or marked, no [확인 필요] blocking an MVP-tier decision. /create-prd can start.
• CONCERNS — written and usable, but list each [확인 필요] that a feature PRD will inherit. These are the assumptions that will propagate; name them here or they will surface as facts in three PRDs' time.
• BLOCKED — a decision only the user can make is missing (target segment, monetization posture, a regulatory question). Do not guess it to finish the document. Record it in production/human-actions.md per rules/work-records.md § 2 and stop.

7. Next Steps

List these in order:

1. "Pin the stack in .claude/docs/technical-preferences.md if it is not pinned yet — the product-track equivalent of /setup-engine"
2. "Write the first feature PRD with /create-prd <feature> — one per MVP-tier feature"
3. "Design the screens with /ux-design once the MVP features have PRDs"
4. "Validate readiness to advance with /gate-check architecture"

Relationship to Neighbouring Skills

/create-prd reads this document and fails without it. That was the gap this skill closes: the product track required the artifact and named no skill that wrote it.