@devobsessed/code-captain 0.0.3
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 +214 -0
- package/bin/install.js +1048 -0
- package/claude-code/README.md +276 -0
- package/claude-code/agents/code-captain.md +121 -0
- package/claude-code/agents/spec-generator.md +271 -0
- package/claude-code/agents/story-creator.md +309 -0
- package/claude-code/agents/tech-spec.md +440 -0
- package/claude-code/commands/cc-initialize.md +520 -0
- package/copilot/README.md +210 -0
- package/copilot/chatmodes/Code Captain.chatmode.md +60 -0
- package/copilot/docs/best-practices.md +74 -0
- package/copilot/prompts/create-adr.prompt.md +468 -0
- package/copilot/prompts/create-spec.prompt.md +430 -0
- package/copilot/prompts/edit-spec.prompt.md +396 -0
- package/copilot/prompts/execute-task.prompt.md +144 -0
- package/copilot/prompts/explain-code.prompt.md +292 -0
- package/copilot/prompts/initialize.prompt.md +65 -0
- package/copilot/prompts/new-command.prompt.md +310 -0
- package/copilot/prompts/plan-product.prompt.md +450 -0
- package/copilot/prompts/research.prompt.md +329 -0
- package/copilot/prompts/status.prompt.md +424 -0
- package/copilot/prompts/swab.prompt.md +217 -0
- package/cursor/README.md +224 -0
- package/cursor/cc.md +183 -0
- package/cursor/cc.mdc +69 -0
- package/cursor/commands/create-adr.md +504 -0
- package/cursor/commands/create-spec.md +430 -0
- package/cursor/commands/edit-spec.md +405 -0
- package/cursor/commands/execute-task.md +514 -0
- package/cursor/commands/explain-code.md +289 -0
- package/cursor/commands/initialize.md +397 -0
- package/cursor/commands/new-command.md +312 -0
- package/cursor/commands/plan-product.md +466 -0
- package/cursor/commands/research.md +317 -0
- package/cursor/commands/status.md +413 -0
- package/cursor/commands/swab.md +209 -0
- package/cursor/docs/best-practices.md +74 -0
- package/cursor/integrations/azure-devops/create-azure-work-items.md +403 -0
- package/cursor/integrations/azure-devops/sync-azure-work-items.md +486 -0
- package/cursor/integrations/github/create-github-issues.md +765 -0
- package/cursor/integrations/github/scripts/create-issues-batch.sh +272 -0
- package/cursor/integrations/github/sync-github-issues.md +237 -0
- package/cursor/integrations/github/sync.md +305 -0
- package/manifest.json +381 -0
- package/package.json +58 -0
- package/windsurf/README.md +254 -0
- package/windsurf/rules/cc.md +5 -0
- package/windsurf/workflows/create-adr.md +331 -0
- package/windsurf/workflows/create-spec.md +280 -0
- package/windsurf/workflows/edit-spec.md +273 -0
- package/windsurf/workflows/execute-task.md +276 -0
- package/windsurf/workflows/explain-code.md +292 -0
- package/windsurf/workflows/initialize.md +298 -0
- package/windsurf/workflows/new-command.md +321 -0
- package/windsurf/workflows/status.md +213 -0
|
@@ -0,0 +1,466 @@
|
|
|
1
|
+
# Plan Product Command (cc: plan-product)
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
Generate comprehensive product planning documentation using a contract-first approach that establishes clear product vision, mission, and roadmap before creating any supporting files. This command eliminates assumptions by gathering complete product context through structured discovery, then creates a complete product planning package for AI-assisted development.
|
|
6
|
+
|
|
7
|
+
## Usage
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
cc: plan-product "product idea description"
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
## Command Process
|
|
14
|
+
|
|
15
|
+
### Phase 1: Product Discovery & Contract Establishment (No File Creation)
|
|
16
|
+
|
|
17
|
+
**Mission Statement:**
|
|
18
|
+
> Your goal is to transform a rough product idea into a comprehensive, actionable product plan. You will deliver the complete product planning package only after we both agree on the product contract. **Important: Challenge ideas that don't make business or technical sense - it's better to surface concerns early than build the wrong product.**
|
|
19
|
+
|
|
20
|
+
#### Step 1.1: Initial Context Scan
|
|
21
|
+
|
|
22
|
+
- Scan existing `.code-captain/product/` for any existing product documentation
|
|
23
|
+
- Load available project context from `.code-captain/docs/` (tech-stack.md if available)
|
|
24
|
+
- Review any existing product mission or objectives
|
|
25
|
+
- **Output:** Product context summary and foundation assessment
|
|
26
|
+
|
|
27
|
+
#### Step 1.2: Gap Analysis & Silent Enumeration
|
|
28
|
+
|
|
29
|
+
**Internal Process (not shown to user):**
|
|
30
|
+
- Silently list every missing product detail and requirement
|
|
31
|
+
- Identify ambiguities in the initial product description
|
|
32
|
+
- Note potential market and technical constraints
|
|
33
|
+
- Catalog unknowns across these domains:
|
|
34
|
+
- Product vision and core value proposition
|
|
35
|
+
- Target market and user personas
|
|
36
|
+
- Key features and functionality scope
|
|
37
|
+
- Business model and monetization strategy
|
|
38
|
+
- Technical feasibility and architecture requirements
|
|
39
|
+
- Competitive landscape and differentiation
|
|
40
|
+
- Success metrics and validation criteria
|
|
41
|
+
- Timeline expectations and resource constraints
|
|
42
|
+
- Risk factors and mitigation strategies
|
|
43
|
+
|
|
44
|
+
#### Step 1.3: Structured Product Discovery Loop
|
|
45
|
+
|
|
46
|
+
**Rules:**
|
|
47
|
+
- Ask ONE focused question at a time
|
|
48
|
+
- After each answer, re-analyze context and technical feasibility
|
|
49
|
+
- Continue until reaching 95% confidence on product deliverable
|
|
50
|
+
- Each question should target the highest-impact unknown
|
|
51
|
+
- **Never declare "final question"** - let the conversation flow naturally
|
|
52
|
+
- Let the user signal when they're ready to lock the contract
|
|
53
|
+
- **Challenge ideas that don't make business or technical sense** - better to surface concerns early than plan the wrong product
|
|
54
|
+
|
|
55
|
+
**Critical Analysis Responsibility:**
|
|
56
|
+
- If product scope seems too large for available resources, recommend phasing
|
|
57
|
+
- If target market is unclear or too broad, suggest narrowing focus
|
|
58
|
+
- If technical requirements conflict with existing codebase, explain implications
|
|
59
|
+
- If business model doesn't align with user value, ask clarifying questions
|
|
60
|
+
- If competitive landscape presents challenges, surface them proactively
|
|
61
|
+
|
|
62
|
+
**Pushback Phrasing Examples:**
|
|
63
|
+
- "I see a potential issue with [scope] because [business/technical reason]. Would focusing on [core value] first work better?"
|
|
64
|
+
- "Based on your existing codebase, [proposed approach] might require significant architecture changes. Are you prepared for that?"
|
|
65
|
+
- "The market you're describing sounds very broad. Should we focus on [specific segment] to start?"
|
|
66
|
+
- "I'm concerned that [requirement] could face [specific challenge]. Have you considered [alternative approach]?"
|
|
67
|
+
|
|
68
|
+
**Question Categories (examples):**
|
|
69
|
+
- "Who specifically has this problem, and how painful is it for them?"
|
|
70
|
+
- "What would make someone switch from their current solution to yours?"
|
|
71
|
+
- "How will you measure product success in the first 6 months?"
|
|
72
|
+
- "What's your biggest constraint - time, budget, technical expertise, or market access?"
|
|
73
|
+
- "How does this align with your existing business/project goals?"
|
|
74
|
+
- "What happens if your first assumption about users turns out to be wrong?"
|
|
75
|
+
|
|
76
|
+
**Transition to Contract:**
|
|
77
|
+
- When confidence is high, present contract without declaring it "final"
|
|
78
|
+
- Use phrases like "I think I have enough to create a solid product contract" or "Based on our discussion, here's what I understand"
|
|
79
|
+
- Always leave room for more questions if needed
|
|
80
|
+
|
|
81
|
+
#### Step 1.4: Product Contract Proposal
|
|
82
|
+
|
|
83
|
+
When confident, present a product contract proposal with any concerns surfaced:
|
|
84
|
+
|
|
85
|
+
**Format:**
|
|
86
|
+
```
|
|
87
|
+
## Product Planning Contract
|
|
88
|
+
|
|
89
|
+
**Product Vision:** [One clear sentence describing the product and its primary value]
|
|
90
|
+
|
|
91
|
+
**Target Market:** [Specific user segment with their core problem]
|
|
92
|
+
|
|
93
|
+
**Unique Value:** [What makes this different/better than alternatives]
|
|
94
|
+
|
|
95
|
+
**Success Criteria:** [How you'll measure product-market fit and growth]
|
|
96
|
+
|
|
97
|
+
**MVP Scope:**
|
|
98
|
+
- Core Features: [3-5 essential features for first version]
|
|
99
|
+
- Success Metrics: [Key performance indicators]
|
|
100
|
+
|
|
101
|
+
**Product Architecture:**
|
|
102
|
+
- Complexity Level: [Simple/Moderate/Complex based on features]
|
|
103
|
+
- Integration Needs: [How this fits with existing business systems]
|
|
104
|
+
- Scale Requirements: [Expected user growth and feature expansion]
|
|
105
|
+
|
|
106
|
+
**β οΈ Product Risks (if any):**
|
|
107
|
+
- [Market risk, technical risk, or business model concerns]
|
|
108
|
+
- [Suggested validation approach or risk mitigation]
|
|
109
|
+
|
|
110
|
+
**π‘ Recommendations:**
|
|
111
|
+
- [Suggestions for improving product-market fit]
|
|
112
|
+
- [Ways to validate assumptions early and reduce risk]
|
|
113
|
+
|
|
114
|
+
**Roadmap Phases:**
|
|
115
|
+
- Phase 1 (MVP): [Core value delivery - weeks/months]
|
|
116
|
+
- Phase 2 (Growth): [Key expansion features - months]
|
|
117
|
+
- Phase 3 (Scale): [Advanced capabilities - quarters]
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
Options:
|
|
121
|
+
- Type 'yes' to lock this contract and create the product planning package
|
|
122
|
+
- Type 'edit: [your changes]' to modify the contract
|
|
123
|
+
- Type 'risks' to explore potential market/technical risks in detail
|
|
124
|
+
- Type 'competition' to analyze competitive landscape
|
|
125
|
+
- Ask more questions if anything needs clarification
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
### Phase 2: Product Planning Package Creation (Post-Agreement Only)
|
|
129
|
+
|
|
130
|
+
**Triggered only after user confirms contract with 'yes'**
|
|
131
|
+
|
|
132
|
+
#### Step 2.1: Initialize Tracking
|
|
133
|
+
|
|
134
|
+
```bash
|
|
135
|
+
# Use todo_write to track creation process
|
|
136
|
+
1. Create product planning folder structure
|
|
137
|
+
2. Generate core product mission document
|
|
138
|
+
3. Develop product roadmap with phases
|
|
139
|
+
4. Create decision log and rationale
|
|
140
|
+
5. Generate lite mission for AI context
|
|
141
|
+
6. Present package for user review and validation
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
#### Step 2.2: Create Directory Structure
|
|
145
|
+
|
|
146
|
+
**Generated folder:**
|
|
147
|
+
```
|
|
148
|
+
.code-captain/product/
|
|
149
|
+
βββ mission.md # Complete product vision and strategy
|
|
150
|
+
βββ mission-lite.md # Condensed version for AI context
|
|
151
|
+
βββ roadmap.md # Development phases and timeline
|
|
152
|
+
βββ decisions.md # Decision log with rationale
|
|
153
|
+
βββ research/ # Supporting research and analysis
|
|
154
|
+
βββ market-analysis.md # Target market and competition (if needed)
|
|
155
|
+
βββ user-personas.md # Detailed user profiles (if needed)
|
|
156
|
+
βββ feature-specs/ # Individual feature specifications (if needed)
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
#### Step 2.3: Generate Core Product Documents
|
|
160
|
+
|
|
161
|
+
**mission.md** - Built directly from the locked contract:
|
|
162
|
+
```markdown
|
|
163
|
+
# Product Mission
|
|
164
|
+
|
|
165
|
+
> Created: [DATE]
|
|
166
|
+
> Status: Planning
|
|
167
|
+
> Contract Locked: β
|
|
168
|
+
|
|
169
|
+
## Pitch
|
|
170
|
+
[PRODUCT_NAME] is a [PRODUCT_TYPE] that helps [TARGET_USERS] [SOLVE_PROBLEM] by providing [KEY_VALUE_PROPOSITION].
|
|
171
|
+
|
|
172
|
+
## Users
|
|
173
|
+
### Primary Customers
|
|
174
|
+
- [CUSTOMER_SEGMENT]: [DESCRIPTION and pain points]
|
|
175
|
+
|
|
176
|
+
### User Personas
|
|
177
|
+
**[PRIMARY_USER_TYPE]** ([AGE_RANGE])
|
|
178
|
+
- **Role:** [JOB_TITLE or context]
|
|
179
|
+
- **Context:** [Where/when they encounter the problem]
|
|
180
|
+
- **Pain Points:** [Specific problems this product solves]
|
|
181
|
+
- **Goals:** [What success looks like for them]
|
|
182
|
+
|
|
183
|
+
## The Problem
|
|
184
|
+
### [MAIN_PROBLEM_TITLE]
|
|
185
|
+
[Problem description with quantifiable impact where possible]
|
|
186
|
+
|
|
187
|
+
**Our Solution:** [How the product specifically addresses this problem]
|
|
188
|
+
|
|
189
|
+
## Differentiators
|
|
190
|
+
### [KEY_DIFFERENTIATOR]
|
|
191
|
+
Unlike [EXISTING_ALTERNATIVES], we provide [SPECIFIC_ADVANTAGE]. This results in [MEASURABLE_BENEFIT].
|
|
192
|
+
|
|
193
|
+
## Key Features
|
|
194
|
+
### Core Features (MVP)
|
|
195
|
+
- **[FEATURE_NAME]:** [User benefit and value]
|
|
196
|
+
|
|
197
|
+
### Growth Features (Phase 2)
|
|
198
|
+
- **[FEATURE_NAME]:** [User benefit and expansion value]
|
|
199
|
+
|
|
200
|
+
### Scale Features (Phase 3)
|
|
201
|
+
- **[FEATURE_NAME]:** [Advanced capabilities]
|
|
202
|
+
```
|
|
203
|
+
|
|
204
|
+
|
|
205
|
+
|
|
206
|
+
**roadmap.md** - Phased development plan:
|
|
207
|
+
```markdown
|
|
208
|
+
# Product Roadmap
|
|
209
|
+
|
|
210
|
+
> Based on Product Contract: [DATE]
|
|
211
|
+
|
|
212
|
+
## Phase 1: MVP (Minimum Viable Product)
|
|
213
|
+
**Timeline:** [Weeks/months]
|
|
214
|
+
**Goal:** Validate core value proposition with target users
|
|
215
|
+
|
|
216
|
+
### Success Criteria
|
|
217
|
+
- [Measurable criteria for product-market fit]
|
|
218
|
+
- [Key metrics to track]
|
|
219
|
+
|
|
220
|
+
### Core Features
|
|
221
|
+
- [ ] [FEATURE] - [User value] `[Effort: XS/S/M/L/XL]`
|
|
222
|
+
- [ ] [FEATURE] - [User value] `[Effort: XS/S/M/L/XL]`
|
|
223
|
+
|
|
224
|
+
### Technical Foundation
|
|
225
|
+
- [ ] [Infrastructure setup]
|
|
226
|
+
- [ ] [Core architecture implementation]
|
|
227
|
+
- [ ] [Testing and deployment pipeline]
|
|
228
|
+
|
|
229
|
+
### Validation Targets
|
|
230
|
+
- [Number] active users using core feature
|
|
231
|
+
- [Metric] user retention rate
|
|
232
|
+
- [Feedback] qualitative validation criteria
|
|
233
|
+
|
|
234
|
+
---
|
|
235
|
+
|
|
236
|
+
## Phase 2: Growth (Market Expansion)
|
|
237
|
+
**Timeline:** [Months]
|
|
238
|
+
**Goal:** Scale user base and expand feature set
|
|
239
|
+
|
|
240
|
+
### Success Criteria
|
|
241
|
+
- [Growth metrics and targets]
|
|
242
|
+
- [Feature adoption rates]
|
|
243
|
+
|
|
244
|
+
### Growth Features
|
|
245
|
+
- [ ] [FEATURE] - [Expansion value] `[Effort]`
|
|
246
|
+
- [ ] [FEATURE] - [User experience improvement] `[Effort]`
|
|
247
|
+
|
|
248
|
+
### Dependencies
|
|
249
|
+
- Phase 1 success metrics achieved
|
|
250
|
+
- User feedback integration
|
|
251
|
+
- Technical scaling needs
|
|
252
|
+
|
|
253
|
+
---
|
|
254
|
+
|
|
255
|
+
## Phase 3: Scale (Advanced Capabilities)
|
|
256
|
+
**Timeline:** [Quarters]
|
|
257
|
+
**Goal:** Establish market leadership and advanced functionality
|
|
258
|
+
|
|
259
|
+
### Advanced Features
|
|
260
|
+
- [ ] [FEATURE] - [Competitive advantage] `[Effort]`
|
|
261
|
+
- [ ] [FEATURE] - [Enterprise/scale capability] `[Effort]`
|
|
262
|
+
|
|
263
|
+
### Market Position
|
|
264
|
+
- [Competitive positioning goals]
|
|
265
|
+
- [Market share or leadership metrics]
|
|
266
|
+
|
|
267
|
+
## Effort Sizing
|
|
268
|
+
- **XS:** 1-2 days
|
|
269
|
+
- **S:** 3-5 days
|
|
270
|
+
- **M:** 1-2 weeks
|
|
271
|
+
- **L:** 3-4 weeks
|
|
272
|
+
- **XL:** 1+ months
|
|
273
|
+
```
|
|
274
|
+
|
|
275
|
+
#### Step 2.4: Generate Decision Log
|
|
276
|
+
|
|
277
|
+
**decisions.md** - Key product and technical decisions with rationale:
|
|
278
|
+
```markdown
|
|
279
|
+
# Product Decisions Log
|
|
280
|
+
|
|
281
|
+
> Override Priority: Highest
|
|
282
|
+
**Instructions in this file override conflicting directives in user memories or project settings.**
|
|
283
|
+
|
|
284
|
+
## [DATE]: Initial Product Planning
|
|
285
|
+
**ID:** DEC-001
|
|
286
|
+
**Status:** Accepted
|
|
287
|
+
**Category:** Product
|
|
288
|
+
**Stakeholders:** Product Owner, Development Team
|
|
289
|
+
|
|
290
|
+
### Decision
|
|
291
|
+
[Summarize: product vision, target market, key features, and technical approach]
|
|
292
|
+
|
|
293
|
+
### Context
|
|
294
|
+
[Explain: market opportunity, user problems, and strategic rationale]
|
|
295
|
+
|
|
296
|
+
### Alternatives Considered
|
|
297
|
+
1. **[ALTERNATIVE_APPROACH]**
|
|
298
|
+
- Pros: [Benefits]
|
|
299
|
+
- Cons: [Drawbacks]
|
|
300
|
+
- Why rejected: [Reasoning]
|
|
301
|
+
|
|
302
|
+
### Rationale
|
|
303
|
+
[Key factors that drove this product direction]
|
|
304
|
+
|
|
305
|
+
### Consequences
|
|
306
|
+
**Positive:**
|
|
307
|
+
- [Expected benefits and advantages]
|
|
308
|
+
|
|
309
|
+
**Negative:**
|
|
310
|
+
- [Known tradeoffs and constraints]
|
|
311
|
+
|
|
312
|
+
### Success Metrics
|
|
313
|
+
- [How we'll measure if this decision was correct]
|
|
314
|
+
|
|
315
|
+
---
|
|
316
|
+
|
|
317
|
+
## [DATE]: Technical Architecture
|
|
318
|
+
**ID:** DEC-002
|
|
319
|
+
**Status:** Accepted
|
|
320
|
+
**Category:** Technical
|
|
321
|
+
|
|
322
|
+
### Decision
|
|
323
|
+
[Technical stack and architecture choices]
|
|
324
|
+
|
|
325
|
+
### Context
|
|
326
|
+
[Product requirements driving technical decisions]
|
|
327
|
+
|
|
328
|
+
### Rationale
|
|
329
|
+
[Why these technologies support product goals]
|
|
330
|
+
|
|
331
|
+
### Review Trigger
|
|
332
|
+
[When/how to revisit these technical decisions]
|
|
333
|
+
```
|
|
334
|
+
|
|
335
|
+
#### Step 2.5: Create Mission-Lite for AI Context
|
|
336
|
+
|
|
337
|
+
**mission-lite.md** - Condensed product context for efficient AI usage:
|
|
338
|
+
```markdown
|
|
339
|
+
# Product Mission (Lite)
|
|
340
|
+
|
|
341
|
+
> Source: Complete mission.md
|
|
342
|
+
> Purpose: Efficient AI context for development
|
|
343
|
+
|
|
344
|
+
## Core Value
|
|
345
|
+
[1-2 sentences capturing the essential product value proposition]
|
|
346
|
+
|
|
347
|
+
## Target Users
|
|
348
|
+
[Primary user segment and their core problem]
|
|
349
|
+
|
|
350
|
+
## Key Differentiator
|
|
351
|
+
[What makes this unique in 1 sentence]
|
|
352
|
+
|
|
353
|
+
## Success Definition
|
|
354
|
+
[How we measure product success]
|
|
355
|
+
|
|
356
|
+
## Current Phase
|
|
357
|
+
[MVP/Growth/Scale - what we're building now]
|
|
358
|
+
|
|
359
|
+
---
|
|
360
|
+
|
|
361
|
+
**Example:**
|
|
362
|
+
TaskMaster is a project management tool that helps remote software teams coordinate work efficiently through automated workflow integration and intelligent task prioritization. TaskMaster serves distributed development teams who struggle with task coordination across time zones and development tools. Unlike traditional project management tools, TaskMaster automatically syncs with Git workflows and provides AI-powered task prioritization based on team capacity and code dependencies.
|
|
363
|
+
```
|
|
364
|
+
|
|
365
|
+
#### Step 2.6: Final Package Review & User Validation
|
|
366
|
+
|
|
367
|
+
Present complete package with file references:
|
|
368
|
+
```
|
|
369
|
+
β
Product planning package created successfully!
|
|
370
|
+
|
|
371
|
+
π .code-captain/product/
|
|
372
|
+
βββ π mission.md - Complete product vision and strategy
|
|
373
|
+
βββ π mission-lite.md - AI context summary
|
|
374
|
+
βββ πΊοΈ roadmap.md - Phased development plan
|
|
375
|
+
βββ π decisions.md - Decision log and rationale
|
|
376
|
+
|
|
377
|
+
The product plan captures everything we discussed, including:
|
|
378
|
+
- [Brief summary of product vision]
|
|
379
|
+
- [Key market positioning and user value]
|
|
380
|
+
- [Roadmap approach or notable phases]
|
|
381
|
+
|
|
382
|
+
Please review the planning documents and let me know:
|
|
383
|
+
- Does this accurately capture your product vision?
|
|
384
|
+
- Are there any missing requirements or incorrect assumptions?
|
|
385
|
+
- Should any product decisions be reconsidered?
|
|
386
|
+
- Does the roadmap timeline align with your expectations?
|
|
387
|
+
|
|
388
|
+
Once you're satisfied with the product plan, you can use:
|
|
389
|
+
- `cc: create-spec` to detail specific features from the roadmap
|
|
390
|
+
- `cc: execute-task` to begin implementing planned features
|
|
391
|
+
- `cc: research` to investigate any market or product unknowns
|
|
392
|
+
```
|
|
393
|
+
|
|
394
|
+
## Key Improvements Over Basic Product Planning
|
|
395
|
+
|
|
396
|
+
### 1. Contract-First Product Discovery
|
|
397
|
+
- **No presumptuous planning** - Nothing gets created until product contract is locked
|
|
398
|
+
- **Structured discovery** - One question at a time, building complete understanding
|
|
399
|
+
- **Critical analysis** - Challenges assumptions and surfaces risks early
|
|
400
|
+
|
|
401
|
+
### 2. Context-Aware Planning
|
|
402
|
+
- **Product continuity** - Plans build on existing product foundation if present
|
|
403
|
+
- **Integration considerations** - Product features consider current business context
|
|
404
|
+
- **Realistic scoping** - Development effort estimates based on team capabilities
|
|
405
|
+
|
|
406
|
+
### 3. User Control & Risk Assessment
|
|
407
|
+
- **Clear decision points** - User explicitly approves before file creation
|
|
408
|
+
- **Risk exploration option** - Can analyze market/technical risks before committing
|
|
409
|
+
- **Edit capability** - Can modify contract before locking
|
|
410
|
+
- **Competition analysis** - Can explore competitive landscape
|
|
411
|
+
|
|
412
|
+
### 4. AI-Optimized Output
|
|
413
|
+
- **Mission-lite for context** - Efficient AI consumption during development
|
|
414
|
+
- **Decision tracking** - Clear rationale for AI to follow in future work
|
|
415
|
+
- **Integration with specs** - Seamless flow to detailed feature specification
|
|
416
|
+
|
|
417
|
+
## Tool Integration
|
|
418
|
+
|
|
419
|
+
**Primary Code Captain tools:**
|
|
420
|
+
- `todo_write` - Progress tracking throughout discovery and creation
|
|
421
|
+
- `file_search` - Locating existing product documentation
|
|
422
|
+
- `read_file` - Loading project context and existing plans
|
|
423
|
+
- `write` - Creating product planning documents
|
|
424
|
+
- `web_search` - Market research and competitive analysis (if needed)
|
|
425
|
+
|
|
426
|
+
**Parallel execution opportunities:**
|
|
427
|
+
- Context gathering (existing product docs, project context)
|
|
428
|
+
- Product research (market analysis, competitive landscape)
|
|
429
|
+
- User research and persona development
|
|
430
|
+
|
|
431
|
+
## Integration with Code Captain Ecosystem
|
|
432
|
+
|
|
433
|
+
**Project foundation dependency:**
|
|
434
|
+
- Works with existing `.code-captain/docs/` context files for technical awareness
|
|
435
|
+
- Builds on any existing product documentation
|
|
436
|
+
- Integrates with established project patterns if present
|
|
437
|
+
|
|
438
|
+
**Cross-command integration:**
|
|
439
|
+
- Feeds into `cc: create-spec` for detailed feature planning
|
|
440
|
+
- Supports `cc: execute-task` with clear product context
|
|
441
|
+
- Can trigger `cc: research` for market or technical investigation
|
|
442
|
+
|
|
443
|
+
**Output integration:**
|
|
444
|
+
- Product documents provide context for all future development
|
|
445
|
+
- Decision log guides technical choices
|
|
446
|
+
- Roadmap phases structure feature development
|
|
447
|
+
|
|
448
|
+
## Best Practices
|
|
449
|
+
|
|
450
|
+
**Product discovery:**
|
|
451
|
+
- Challenge assumptions early and often
|
|
452
|
+
- Focus on user problems over solution features
|
|
453
|
+
- Validate business model alignment with user value
|
|
454
|
+
- Surface technical constraints before committing to features
|
|
455
|
+
|
|
456
|
+
**Documentation quality:**
|
|
457
|
+
- Keep mission-lite focused and efficient for AI context
|
|
458
|
+
- Maintain decision rationale for future reference
|
|
459
|
+
- Structure roadmap for incremental value delivery
|
|
460
|
+
- Connect technical decisions to product requirements
|
|
461
|
+
|
|
462
|
+
**Risk management:**
|
|
463
|
+
- Identify market risks and validation strategies
|
|
464
|
+
- Assess technical feasibility realistically
|
|
465
|
+
- Plan for scope reduction if needed
|
|
466
|
+
- Build learning and iteration into roadmap phases
|