Cy Create Prd

Create PRD

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

<HARD-GATE> 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. </HARD-GATE>

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?").
• Include a fallback option (e.g., "D) Other — describe") for flexibility.
• For complex features with many dimensions, decompose into sub-topics and ask about one dimension at a time. Each sub-topic usually has predeterminable options. Example: instead of the open-ended "What should the collaboration feature include?", ask "Which aspect of team collaboration is most important to start with? A) Shared workspaces B) Real-time presence C) Permission controls D) Activity feeds".
• Complete at least one full clarification round before presenting approaches.

4. Present product approaches.

• Offer 2-3 product approaches with trade-offs for each.
• Lead with the recommended approach and explain why it is preferred.
• Wait for the user to select an approach before continuing.
• After the user selects an approach, create an ADR for this decision:
• Read references/adr-template.md.
• Determine the next ADR number by listing existing files in .compozy/tasks/<slug>/adrs/.
• Fill the template: the selected approach as "Decision", rejected approaches as "Alternatives Considered" with their trade-offs, and outcomes as "Consequences". Set Status to "Accepted" and Date to today.
• Write the ADR to .compozy/tasks/<slug>/adrs/adr-NNN.md (zero-padded 3-digit number, e.g., adr-001.md).

5. Draft the PRD.

• After the user selects an approach, synthesize the final product design. Do not present each section for separate approval.
• If the user makes a significant scope decision during clarification or approach selection, create an additional ADR following the same process as step 4.
• Only pause before writing if a blocking ambiguity remains that would force guessing; otherwise proceed directly to document generation.
• Read references/prd-template.md and fill every section with gathered context.
• Include an "Architecture Decision Records" section listing all ADRs created during this session with their numbers, titles, and one-line summaries as links to the adrs/ directory.
• Apply YAGNI ruthlessly: challenge every feature and remove anything the MVP does not need.
• The PRD must describe user capabilities and business outcomes only.
• No databases, APIs, code structure, frameworks, testing strategies, or architecture decisions.
• Mandatory sections (ALWAYS include): Overview, Goals, User Stories, Core Features, User Experience, Non-Goals, Phased Rollout Plan, Success Metrics, Risks and Mitigations, Architecture Decision Records, Open Questions.
• Optional sections (include when relevant): High-Level Technical Constraints.
• Prefer active voice, omit needless words, use definite and specific language over vague generalities. Every sentence should earn its place.
• Language: English. Tone: clear, technical, consistent with existing project artifacts.
• Present the complete draft to the user for review.

6. Review with the user.

• Present the draft and ask using the interactive question tool:
• "Here is the PRD draft. Please review and let me know:"
• A) Approved — save as is
• B) Adjust specific sections (tell me which ones)
• C) Rewrite section X (tell me what to change)
• D) Discard and start over
• If B or C: make the changes and present again.
• If D: go back to step 3.

7. Save the PRD file.

• Write the completed document to .compozy/tasks/<slug>/_prd.md.
• Confirm the file path to the user.
• Remind the user that the next step is to create a TechSpec using cy-create-techspec from this PRD.

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

ADR-XXX: [Title]

Status

[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]

Date

YYYY-MM-DD

Context

[Describe the issue or problem that motivates this decision. Include relevant technical context, constraints, and any forces at play.]

Decision

[State the decision that was made. Be specific and clear about what will be done.]

Alternatives Considered

Alternative 1: [Name]

• Description: [Brief description]
• Pros: [List advantages]
• Cons: [List disadvantages]
• Why rejected: [Reason]

Alternative 2: [Name]

• Description: [Brief description]
• Pros: [List advantages]
• Cons: [List disadvantages]
• Why rejected: [Reason]

Consequences

Positive

• [List positive outcomes]

Negative

• [List negative outcomes or trade-offs]

Risks

• [List risks and mitigation strategies]

Implementation Notes

[Any specific implementation details, migration steps, or technical notes relevant to this decision.]

References

• [Link to relevant documents, PRDs, tech specs, or external resources]

PRD Template

Use this template to structure every Product Requirements Document. Fill each section based on brainstorming outcomes. Leave placeholder guidance in sections where information is insufficient and note them in Open Questions.

Overview

High-level overview of the feature or product. Describe:

• What problem it solves
• Who it is for
• Why it is valuable

Goals

Specific, measurable objectives for this feature or product:

• Success metrics and key performance indicators
• Business objectives and expected outcomes
• Target timelines or milestones

User Stories

User stories organized by persona:

• As a [type of user], I want [action] so that [benefit]
• Primary personas and their main flows
• Secondary personas and edge cases

Core Features

Main features grouped by priority:

• Feature name: what it does, why it is important, high-level behavior
• Functional requirements for each feature
• Interaction between features

User Experience

User journey from first contact to regular use:

• Key personas and their goals
• Primary user flows step by step
• UI/UX considerations and accessibility requirements
• Onboarding and discoverability

High-Level Technical Constraints

Required boundaries that shape the product without prescribing implementation:

• Required integrations with existing systems
• Compliance mandates or regulatory requirements
• Performance targets from a user perspective
• Data privacy and security requirements

Do NOT include implementation details such as specific databases, frameworks, API designs, or architecture patterns.

Non-Goals (Out of Scope)

Explicitly excluded features and boundaries:

• Features intentionally deferred to future phases
• Adjacent problems that will not be addressed
• Boundaries of this effort

Phased Rollout Plan

Incremental delivery plan with success criteria per phase:

MVP (Phase 1)

• Core features included
• Success criteria to proceed to Phase 2

Phase 2

• Additional features
• Success criteria to proceed to Phase 3

Phase 3

• Full feature set
• Long-term success criteria

Success Metrics

Quantifiable measures of success:

• User engagement metrics
• Performance benchmarks from a user perspective
• Business impact indicators
• Quality attributes

Risks and Mitigations

Non-technical risks that could affect the product:

• Adoption risks and mitigation strategies
• Competitive risks
• Timeline and resource constraints
• Dependency risks on external factors

Do NOT include technical risks such as architectural complexity or technical debt.

Architecture Decision Records

ADRs documenting key decisions made during brainstorming:

• ADR-NNN: Title — One-line summary of the decision

Open Questions

Remaining items that need clarification:

• Unclear requirements
• Edge cases requiring stakeholder input
• Dependencies on decisions not yet made

Question Protocol

Structured brainstorming protocol for PRD creation. Follow these phases and rules to guide the conversation from idea to document.

Phases

1. Discovery

Gather initial context about the idea or problem space.

• What is the core problem or opportunity?
• Who are the affected users?
• What prompted this initiative?

2. Understanding

Deepen knowledge of requirements and constraints.

• WHAT specific features do users need?
• WHY does this provide business value?
• WHO are the target users and what are their current workflows?
• What are the success criteria?
• What are the known constraints (timeline, budget, compliance)?

3. Options

Present product approaches for the user to evaluate.

• Offer 2-3 distinct approaches with clear trade-offs.
• Lead with the recommended approach and explain why.
• Each approach should differ meaningfully in scope, phasing, or strategy.
• Wait for the user to select before proceeding.

4. Refinement

Refine the selected approach with targeted follow-ups.

• Clarify scope boundaries for the chosen approach.
• Confirm phasing and priority of features.
• Validate success criteria and metrics.
• Resolve any remaining open questions.

4b. Incremental Design Validation

Present the product design section by section for user approval.

• Scale each section to its complexity: brief for straightforward topics, detailed for nuanced ones.
• Present one section at a time; ask whether it looks right before moving on.
• Apply YAGNI: challenge every feature against MVP necessity.
• Be ready to revise any section before proceeding to the next.

5. Creation

Generate the PRD document using the gathered context.

• Read and fill the PRD template.
• Every section should reflect confirmed decisions.
• Unresolved items go into Open Questions.

Rules

Interactive Question Enforcement

• Every question MUST be asked using the runtime's dedicated interactive question tool — the one that presents the question and pauses execution until the user responds.
• Do not output questions as plain text and continue generating.
• If no such tool is available, present the question as your complete message and stop generating.

Question Limits

• Ask only one question per message. If a topic needs deeper exploration, break it into a sequence of individual questions.
• Prefer multiple-choice questions when the options can be predetermined.
• Wait for the user's answer before asking the next question.

Progression Gates

• Must complete at least one full Understanding round before presenting Options.
• Must have clarity on purpose, constraints, and success criteria before presenting approaches.
• Must have user approval of an approach before entering Refinement.

Focus Boundaries

• Questions must focus on WHAT, WHY, and WHO.
• Never ask HOW, WHERE, or WHICH regarding technical implementation.
• Forbidden topics: databases, APIs, code structure, frameworks, testing strategies, architecture patterns, deployment infrastructure.

YAGNI Principle

• Ruthlessly remove non-essential features during refinement.
• Challenge every feature: does the MVP need this?
• Defer nice-to-have features to later phases.
• Prefer smaller, well-defined scope over ambitious breadth.

Anti-Pattern: Skipping Brainstorming For "Simple" Features

Every PRD goes through the full question protocol regardless of perceived simplicity. Simple features are where unexamined business assumptions cause the most rework. The brainstorming can be brief, but it must happen.