@devobsessed/code-captain 0.0.8 β 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +35 -27
- package/bin/install.js +1165 -978
- package/claude-code/agents/code-captain.md +15 -3
- package/copilot/chatmodes/Code Captain.chatmode.md +30 -9
- package/copilot/prompts/create-adr.prompt.md +6 -4
- package/copilot/prompts/create-spec.prompt.md +60 -40
- package/copilot/prompts/explain-code.prompt.md +7 -20
- package/copilot/prompts/research.prompt.md +14 -27
- package/cursor/README.md +72 -68
- package/cursor/cc.mdc +54 -31
- package/cursor/commands/create-adr.md +6 -12
- package/cursor/commands/create-spec.md +66 -54
- package/cursor/commands/edit-spec.md +2 -15
- package/cursor/commands/execute-task.md +7 -15
- package/cursor/commands/explain-code.md +16 -32
- package/cursor/commands/initialize.md +18 -17
- package/cursor/commands/new-command.md +168 -77
- package/cursor/commands/plan-product.md +7 -13
- package/cursor/commands/research.md +4 -23
- package/cursor/commands/status.md +28 -28
- package/cursor/commands/swab.md +4 -12
- package/manifest.json +104 -207
- package/package.json +2 -3
- package/cursor/cc.md +0 -156
- package/windsurf/README.md +0 -254
- package/windsurf/rules/cc.md +0 -5
- package/windsurf/workflows/create-adr.md +0 -331
- package/windsurf/workflows/create-spec.md +0 -280
- package/windsurf/workflows/edit-spec.md +0 -273
- package/windsurf/workflows/execute-task.md +0 -276
- package/windsurf/workflows/explain-code.md +0 -288
- package/windsurf/workflows/initialize.md +0 -298
- package/windsurf/workflows/new-command.md +0 -321
- package/windsurf/workflows/plan-product.md +0 -330
- package/windsurf/workflows/research.md +0 -240
- package/windsurf/workflows/status.md +0 -213
- package/windsurf/workflows/swab.md +0 -212
|
@@ -1,321 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Create new Code Captain workflows following established patterns and conventions for Windsurf
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# New Command Workflow
|
|
6
|
-
|
|
7
|
-
## Overview
|
|
8
|
-
A meta workflow that creates new Code Captain workflows following established patterns and conventions. This workflow generates properly structured workflow files, updates documentation, and ensures consistency across the Code Captain ecosystem for Windsurf environments.
|
|
9
|
-
|
|
10
|
-
## Usage Examples
|
|
11
|
-
|
|
12
|
-
```bash
|
|
13
|
-
# Create a new workflow
|
|
14
|
-
/new-command "optimize" "Performance optimization for slow code sections"
|
|
15
|
-
|
|
16
|
-
# Create deployment workflow
|
|
17
|
-
/new-command "deploy" "Deploy applications to various cloud platforms"
|
|
18
|
-
|
|
19
|
-
# Create test generation workflow
|
|
20
|
-
/new-command "test-gen" "Generate comprehensive test suites from existing code"
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
## Workflow Process
|
|
24
|
-
|
|
25
|
-
### Step 1: Command Specification Gathering
|
|
26
|
-
|
|
27
|
-
**Initial Input Processing:**
|
|
28
|
-
- Parse workflow name (validate format: lowercase, hyphens allowed)
|
|
29
|
-
- Extract brief description from user input
|
|
30
|
-
- Use `find_by_name` to validate workflow name doesn't conflict with existing workflows
|
|
31
|
-
|
|
32
|
-
**Interactive Specification Building:**
|
|
33
|
-
|
|
34
|
-
Ask clarifying questions to build complete workflow specification:
|
|
35
|
-
|
|
36
|
-
1. **Workflow Category**: "Is this a [Setup/Analysis/Implementation/Integration] workflow?"
|
|
37
|
-
2. **Execution Style**: "Should this use contract style (extensive clarification rounds like create-spec) or direct execution (immediate action like swab)?"
|
|
38
|
-
3. **Usage Pattern**: "Does it take arguments, flags, or is it standalone?"
|
|
39
|
-
4. **AI Coordination**: "Does it need AI prompts for complex decision-making?"
|
|
40
|
-
5. **Output Location**: "Where should outputs be stored? (.code-captain/[folder])"
|
|
41
|
-
6. **Tool Integration**: "Which Windsurf tools will it use? (codebase_search, view_file, etc.)"
|
|
42
|
-
7. **Workflow Steps**: "What are the main phases/steps the workflow follows?"
|
|
43
|
-
|
|
44
|
-
### Step 2: Workflow Structure Generation
|
|
45
|
-
|
|
46
|
-
**Generate Standard Workflow File Structure:**
|
|
47
|
-
|
|
48
|
-
Use `write_to_file` to create workflow in `.windsurf/workflows/[command-name].md`:
|
|
49
|
-
|
|
50
|
-
```markdown
|
|
51
|
-
---
|
|
52
|
-
description: [Generated from description and clarifying questions]
|
|
53
|
-
---
|
|
54
|
-
|
|
55
|
-
# [Command Name] Workflow
|
|
56
|
-
|
|
57
|
-
## Overview
|
|
58
|
-
[Generated from description and clarifying questions]
|
|
59
|
-
|
|
60
|
-
## Usage Examples
|
|
61
|
-
|
|
62
|
-
```bash
|
|
63
|
-
# Primary usage
|
|
64
|
-
/[command-name] [arguments]
|
|
65
|
-
|
|
66
|
-
# Example scenarios
|
|
67
|
-
/[command-name] [example-args]
|
|
68
|
-
```
|
|
69
|
-
|
|
70
|
-
## Workflow Process
|
|
71
|
-
|
|
72
|
-
### Step 1: [Phase Name]
|
|
73
|
-
[Generated workflow steps]
|
|
74
|
-
|
|
75
|
-
### Step 2: [Phase Name]
|
|
76
|
-
[Generated workflow steps]
|
|
77
|
-
|
|
78
|
-
## Core Rules
|
|
79
|
-
[Generated based on workflow type]
|
|
80
|
-
|
|
81
|
-
## Integration with Code Captain Ecosystem
|
|
82
|
-
[Generated integration details]
|
|
83
|
-
|
|
84
|
-
## Windsurf Tools Used
|
|
85
|
-
[Generated tool list]
|
|
86
|
-
|
|
87
|
-
## Windsurf Features Used
|
|
88
|
-
[Generated features list]
|
|
89
|
-
|
|
90
|
-
---
|
|
91
|
-
*[Generated tagline]*
|
|
92
|
-
```
|
|
93
|
-
|
|
94
|
-
**Template Sections Based on Workflow Type and Execution Style:**
|
|
95
|
-
|
|
96
|
-
**Contract Style Workflows** (like `create-spec`, `create-adr`):
|
|
97
|
-
- Phase 1: Contract Establishment (No File Creation)
|
|
98
|
-
- Interactive clarification rounds with structured questions
|
|
99
|
-
- Critical analysis and assumption challenging
|
|
100
|
-
- Contract proposal phase
|
|
101
|
-
- Explicit user agreement before proceeding
|
|
102
|
-
|
|
103
|
-
**Direct Execution Workflows** (like `swab`, `execute-task`):
|
|
104
|
-
- Immediate action workflows
|
|
105
|
-
- Minimal clarification if needed
|
|
106
|
-
- Clear step-by-step execution
|
|
107
|
-
- Progress feedback and completion confirmation
|
|
108
|
-
|
|
109
|
-
**Setup/Analysis Workflows:**
|
|
110
|
-
- Context scanning steps
|
|
111
|
-
- File generation workflows
|
|
112
|
-
- Documentation creation
|
|
113
|
-
|
|
114
|
-
**Implementation Workflows:**
|
|
115
|
-
- TDD workflows if applicable
|
|
116
|
-
- Code modification steps
|
|
117
|
-
- Verification procedures
|
|
118
|
-
|
|
119
|
-
**Integration Workflows:**
|
|
120
|
-
- Platform-specific API interactions
|
|
121
|
-
- Sync and conflict resolution
|
|
122
|
-
- Error handling patterns
|
|
123
|
-
|
|
124
|
-
### Step 3: Tool Integration Mapping
|
|
125
|
-
|
|
126
|
-
**Map appropriate Windsurf tools based on workflow type:**
|
|
127
|
-
|
|
128
|
-
**File Operations:**
|
|
129
|
-
- `view_file`, `write_to_file`, `replace_file_content`, `find_by_name`, `list_dir`, `grep_search`
|
|
130
|
-
|
|
131
|
-
**Code Analysis:**
|
|
132
|
-
- `codebase_search`, `view_code_item`, `trajectory_search`
|
|
133
|
-
|
|
134
|
-
**Web & Browser:**
|
|
135
|
-
- `browser_preview`, `open_browser_url`, `search_web`, `read_url_content`
|
|
136
|
-
|
|
137
|
-
**System & Deployment:**
|
|
138
|
-
- `run_command`, `command_status`, `deploy_web_app`
|
|
139
|
-
|
|
140
|
-
**Memory & Context:**
|
|
141
|
-
- `view_content_chunk`, Memories feature for important decisions
|
|
142
|
-
|
|
143
|
-
### Step 4: Validation and Character Limit Check
|
|
144
|
-
|
|
145
|
-
**Verify Workflow Integration:**
|
|
146
|
-
- Use `view_file` to check workflow file syntax and structure
|
|
147
|
-
- Use `run_command` with `wc -c` to validate under 12k character limit
|
|
148
|
-
- Use `find_by_name` to ensure no conflicts with existing workflows
|
|
149
|
-
- Run basic structure validation
|
|
150
|
-
|
|
151
|
-
**Character Limit Enforcement:**
|
|
152
|
-
```bash
|
|
153
|
-
# Check if workflow is under 12k limit
|
|
154
|
-
wc -c .windsurf/workflows/[command-name].md
|
|
155
|
-
|
|
156
|
-
# Validate limit
|
|
157
|
-
[ $(wc -c < .windsurf/workflows/[command-name].md) -lt 12000 ] && echo "β
Under 12k" || echo "β οΈ Over 12k"
|
|
158
|
-
```
|
|
159
|
-
|
|
160
|
-
**Present Summary:**
|
|
161
|
-
```
|
|
162
|
-
β
New workflow created successfully!
|
|
163
|
-
|
|
164
|
-
π Files Created:
|
|
165
|
-
- .windsurf/workflows/[command-name].md
|
|
166
|
-
|
|
167
|
-
π Workflow Ready:
|
|
168
|
-
Usage: /[command-name] [args]
|
|
169
|
-
Documentation: .windsurf/workflows/[command-name].md
|
|
170
|
-
Character count: [X]/12000 characters
|
|
171
|
-
|
|
172
|
-
π Character Limit: β
Under 12k limit
|
|
173
|
-
```
|
|
174
|
-
|
|
175
|
-
## Core Rules
|
|
176
|
-
|
|
177
|
-
1. **Consistent Structure** - All generated workflows follow established Windsurf patterns
|
|
178
|
-
2. **Clear Documentation** - Each section has purpose and implementation details
|
|
179
|
-
3. **Character Limit Compliance** - All workflows must be under 12k characters
|
|
180
|
-
4. **Slash Command Syntax** - Use /command-name format for all examples
|
|
181
|
-
5. **Windsurf Tool Integration** - Use appropriate Windsurf tools for functionality
|
|
182
|
-
6. **Template Flexibility** - Adapt template based on workflow type and requirements
|
|
183
|
-
7. **Language & Shell Agnostic** - Workflows work across different programming languages using Windsurf's tools
|
|
184
|
-
|
|
185
|
-
## Workflow Generation Templates
|
|
186
|
-
|
|
187
|
-
### Contract Style Template Structure
|
|
188
|
-
```markdown
|
|
189
|
-
## Workflow Process
|
|
190
|
-
|
|
191
|
-
### Step 1: Requirement Clarification
|
|
192
|
-
**Gather detailed requirements through structured questions**
|
|
193
|
-
- [Specific clarification questions]
|
|
194
|
-
- [Assumption challenging]
|
|
195
|
-
- [Context gathering]
|
|
196
|
-
|
|
197
|
-
### Step 2: Contract Proposal
|
|
198
|
-
**Present structured contract for user agreement**
|
|
199
|
-
- [Contract format specific to workflow type]
|
|
200
|
-
- [Success criteria definition]
|
|
201
|
-
- [Scope boundaries]
|
|
202
|
-
|
|
203
|
-
### Step 3: User Agreement
|
|
204
|
-
**Explicit confirmation before proceeding**
|
|
205
|
-
- [Agreement validation]
|
|
206
|
-
- [Scope confirmation]
|
|
207
|
-
|
|
208
|
-
### Step 4: Implementation
|
|
209
|
-
**Execute workflow based on agreed contract**
|
|
210
|
-
- [Implementation steps]
|
|
211
|
-
- [Progress tracking]
|
|
212
|
-
- [Validation procedures]
|
|
213
|
-
```
|
|
214
|
-
|
|
215
|
-
### Direct Execution Template Structure
|
|
216
|
-
```markdown
|
|
217
|
-
## Workflow Process
|
|
218
|
-
|
|
219
|
-
### Step 1: Context Analysis
|
|
220
|
-
**Analyze current state and requirements**
|
|
221
|
-
- [Context gathering steps]
|
|
222
|
-
- [Requirement analysis]
|
|
223
|
-
|
|
224
|
-
### Step 2: Action Execution
|
|
225
|
-
**Perform workflow actions directly**
|
|
226
|
-
- [Action steps]
|
|
227
|
-
- [Tool usage]
|
|
228
|
-
- [Progress feedback]
|
|
229
|
-
|
|
230
|
-
### Step 3: Verification
|
|
231
|
-
**Validate results and completion**
|
|
232
|
-
- [Verification steps]
|
|
233
|
-
- [Quality checks]
|
|
234
|
-
- [Completion confirmation]
|
|
235
|
-
```
|
|
236
|
-
|
|
237
|
-
## Command Name Validation
|
|
238
|
-
|
|
239
|
-
**Validation Rules:**
|
|
240
|
-
- Lowercase letters, numbers, hyphens only
|
|
241
|
-
- No spaces or special characters
|
|
242
|
-
- Maximum 20 characters
|
|
243
|
-
- Cannot start with number or hyphen
|
|
244
|
-
- Must not conflict with existing workflows
|
|
245
|
-
|
|
246
|
-
**Validation Process:**
|
|
247
|
-
Use `grep_search` and `find_by_name` to check for conflicts:
|
|
248
|
-
```bash
|
|
249
|
-
# Check existing workflows
|
|
250
|
-
find_by_name "[command-name].md" in .windsurf/workflows/
|
|
251
|
-
|
|
252
|
-
# Validate format using pattern matching
|
|
253
|
-
```
|
|
254
|
-
|
|
255
|
-
## Error Handling
|
|
256
|
-
|
|
257
|
-
**Common Issues:**
|
|
258
|
-
- **Duplicate workflow name**: Check existing workflows, suggest alternatives
|
|
259
|
-
- **Invalid workflow name format**: Provide format guidance and examples
|
|
260
|
-
- **Character limit exceeded**: Provide optimization suggestions
|
|
261
|
-
- **Template generation errors**: Validate inputs, provide clear error messages
|
|
262
|
-
|
|
263
|
-
**Error Messages:**
|
|
264
|
-
```
|
|
265
|
-
β Workflow creation failed: [specific reason]
|
|
266
|
-
|
|
267
|
-
Suggestions:
|
|
268
|
-
- Check workflow name format (lowercase, hyphens only)
|
|
269
|
-
- Ensure name doesn't conflict with existing workflows
|
|
270
|
-
- Verify all required inputs are provided
|
|
271
|
-
- Ensure generated content is under 12k characters
|
|
272
|
-
|
|
273
|
-
Try: /new-command "valid-name" "clear description"
|
|
274
|
-
```
|
|
275
|
-
|
|
276
|
-
## Integration with Code Captain Ecosystem
|
|
277
|
-
|
|
278
|
-
**Workflow relationship:**
|
|
279
|
-
- Generates workflows compatible with other Code Captain workflows
|
|
280
|
-
- Follows established patterns from existing workflows
|
|
281
|
-
- Maintains consistency in structure and tool usage
|
|
282
|
-
- Ensures proper slash command syntax throughout
|
|
283
|
-
|
|
284
|
-
**Cross-workflow integration:**
|
|
285
|
-
- New workflows can reference existing workflows with proper `/workflow-name` syntax
|
|
286
|
-
- Generated workflows include appropriate tool mappings
|
|
287
|
-
- Documentation follows established Windsurf patterns
|
|
288
|
-
- Character limit compliance ensures deployability
|
|
289
|
-
|
|
290
|
-
## Quality Standards
|
|
291
|
-
|
|
292
|
-
**Structure requirements:**
|
|
293
|
-
- Proper frontmatter with description
|
|
294
|
-
- Clear overview and usage examples
|
|
295
|
-
- Detailed workflow process with numbered steps
|
|
296
|
-
- Appropriate tool integration
|
|
297
|
-
- Proper slash command syntax
|
|
298
|
-
|
|
299
|
-
**Content quality:**
|
|
300
|
-
- Clear, actionable workflow steps
|
|
301
|
-
- Appropriate tool usage for each step
|
|
302
|
-
- Proper error handling guidance
|
|
303
|
-
- Integration notes with other workflows
|
|
304
|
-
- Character count optimization
|
|
305
|
-
|
|
306
|
-
## Windsurf Tools Used
|
|
307
|
-
|
|
308
|
-
- `find_by_name`: Locate existing workflows and check for conflicts
|
|
309
|
-
- `view_file`: Examine existing workflow patterns for consistency
|
|
310
|
-
- `write_to_file`: Create new workflow files
|
|
311
|
-
- `run_command`: Validate character limits and file structure
|
|
312
|
-
- `codebase_search`: Understand existing workflow patterns
|
|
313
|
-
- `grep_search`: Search for workflow naming conflicts and patterns
|
|
314
|
-
|
|
315
|
-
## Windsurf Features Used
|
|
316
|
-
|
|
317
|
-
- **Memories**: After creating complex workflows, ask Cascade to "create a memory of this workflow pattern and its structure"
|
|
318
|
-
|
|
319
|
-
---
|
|
320
|
-
|
|
321
|
-
*π§ Building workflows that build workflows - meta automation at its finest.*
|
|
@@ -1,330 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: "Generate comprehensive product planning documentation using contract-first approach with structured discovery"
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Plan Product Workflow
|
|
6
|
-
|
|
7
|
-
## Overview
|
|
8
|
-
|
|
9
|
-
Generate comprehensive product planning documentation using contract-first approach. Establishes clear product vision, mission, and roadmap through structured discovery, then creates complete product planning package.
|
|
10
|
-
|
|
11
|
-
## Usage
|
|
12
|
-
|
|
13
|
-
```bash
|
|
14
|
-
/plan-product "product idea description"
|
|
15
|
-
```
|
|
16
|
-
|
|
17
|
-
## Process
|
|
18
|
-
|
|
19
|
-
### Phase 1: Product Discovery & Contract (No Files Created)
|
|
20
|
-
|
|
21
|
-
**Mission:** Transform rough product idea into comprehensive, actionable product plan. Challenge ideas that don't make business or technical sense.
|
|
22
|
-
|
|
23
|
-
#### Step 1.1: Context Scan
|
|
24
|
-
- Scan existing `.code-captain/product/` for product documentation
|
|
25
|
-
- Load project context from `.code-captain/docs/` (tech-stack.md if available)
|
|
26
|
-
- Review existing product mission or objectives
|
|
27
|
-
- **Output:** Product context summary and foundation assessment
|
|
28
|
-
|
|
29
|
-
#### Step 1.2: Gap Analysis (Internal)
|
|
30
|
-
Silently identify missing details across:
|
|
31
|
-
- Product vision and core value proposition
|
|
32
|
-
- Target market and user personas
|
|
33
|
-
- Key features and functionality scope
|
|
34
|
-
- Business model and monetization strategy
|
|
35
|
-
- Technical feasibility and architecture requirements
|
|
36
|
-
- Competitive landscape and differentiation
|
|
37
|
-
- Success metrics and validation criteria
|
|
38
|
-
- Timeline expectations and resource constraints
|
|
39
|
-
- Risk factors and mitigation strategies
|
|
40
|
-
|
|
41
|
-
#### Step 1.3: Structured Discovery Loop
|
|
42
|
-
|
|
43
|
-
**Rules:**
|
|
44
|
-
- Ask ONE focused question at a time
|
|
45
|
-
- After each answer, re-analyze context and technical feasibility
|
|
46
|
-
- Continue until reaching 95% confidence on product deliverable
|
|
47
|
-
- **Challenge ideas that don't make business or technical sense**
|
|
48
|
-
- Never declare "final question" - let conversation flow naturally
|
|
49
|
-
|
|
50
|
-
**Critical Analysis Examples:**
|
|
51
|
-
- "I see a potential issue with [scope] because [business/technical reason]. Would focusing on [core value] first work better?"
|
|
52
|
-
- "Based on your existing codebase, [proposed approach] might require significant architecture changes. Are you prepared for that?"
|
|
53
|
-
- "The market you're describing sounds very broad. Should we focus on [specific segment] to start?"
|
|
54
|
-
|
|
55
|
-
**Question Categories:**
|
|
56
|
-
- "Who specifically has this problem, and how painful is it for them?"
|
|
57
|
-
- "What would make someone switch from their current solution to yours?"
|
|
58
|
-
- "How will you measure product success in the first 6 months?"
|
|
59
|
-
- "What's your biggest constraint - time, budget, technical expertise, or market access?"
|
|
60
|
-
|
|
61
|
-
#### Step 1.4: Product Contract Proposal
|
|
62
|
-
|
|
63
|
-
When confident, present contract proposal:
|
|
64
|
-
|
|
65
|
-
```
|
|
66
|
-
## Product Planning Contract
|
|
67
|
-
|
|
68
|
-
**Product Vision:** [One clear sentence describing product and primary value]
|
|
69
|
-
|
|
70
|
-
**Target Market:** [Specific user segment with core problem]
|
|
71
|
-
|
|
72
|
-
**Unique Value:** [What makes this different/better than alternatives]
|
|
73
|
-
|
|
74
|
-
**Success Criteria:** [How you'll measure product-market fit and growth]
|
|
75
|
-
|
|
76
|
-
**MVP Scope:**
|
|
77
|
-
- Core Features: [3-5 essential features for first version]
|
|
78
|
-
- Success Metrics: [Key performance indicators]
|
|
79
|
-
|
|
80
|
-
**Product Architecture:**
|
|
81
|
-
- Complexity Level: [Simple/Moderate/Complex based on features]
|
|
82
|
-
- Integration Needs: [How this fits with existing business systems]
|
|
83
|
-
- Scale Requirements: [Expected user growth and feature expansion]
|
|
84
|
-
|
|
85
|
-
**β οΈ Product Risks (if any):**
|
|
86
|
-
- [Market risk, technical risk, or business model concerns]
|
|
87
|
-
- [Suggested validation approach or risk mitigation]
|
|
88
|
-
|
|
89
|
-
**π‘ Recommendations:**
|
|
90
|
-
- [Suggestions for improving product-market fit]
|
|
91
|
-
- [Ways to validate assumptions early and reduce risk]
|
|
92
|
-
|
|
93
|
-
**Roadmap Phases:**
|
|
94
|
-
- Phase 1 (MVP): [Core value delivery - weeks/months]
|
|
95
|
-
- Phase 2 (Growth): [Key expansion features - months]
|
|
96
|
-
- Phase 3 (Scale): [Advanced capabilities - quarters]
|
|
97
|
-
|
|
98
|
-
---
|
|
99
|
-
Options:
|
|
100
|
-
- Type 'yes' to lock this contract and create the product planning package
|
|
101
|
-
- Type 'edit: [your changes]' to modify the contract
|
|
102
|
-
- Type 'risks' to explore potential market/technical risks in detail
|
|
103
|
-
- Ask more questions if anything needs clarification
|
|
104
|
-
```
|
|
105
|
-
|
|
106
|
-
### Phase 2: Product Planning Package Creation (Post-Agreement Only)
|
|
107
|
-
|
|
108
|
-
**Triggered only after user confirms contract with 'yes'**
|
|
109
|
-
|
|
110
|
-
#### Step 2.1: Initialize Tracking
|
|
111
|
-
Use memory feature to track creation process:
|
|
112
|
-
1. Create product planning folder structure
|
|
113
|
-
2. Generate core product mission document
|
|
114
|
-
3. Develop product roadmap with phases
|
|
115
|
-
4. Create decision log and rationale
|
|
116
|
-
5. Generate lite mission for AI context
|
|
117
|
-
6. Present package for user review and validation
|
|
118
|
-
|
|
119
|
-
#### Step 2.2: Create Directory Structure
|
|
120
|
-
|
|
121
|
-
**Generated folder:**
|
|
122
|
-
```
|
|
123
|
-
.code-captain/product/
|
|
124
|
-
βββ mission.md # Complete product vision and strategy
|
|
125
|
-
βββ mission-lite.md # Condensed version for AI context
|
|
126
|
-
βββ roadmap.md # Development phases and timeline
|
|
127
|
-
βββ decisions.md # Decision log with rationale
|
|
128
|
-
βββ research/ # Supporting research and analysis
|
|
129
|
-
```
|
|
130
|
-
|
|
131
|
-
#### Step 2.3: Generate Core Documents
|
|
132
|
-
|
|
133
|
-
**mission.md** - Built from locked contract:
|
|
134
|
-
```markdown
|
|
135
|
-
# Product Mission
|
|
136
|
-
|
|
137
|
-
> Created: [DATE]
|
|
138
|
-
> Status: Planning
|
|
139
|
-
> Contract Locked: β
|
|
140
|
-
|
|
141
|
-
## Pitch
|
|
142
|
-
[PRODUCT_NAME] is a [PRODUCT_TYPE] that helps [TARGET_USERS] [SOLVE_PROBLEM] by providing [KEY_VALUE_PROPOSITION].
|
|
143
|
-
|
|
144
|
-
## Users
|
|
145
|
-
### Primary Customers
|
|
146
|
-
- [CUSTOMER_SEGMENT]: [DESCRIPTION and pain points]
|
|
147
|
-
|
|
148
|
-
### User Personas
|
|
149
|
-
**[PRIMARY_USER_TYPE]** ([AGE_RANGE])
|
|
150
|
-
- **Role:** [JOB_TITLE or context]
|
|
151
|
-
- **Context:** [Where/when they encounter the problem]
|
|
152
|
-
- **Pain Points:** [Specific problems this product solves]
|
|
153
|
-
- **Goals:** [What success looks like for them]
|
|
154
|
-
|
|
155
|
-
## The Problem
|
|
156
|
-
### [MAIN_PROBLEM_TITLE]
|
|
157
|
-
[Problem description with quantifiable impact where possible]
|
|
158
|
-
|
|
159
|
-
**Our Solution:** [How the product specifically addresses this problem]
|
|
160
|
-
|
|
161
|
-
## Differentiators
|
|
162
|
-
### [KEY_DIFFERENTIATOR]
|
|
163
|
-
Unlike [EXISTING_ALTERNATIVES], we provide [SPECIFIC_ADVANTAGE]. This results in [MEASURABLE_BENEFIT].
|
|
164
|
-
|
|
165
|
-
## Key Features
|
|
166
|
-
### Core Features (MVP)
|
|
167
|
-
- **[FEATURE_NAME]:** [User benefit and value]
|
|
168
|
-
|
|
169
|
-
### Growth Features (Phase 2)
|
|
170
|
-
- **[FEATURE_NAME]:** [User benefit and expansion value]
|
|
171
|
-
|
|
172
|
-
### Scale Features (Phase 3)
|
|
173
|
-
- **[FEATURE_NAME]:** [Advanced capabilities]
|
|
174
|
-
```
|
|
175
|
-
|
|
176
|
-
**roadmap.md** - Phased development plan:
|
|
177
|
-
```markdown
|
|
178
|
-
# Product Roadmap
|
|
179
|
-
|
|
180
|
-
> Based on Product Contract: [DATE]
|
|
181
|
-
|
|
182
|
-
## Phase 1: MVP (Minimum Viable Product)
|
|
183
|
-
**Timeline:** [Weeks/months]
|
|
184
|
-
**Goal:** Validate core value proposition with target users
|
|
185
|
-
|
|
186
|
-
### Success Criteria
|
|
187
|
-
- [Measurable criteria for product-market fit]
|
|
188
|
-
- [Key metrics to track]
|
|
189
|
-
|
|
190
|
-
### Core Features
|
|
191
|
-
- [ ] [FEATURE] - [User value] `[Effort: XS/S/M/L/XL]`
|
|
192
|
-
- [ ] [FEATURE] - [User value] `[Effort: XS/S/M/L/XL]`
|
|
193
|
-
|
|
194
|
-
### Technical Foundation
|
|
195
|
-
- [ ] [Infrastructure setup]
|
|
196
|
-
- [ ] [Core architecture implementation]
|
|
197
|
-
- [ ] [Testing and deployment pipeline]
|
|
198
|
-
|
|
199
|
-
### Validation Targets
|
|
200
|
-
- [Number] active users using core feature
|
|
201
|
-
- [Metric] user retention rate
|
|
202
|
-
- [Feedback] qualitative validation criteria
|
|
203
|
-
|
|
204
|
-
## Phase 2: Growth (Market Expansion)
|
|
205
|
-
**Timeline:** [Months]
|
|
206
|
-
**Goal:** Scale user base and expand feature set
|
|
207
|
-
|
|
208
|
-
### Growth Features
|
|
209
|
-
- [ ] [FEATURE] - [Expansion value] `[Effort]`
|
|
210
|
-
- [ ] [FEATURE] - [User experience improvement] `[Effort]`
|
|
211
|
-
|
|
212
|
-
## Phase 3: Scale (Advanced Capabilities)
|
|
213
|
-
**Timeline:** [Quarters]
|
|
214
|
-
**Goal:** Establish market leadership and advanced functionality
|
|
215
|
-
|
|
216
|
-
### Advanced Features
|
|
217
|
-
- [ ] [FEATURE] - [Competitive advantage] `[Effort]`
|
|
218
|
-
- [ ] [FEATURE] - [Enterprise/scale capability] `[Effort]`
|
|
219
|
-
|
|
220
|
-
## Effort Sizing
|
|
221
|
-
- **XS:** 1-2 days
|
|
222
|
-
- **S:** 3-5 days
|
|
223
|
-
- **M:** 1-2 weeks
|
|
224
|
-
- **L:** 3-4 weeks
|
|
225
|
-
- **XL:** 1+ months
|
|
226
|
-
```
|
|
227
|
-
|
|
228
|
-
#### Step 2.4: Generate Decision Log
|
|
229
|
-
|
|
230
|
-
**decisions.md** - Key product and technical decisions:
|
|
231
|
-
```markdown
|
|
232
|
-
# Product Decisions Log
|
|
233
|
-
|
|
234
|
-
> Override Priority: Highest
|
|
235
|
-
|
|
236
|
-
## [DATE]: Initial Product Planning
|
|
237
|
-
**ID:** DEC-001
|
|
238
|
-
**Status:** Accepted
|
|
239
|
-
**Category:** Product
|
|
240
|
-
|
|
241
|
-
### Decision
|
|
242
|
-
[Summarize: product vision, target market, key features, technical approach]
|
|
243
|
-
|
|
244
|
-
### Context
|
|
245
|
-
[Market opportunity, user problems, strategic rationale]
|
|
246
|
-
|
|
247
|
-
### Alternatives Considered
|
|
248
|
-
1. **[ALTERNATIVE_APPROACH]**
|
|
249
|
-
- Pros: [Benefits]
|
|
250
|
-
- Cons: [Drawbacks]
|
|
251
|
-
- Why rejected: [Reasoning]
|
|
252
|
-
|
|
253
|
-
### Rationale
|
|
254
|
-
[Key factors that drove this product direction]
|
|
255
|
-
|
|
256
|
-
### Consequences
|
|
257
|
-
**Positive:**
|
|
258
|
-
- [Expected benefits and advantages]
|
|
259
|
-
|
|
260
|
-
**Negative:**
|
|
261
|
-
- [Known tradeoffs and constraints]
|
|
262
|
-
|
|
263
|
-
### Success Metrics
|
|
264
|
-
- [How we'll measure if this decision was correct]
|
|
265
|
-
```
|
|
266
|
-
|
|
267
|
-
#### Step 2.5: Create Mission-Lite
|
|
268
|
-
|
|
269
|
-
**mission-lite.md** - Condensed product context for AI:
|
|
270
|
-
```markdown
|
|
271
|
-
# Product Mission (Lite)
|
|
272
|
-
|
|
273
|
-
> Source: Complete mission.md
|
|
274
|
-
> Purpose: Efficient AI context for development
|
|
275
|
-
|
|
276
|
-
## Core Value
|
|
277
|
-
[1-2 sentences capturing essential product value proposition]
|
|
278
|
-
|
|
279
|
-
## Target Users
|
|
280
|
-
[Primary user segment and core problem]
|
|
281
|
-
|
|
282
|
-
## Key Differentiator
|
|
283
|
-
[What makes this unique in 1 sentence]
|
|
284
|
-
|
|
285
|
-
## Success Definition
|
|
286
|
-
[How we measure product success]
|
|
287
|
-
|
|
288
|
-
## Current Phase
|
|
289
|
-
[MVP/Growth/Scale - what we're building now]
|
|
290
|
-
```
|
|
291
|
-
|
|
292
|
-
#### Step 2.6: Final Package Review
|
|
293
|
-
|
|
294
|
-
Present complete package:
|
|
295
|
-
```
|
|
296
|
-
β
Product planning package created successfully!
|
|
297
|
-
|
|
298
|
-
π .code-captain/product/
|
|
299
|
-
βββ π mission.md - Complete product vision and strategy
|
|
300
|
-
βββ π mission-lite.md - AI context summary
|
|
301
|
-
βββ πΊοΈ roadmap.md - Phased development plan
|
|
302
|
-
βββ π decisions.md - Decision log and rationale
|
|
303
|
-
|
|
304
|
-
Please review the planning documents and let me know:
|
|
305
|
-
- Does this accurately capture your product vision?
|
|
306
|
-
- Are there any missing requirements or incorrect assumptions?
|
|
307
|
-
- Should any product decisions be reconsidered?
|
|
308
|
-
- Does the roadmap timeline align with your expectations?
|
|
309
|
-
|
|
310
|
-
Once satisfied, you can use:
|
|
311
|
-
- `/create-spec` to detail specific features from the roadmap
|
|
312
|
-
- `/execute-task` to begin implementing planned features
|
|
313
|
-
- `/research` to investigate any market or product unknowns
|
|
314
|
-
```
|
|
315
|
-
|
|
316
|
-
## Implementation with Windsurf Tools
|
|
317
|
-
|
|
318
|
-
**File Operations:**
|
|
319
|
-
- Use `write_to_file` to create product planning documents
|
|
320
|
-
- Use `view_file` to review existing product documentation
|
|
321
|
-
- Use `find_by_name` to locate related files
|
|
322
|
-
|
|
323
|
-
**Research Tools:**
|
|
324
|
-
- Use `search_web` for market research and competitive analysis
|
|
325
|
-
- Use memory feature to track discovery progress and key decisions
|
|
326
|
-
|
|
327
|
-
**Integration:**
|
|
328
|
-
- Works with existing `.code-captain/product/` directory structure
|
|
329
|
-
- Feeds into feature specification and development workflows
|
|
330
|
-
- Supports cross-command integration with research and ADR workflows
|