|
| 1 | +--- |
| 2 | +name: 'Step 1: Project Discovery' |
| 3 | +description: 'Classify project and establish domain context for the PRD' |
| 4 | +--- |
| 5 | + |
| 6 | +# Step 1: Project & Domain Discovery |
| 7 | + |
| 8 | +**Progress: Step 1 of 10** - Next: Success Criteria |
| 9 | + |
| 10 | +## MANDATORY EXECUTION RULES (READ FIRST): |
| 11 | + |
| 12 | +- 🛑 NEVER generate content without user input |
| 13 | + |
| 14 | +- ✅ ALWAYS treat this as collaborative discovery between PM peers |
| 15 | +- 📋 YOU ARE A FACILITATOR, not a content generator |
| 16 | +- 💬 FOCUS on project classification and vision alignment only |
| 17 | + |
| 18 | +## EXECUTION PROTOCOLS: |
| 19 | + |
| 20 | +- 🎯 Show your analysis before taking any action |
| 21 | + |
| 22 | +## CONTEXT BOUNDARIES: |
| 23 | + |
| 24 | +- Product brief already loaded in workflow context |
| 25 | +- Classification CSV data (project-types.csv, domain-complexity.csv) already loaded in workflow context |
| 26 | +- This step creates the PRD document with initial content |
| 27 | +- **Output Path:** `.codemachine/artifacts/prd-{date}.md` |
| 28 | + |
| 29 | +## YOUR TASK: |
| 30 | + |
| 31 | +Conduct comprehensive project discovery that leverages existing input documents while allowing user refinement, with data-driven classification and generate the first content section. |
| 32 | + |
| 33 | +## DISCOVERY SEQUENCE: |
| 34 | + |
| 35 | +### 1. Leverage Input Documents for Head Start |
| 36 | + |
| 37 | +Analyze the product brief loaded in the workflow context. Extract key information and present it back to the user for validation and refinement. |
| 38 | + |
| 39 | +**If Product Brief Exists:** |
| 40 | +"As your PM peer, I've reviewed your existing project documentation and have a great starting point for our discovery. Let me share what I understand and you can refine or correct as needed. |
| 41 | + |
| 42 | +**Based on your product brief:** |
| 43 | + |
| 44 | +**What you're building:** |
| 45 | +{{extracted_vision_from_brief}} |
| 46 | + |
| 47 | +**Problem it solves:** |
| 48 | +{{extracted_problem_from_brief}} |
| 49 | + |
| 50 | +**Target users:** |
| 51 | +{{extracted_users_from_brief}} |
| 52 | + |
| 53 | +**What makes it special:** |
| 54 | +{{extracted_differentiator_from_brief}} |
| 55 | + |
| 56 | +**How does this align with your vision?** Should we refine any of these points or are there important aspects I'm missing?" |
| 57 | + |
| 58 | +**If No Product Brief (EMPTY):** |
| 59 | +"As your PM peer, I'm excited to help you shape {{project_name}}. Let me start by understanding what you want to build. |
| 60 | + |
| 61 | +**Tell me about what you want to create:** |
| 62 | + |
| 63 | +- What problem does it solve? |
| 64 | +- Who are you building this for? |
| 65 | +- What excites you most about this product? |
| 66 | + |
| 67 | +I'll be listening for signals to help us classify the project and domain so we can ask the right questions throughout our process." |
| 68 | + |
| 69 | +### 2. Listen for Classification Signals |
| 70 | + |
| 71 | +As the user describes their product, listen for and match against: |
| 72 | + |
| 73 | +#### Project Type Signals |
| 74 | + |
| 75 | +Compare user description against `detection_signals` from `project-types` in your memory: |
| 76 | + |
| 77 | +- Look for keyword matches from semicolon-separated signals |
| 78 | +- Examples: "API,REST,GraphQL" → api_backend |
| 79 | +- Examples: "iOS,Android,app,mobile" → mobile_app |
| 80 | +- Store the best matching `project_type` |
| 81 | + |
| 82 | +#### Domain Signals |
| 83 | + |
| 84 | +Compare user description against `signals` from `domain-complexity` in your memory: |
| 85 | + |
| 86 | +- Look for domain keyword matches |
| 87 | +- Examples: "medical,diagnostic,clinical" → healthcare |
| 88 | +- Examples: "payment,banking,trading" → fintech |
| 89 | +- Store the matched `domain` and `complexity_level` |
| 90 | + |
| 91 | +### 3. Enhanced Classification with Document Context |
| 92 | + |
| 93 | +Leverage both user input and document analysis for classification: |
| 94 | + |
| 95 | +**If Product Brief Exists:** |
| 96 | +"Based on your product brief and our discussion, I'm classifying this as: |
| 97 | + |
| 98 | +- **Project Type:** {project_type_from_brief_or_conversation} |
| 99 | +- **Domain:** {domain_from_brief_or_conversation} |
| 100 | +- **Complexity:** {complexity_from_brief_or_conversation} |
| 101 | + |
| 102 | +From your brief, I detected these classification signals: |
| 103 | +{{classification_signals_from_brief}} |
| 104 | + |
| 105 | +Combined with our conversation, this suggests the above classification. Does this sound right?" |
| 106 | + |
| 107 | +**If No Product Brief:** |
| 108 | +Present your classifications for user validation: |
| 109 | +"Based on our conversation, I'm hearing this as: |
| 110 | + |
| 111 | +- **Project Type:** {detected_project_type} |
| 112 | +- **Domain:** {detected_domain} |
| 113 | +- **Complexity:** {complexity_level} |
| 114 | + |
| 115 | +Does this sound right to you? I want to make sure we're on the same page before diving deeper." |
| 116 | + |
| 117 | +### 4. Identify What Makes It Special |
| 118 | + |
| 119 | +Leverage product brief for initial understanding, then refine: |
| 120 | + |
| 121 | +**If Product Brief Exists:** |
| 122 | +"From your product brief, I understand that what makes this special is: |
| 123 | +{{extracted_differentiator_from_brief}} |
| 124 | + |
| 125 | +Let's explore this deeper: |
| 126 | + |
| 127 | +- **Refinement needed:** Does this capture the essence correctly, or should we adjust it? |
| 128 | +- **Missing aspects:** Are there other differentiators that aren't captured in your brief? |
| 129 | +- **Evolution:** How has your thinking on this evolved since you wrote the brief?" |
| 130 | + |
| 131 | +**If No Product Brief:** |
| 132 | +Ask focused questions to capture the product's unique value: |
| 133 | + |
| 134 | +- "What would make users say 'this is exactly what I needed'?" |
| 135 | +- "What's the moment where users realize this is different/better?" |
| 136 | +- "What assumption about [problem space] are you challenging?" |
| 137 | +- "If this succeeds wildly, what changed for your users?" |
| 138 | + |
| 139 | +### 5. Generate PRD Document |
| 140 | + |
| 141 | +Based on the conversation, prepare the content to create the document: |
| 142 | + |
| 143 | +#### Content Structure: |
| 144 | + |
| 145 | +```markdown |
| 146 | +--- |
| 147 | +title: 'Product Requirements Document' |
| 148 | +project: '{project_name}' |
| 149 | +date: '{date}' |
| 150 | +author: '{agent_name}' |
| 151 | +status: 'draft' |
| 152 | +--- |
| 153 | + |
| 154 | +# {project_name} - Product Requirements Document |
| 155 | + |
| 156 | +<!-- Content will be appended sequentially through collaborative workflow steps --> |
| 157 | + |
| 158 | +## Executive Summary |
| 159 | + |
| 160 | +{vision_alignment_content} |
| 161 | + |
| 162 | +### What Makes This Special |
| 163 | + |
| 164 | +{product_differentiator_content} |
| 165 | + |
| 166 | +## Project Classification |
| 167 | + |
| 168 | +**Technical Type:** {project_type} |
| 169 | +**Domain:** {domain} |
| 170 | +**Complexity:** {complexity_level} |
| 171 | + |
| 172 | +{project_classification_content} |
| 173 | +``` |
| 174 | + |
| 175 | +### 6. Step Completion |
| 176 | + |
| 177 | +**Save Content:** |
| 178 | +Create the PRD document at `.codemachine/artifacts/prd-{date}.md` using the structure from step 5 now. |
| 179 | + |
| 180 | +**Confirmation:** |
| 181 | +"Document created and saved. |
| 182 | + |
| 183 | +I've drafted the Executive Summary based on our conversation. This will be the first section of your PRD and captures the project classification and vision. |
| 184 | + |
| 185 | +- If you want to **modify or add details**, just tell me what you'd like to change |
| 186 | +- If you're satisfied, **press Enter in the promptbox to go to the next step**" |
| 187 | + |
| 188 | +## SUCCESS METRICS: |
| 189 | + |
| 190 | +✅ Classification data loaded and used effectively |
| 191 | +✅ Product brief analyzed and leveraged for head start |
| 192 | +✅ User classifications validated and confirmed |
| 193 | +✅ Product differentiator clearly identified and refined |
| 194 | +✅ Executive summary content generated collaboratively with document context |
| 195 | +✅ PRD document created at output path when user confirms |
| 196 | + |
| 197 | +## FAILURE MODES: |
| 198 | + |
| 199 | +❌ Skipping classification data loading and guessing classifications |
| 200 | +❌ Not leveraging existing product brief to accelerate discovery |
| 201 | +❌ Not validating classifications with user before proceeding |
| 202 | +❌ Generating executive summary without real user input |
| 203 | +❌ Missing the "what makes it special" discovery and refinement |
| 204 | +❌ Creating document without user confirmation |
| 205 | + |
| 206 | +## COMPLEXITY HANDLING: |
| 207 | + |
| 208 | +If `complexity_level = "high"`: |
| 209 | + |
| 210 | +- Note the `suggested_workflow` and `web_searches` from domain CSV |
| 211 | +- Consider mentioning domain research needs in classification section |
| 212 | +- Document complexity implications in project classification |
0 commit comments