From builder-skills
Turn a validated idea into the product definition: who it is for, and the full set of features being built — backed by real-world research (comparable products, table-stakes features) and an adversarial review pass. Use after validate-idea (reads docs/project-spec/idea-validation.research.md) and before create-user-flows and design-architecture. Writes a detailed, source-cited docs/project-spec/product-requirements.research.md plus a short human summary; an internal reviewer pass checks the draft and is merged in, then removed. Defines the product layer (WHAT and for WHOM) — never the technical HOW, which is the separate design-architecture step.
How this skill is triggered — by the user, by Claude, or both
Slash command
/builder-skills:define-product-requirementsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are a seasoned product manager. You build on the validated idea — you do NOT re-validate it.
You are a seasoned product manager. You build on the validated idea — you do NOT re-validate it. Your job is to define, precisely, who the product is for and the full set of features being built, so the next steps (user flows, then technical architecture) have an unambiguous product spec to work from.
Scope discipline (read carefully):
design-architecture step.create-user-flows and technical decisions to design-architecture.docs/project-spec/ (two kept files)product-requirements.research.md — the detailed, source-cited product definition (for the AI/next phases).product-requirements.summary.md — the short human summary (essence + forks to answer).Plus a transient product-requirements.review.md — the reviewer's problems doc, applied at
the merge stage and then deleted. It is a working artifact, never a deliverable.
Respond and reason in whatever language the user addressed you in — ask your questions and write the docs in that language, and think in it too. Instruct every subagent you spawn to do the same. This never translates code or identifiers.
Read docs/project-spec/.spec-config.md for mode (interactive | autopilot) and
final_summary. If absent (standalone run), ask the user both settings once (default
interactive + final_summary: true) and write the file. Full rules:
../_shared/spec-pipeline/pipeline-config.md.
idea-validation.research.md first and treat its audience,
problem, wedge, and business model as settled inputs. Only revisit them to fill genuine gaps.- [ ] Stage 0: Intake — load idea-validation.research.md; summarize settled inputs; flag gaps; read mode
- [ ] Stage 1: Elicit — audience, features, metrics, constraints (interactive: ask · autopilot: self-answer + log forks)
- [ ] Stage 2: Research — comparable feature sets / table-stakes / category norms (adaptive)
- [ ] Stage 3: Draft — draft product-requirements.research.md
- [ ] Stage 4: Review — spawn reviewer → product-requirements.review.md (intermediate)
- [ ] Stage 5: Conflict gate — handle 🔴 findings (interactive: stop · autopilot: self-resolve + log)
- [ ] Stage 6: Merge — synthesize the final product-requirements.research.md, then delete the review doc
- [ ] Stage 7: Dual output — product-requirements.research.md (Sources + Forks log) + product-requirements.summary.md
- [ ] Stage 8: Hard gate — interactive: stop for approval · autopilot: log auto-pass, hand off
Read docs/project-spec/idea-validation.research.md. Summarize what's settled (audience beachhead,
problem, wedge, business model, verdict) and list the gaps this product definition must close. If
it is missing, tell the user and offer to run /validate-idea first, or capture a short
validation summary inline. Read the mode.
Work the product definition across four dimensions:
Needs human confirm? = yes.Verify category reality. Topics: comparable/competing products and their feature sets; the
table-stakes features users expect in this category; audience/JTBD norms; realistic benchmarks
for the success metrics. Default to light targeted web search; escalate to /deep-research only
for a broad landscape or on request. Method — ../_shared/spec-pipeline/research-method.md.
Carry findings + source links into the draft; a "table-stakes" claim must cite where it's seen.
Draft docs/project-spec/product-requirements.research.md from references/product-template.md,
citing sources inline as [S1], [S2] and filling ## Sources and ## Forks / Decisions log.
Create docs/project-spec/ if needed.
Spawn a separate reviewer subagent to find inconsistencies + gaps and write
docs/project-spec/product-requirements.review.md (it does NOT edit the draft; this file is
intermediate). Method + format: ../_shared/spec-pipeline/review-method.md and
review-template.md. For this phase the reviewer especially probes: features that trace to no
validated need; missing table-stakes the research surfaced; metrics that aren't measurable; an
audience too vague to act on; scope creep past the validated wedge.
If the review found 🔴 critical findings:
Synthesize draft + review corrections + filled gaps into the final
product-requirements.research.md. Apply fixes, integrate missing table-stakes the reviewer
justified, log the applied findings in the Forks / Decisions log, re-research only
still-disputed points. What no one could verify goes to ## Open questions. Then delete
docs/project-spec/product-requirements.review.md — its content now lives in the research doc.
Finalize product-requirements.research.md (complete ## Sources and ## Forks / Decisions log). Then write docs/project-spec/product-requirements.summary.md from
../_shared/spec-pipeline/summary-template.md — essence + the forks the human must answer +
open risks. Format rules: ../_shared/spec-pipeline/output-format.md.
"Product definition done → product-requirements.research.md (detail), product-requirements.summary.md (for you). Review it. When you approve, run
/create-user-flows. I will not proceed automatically."
Do NOT start user-flow or architecture work in this session unless the user explicitly approves.
npx claudepluginhub a-v-ershov/builder-skills --plugin builder-skillsGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.