cy-create-prd

name	cy-create-prd
description	Creates a Product Requirements Document through interactive brainstorming with parallel codebase and web research. Use when starting a new feature or product, building a PRD, or brainstorming requirements. Do not use for technical specifications, task breakdowns, or code implementation.
argument-hint	[feature-name-or-idea] [idea-file]

Create PRD

Create a business-focused Product Requirements Document through structured brainstorming.

Do NOT write the PRD file until ALL phases are complete and the user has approved the final draft. Do NOT skip the research phase — every PRD MUST be enriched with codebase and market context. Do NOT skip user interactions — the user MUST participate in shaping the PRD at every decision point. Do NOT require section-by-section approval — generate the complete draft, then let the user review it. This applies to EVERY PRD regardless of perceived simplicity.

Asking Questions

When this skill instructs you to ask the user a question, you MUST use your runtime's dedicated interactive question tool — the tool or function that presents a question to the user and pauses execution until the user responds. Do not output questions as plain assistant text and continue generating; always use the mechanism that blocks until the user has answered.

If your runtime does not provide such a tool, present the question as your complete message and stop generating. Do not answer your own question or proceed without user input.

Anti-Pattern: "This Feature Is Too Simple For Full Brainstorming"

Every PRD goes through the full brainstorming process. A single button, a minor workflow tweak, a configuration option — all of them. "Simple" features are where unexamined business assumptions cause the most rework. The brainstorming can be brief for genuinely simple features, but you MUST ask clarifying questions and get approval on the product approach before writing the artifact.

Anti-Pattern: End-Of-Flow Bureaucracy

Once the user has answered the clarifying questions and approved an approach, do not force them through a second approval loop for Overview, Goals, User Stories, or any other final document section. Synthesize the approved direction into the PRD directly. The user can review and request edits in the generated file afterward.

Anti-Pattern: Technical Drift On Technical-Sounding Features

When the feature name sounds technical (e.g., "webhook notifications", "CSV export", "dark mode", "API rate limiting"), you will be tempted to discuss HOW to implement it. Resist this. Your job is the WHAT and WHY:

• WRONG: "Should we use WebSockets or polling for notifications?" (implementation)
• WRONG: "What CSV library format should we target?" (implementation)
• RIGHT: "Which events should trigger a notification to the user?" (user need)
• RIGHT: "What information do users need in their exported reports?" (user need)

Translate every technical-sounding feature into the user experience question behind it.

Required Inputs

• Feature name or product idea.
• Optional: existing _idea.md file as primary input for context.
• Optional: existing _prd.md file for update mode.

Checklist

You MUST create a task for each phase and complete them in order:

1. Determine project & directory — derive slug, create .compozy/tasks/<slug>/ and adrs/
2. Discover context — parallel codebase exploration and web research
3. Understand the need — ask 3-6 targeted questions to refine scope and intent
4. Present product approaches — offer 2-3 approaches with trade-offs, create ADR for the chosen one
5. Draft the PRD — write using the canonical template from references/prd-template.md
6. Review with user — present the draft, iterate until approved
7. Save the file — write to .compozy/tasks/<slug>/_prd.md

Workflow

1. Determine the project name and working directory.

   • Derive the slug from the feature name provided by the user.
   • Use .compozy/tasks/<slug>/ as the target directory.
   • If _idea.md exists in the target directory, read it as primary context input.
   • If _prd.md already exists in the target directory, read it and operate in update mode.
   • If the directory does not exist, create it.
   • Create .compozy/tasks/<slug>/adrs/ directory if it does not exist.

2. Discover context through parallel research. You MUST perform BOTH tracks before asking any questions.

   Track A — Codebase exploration (REQUIRED):

   • Search the codebase for files, patterns, and features related to the user's request.
   • Look for existing implementations, data models, and integration points that are relevant.
   • Summarize what you found in 3-5 bullet points.

   Track B — Market and user research (REQUIRED):

   • Perform 3-5 web searches for market trends, competitive products, and user needs related to the feature.
   • Look for how similar products solve this problem and what users expect.
   • Summarize what you found in 3-5 bullet points.

   Run both tracks in parallel (e.g., two Agent tool calls, two search batches, etc.). Present a brief merged summary of findings from BOTH tracks to the user before moving to questions. If web search tools are unavailable, note the limitation explicitly and proceed with codebase findings only.

3. Ask clarifying questions following references/question-protocol.md.

   • Focus exclusively on WHAT features users need, WHY it provides business value, and WHO the target users are.

   • Ask about success criteria and constraints.

   • Never ask technical implementation questions about databases, APIs, frameworks, or architecture.

   • ONE question per message — strictly enforced. Your message must contain exactly one question mark. After asking the question, STOP. Do not add follow-up questions, "also" questions, or "additionally" prompts. If a topic needs more exploration, ask a follow-up in the NEXT message after the user responds.

     Anti-pattern (FORBIDDEN): "What is the primary user persona? Also, what are the key success metrics?" This is TWO questions. Split them into two separate messages.

   • Every question MUST be multiple-choice when reasonable options can be predetermined. Format as labeled options (A, B, C, etc.) so the user can respond with a single letter. Only use open-ended questions when the answer space is genuinely unbounded (e.g., "What problem are you trying to solve?").

Process Flow

digraph create_prd {
    "Determine project & directory" [shape=box];
    "Discover context (codebase + web)" [shape=box];
    "Ask clarifying questions (one at a time)" [shape=box];
    "Present 2-3 product approaches" [shape=box];
    "User selects approach?" [shape=diamond];
    "Create ADR for approach decision" [shape=box];
    "Draft PRD (canonical template)" [shape=box];
    "User approves draft?" [shape=diamond];
    "Save _prd.md" [shape=doublecircle];

    "Determine project & directory" -> "Discover context (codebase + web)";
    "Discover context (codebase + web)" -> "Ask clarifying questions (one at a time)";
    "Ask clarifying questions (one at a time)" -> "Present 2-3 product approaches";
    "Present 2-3 product approaches" -> "User selects approach?";
    "User selects approach?" -> "Present 2-3 product approaches" [label="no, revise"];
    "User selects approach?" -> "Create ADR for approach decision" [label="yes"];
    "Create ADR for approach decision" -> "Draft PRD (canonical template)";
    "Draft PRD (canonical template)" -> "User approves draft?";
    "User approves draft?" -> "Draft PRD (canonical template)" [label="no, revise"];
    "User approves draft?" -> "Save _prd.md" [label="approved"];
}

Error Handling

• If the user provides insufficient context to complete a section, note it in the Open Questions section rather than guessing.
• If web research tools are unavailable, proceed with codebase exploration only and note the limitation.
• If the target directory cannot be created, stop and report the filesystem error.
• If operating in update mode, preserve sections the user has not asked to change.

Key Principles

• One question at a time — Do not overwhelm with multiple questions in a single message
• Multiple choice mandatory — Every question MUST be multiple-choice (A/B/C) when options can be predetermined; open-ended only when the answer space is genuinely unbounded
• YAGNI ruthlessly — Challenge every feature; remove anything the MVP does not need
• Draft then review — Get approval on the product approach, generate the complete draft, then iterate with the user until approved
• Business focus only — Never ask about implementation; that belongs in TechSpec
• Idea as input — When _idea.md exists, use it as primary context to accelerate brainstorming
• Pipeline awareness — The PRD feeds into cy-create-techspec; focus on WHAT and WHY, not HOW
• Template compliance — Every PRD MUST follow the canonical template
• Language consistency — Write all PRD content in English