@devobsessed/code-captain 0.0.6 → 0.0.9
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 +36 -37
- package/bin/install.js +1166 -983
- package/claude-code/agents/code-captain.md +31 -22
- package/copilot/README.md +26 -16
- package/copilot/chatmodes/Code Captain.chatmode.md +41 -25
- package/copilot/prompts/create-adr.prompt.md +6 -4
- package/copilot/prompts/create-spec.prompt.md +62 -45
- package/copilot/prompts/explain-code.prompt.md +7 -23
- package/copilot/prompts/new-command.prompt.md +60 -21
- package/copilot/prompts/research.prompt.md +14 -30
- package/copilot/prompts/status.prompt.md +13 -2
- package/copilot/prompts/swab.prompt.md +1 -0
- package/cursor/README.md +77 -88
- package/cursor/cc.mdc +13 -42
- package/cursor/commands/create-adr.md +7 -13
- package/cursor/commands/create-spec.md +73 -64
- package/cursor/commands/edit-spec.md +2 -15
- package/cursor/commands/execute-task.md +7 -15
- package/cursor/commands/explain-code.md +16 -35
- package/cursor/commands/initialize.md +19 -18
- package/cursor/commands/new-command.md +173 -81
- package/cursor/commands/plan-product.md +7 -13
- package/cursor/commands/research.md +5 -27
- package/cursor/commands/status.md +34 -23
- package/cursor/commands/swab.md +63 -12
- package/manifest.json +110 -229
- package/package.json +13 -4
- package/cursor/cc.md +0 -183
- package/cursor/integrations/azure-devops/create-azure-work-items.md +0 -403
- package/cursor/integrations/azure-devops/sync-azure-work-items.md +0 -486
- package/cursor/integrations/github/create-github-issues.md +0 -765
- package/cursor/integrations/github/scripts/create-issues-batch.sh +0 -272
- package/cursor/integrations/github/sync-github-issues.md +0 -237
- package/cursor/integrations/github/sync.md +0 -305
- 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 -292
- package/windsurf/workflows/initialize.md +0 -298
- package/windsurf/workflows/new-command.md +0 -321
- package/windsurf/workflows/status.md +0 -213
|
@@ -1,292 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Provide comprehensive AI-powered explanations of code segments, functions, classes, or files with visual diagrams
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Explain Code Workflow
|
|
6
|
-
|
|
7
|
-
## Overview
|
|
8
|
-
Provides comprehensive, AI-powered explanations of code segments, functions, classes, or entire files. Combines natural language explanations with visual diagrams to help developers understand complex code quickly and thoroughly.
|
|
9
|
-
|
|
10
|
-
## Command Targets
|
|
11
|
-
|
|
12
|
-
**Target types:**
|
|
13
|
-
- `[function-name]` - Specific function to explain
|
|
14
|
-
- `[class-name]` - Entire class explanation
|
|
15
|
-
- `[file-path]` - Explain entire file
|
|
16
|
-
- `[line-range]` - Explain specific lines (e.g., "125-150")
|
|
17
|
-
- `current-selection` - Explain currently selected code in IDE
|
|
18
|
-
|
|
19
|
-
**Automatically includes:**
|
|
20
|
-
- Visual diagrams (flowcharts, sequence diagrams, class diagrams)
|
|
21
|
-
- Intermediate complexity level (technical but accessible)
|
|
22
|
-
- Full context (includes dependencies and related components)
|
|
23
|
-
- Saves explanations to `.code-captain/explanations/` for future reference
|
|
24
|
-
|
|
25
|
-
## Examples
|
|
26
|
-
|
|
27
|
-
```bash
|
|
28
|
-
# Explain a specific function
|
|
29
|
-
/explain-code calculateUserDiscount
|
|
30
|
-
|
|
31
|
-
# Explain a class
|
|
32
|
-
/explain-code PaymentProcessor
|
|
33
|
-
|
|
34
|
-
# Explain entire file
|
|
35
|
-
/explain-code src/auth/AuthService.js
|
|
36
|
-
|
|
37
|
-
# Explain specific line range
|
|
38
|
-
/explain-code "src/utils/helpers.js:45-78"
|
|
39
|
-
|
|
40
|
-
# Explain currently selected code
|
|
41
|
-
/explain-code current-selection
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
## Workflow Process
|
|
45
|
-
|
|
46
|
-
### Step 1: Target Identification & Location
|
|
47
|
-
|
|
48
|
-
**Locate the target code:**
|
|
49
|
-
|
|
50
|
-
- Use `find_by_name` to search for files matching the target
|
|
51
|
-
- Use `view_code_item` to locate specific functions or classes
|
|
52
|
-
- Use `grep_search` to find function/class definitions by name
|
|
53
|
-
- Use `view_file` to read file contents for line ranges or full files
|
|
54
|
-
|
|
55
|
-
**Target validation:**
|
|
56
|
-
- Confirm target exists and is accessible
|
|
57
|
-
- If ambiguous, present multiple options for user selection
|
|
58
|
-
- If not found, provide suggestions for similar names
|
|
59
|
-
|
|
60
|
-
### Step 2: Context Gathering & Analysis
|
|
61
|
-
|
|
62
|
-
**Gather comprehensive context:**
|
|
63
|
-
|
|
64
|
-
- Use `codebase_search` to understand architectural context
|
|
65
|
-
- Use `view_file` to read related files and dependencies
|
|
66
|
-
- Use `grep_search` to find all usages of the target code
|
|
67
|
-
- Use `view_code_item` to analyze related classes/functions
|
|
68
|
-
|
|
69
|
-
**Analyze code characteristics:**
|
|
70
|
-
- Parse syntax and identify patterns
|
|
71
|
-
- Measure complexity and performance characteristics
|
|
72
|
-
- Understand dependencies and integration points
|
|
73
|
-
- Identify design patterns and architectural decisions
|
|
74
|
-
|
|
75
|
-
### Step 3: Explanation Generation
|
|
76
|
-
|
|
77
|
-
**Create structured explanation:**
|
|
78
|
-
|
|
79
|
-
**📋 Code Overview**
|
|
80
|
-
- Purpose: What this code does
|
|
81
|
-
- Parameters: Input expectations and validation
|
|
82
|
-
- Return Value: What it outputs and formats
|
|
83
|
-
- Key Logic: Step-by-step breakdown of main functionality
|
|
84
|
-
|
|
85
|
-
**🔄 Execution Flow**
|
|
86
|
-
- Control flow through the code
|
|
87
|
-
- Decision points and branching logic
|
|
88
|
-
- Error handling paths and edge cases
|
|
89
|
-
- Performance characteristics and bottlenecks
|
|
90
|
-
|
|
91
|
-
**🏗️ Architecture Context**
|
|
92
|
-
- Where this fits in the overall system
|
|
93
|
-
- Dependencies and related components
|
|
94
|
-
- Design patterns and architectural decisions
|
|
95
|
-
- Integration points with other modules
|
|
96
|
-
|
|
97
|
-
**⚡ Technical Details**
|
|
98
|
-
- Time and space complexity analysis
|
|
99
|
-
- Memory usage patterns
|
|
100
|
-
- Potential issues and gotchas
|
|
101
|
-
- Optimization opportunities
|
|
102
|
-
|
|
103
|
-
### Step 4: Visual Diagram Creation
|
|
104
|
-
|
|
105
|
-
**Generate appropriate diagrams using Mermaid syntax:**
|
|
106
|
-
|
|
107
|
-
**Flowcharts:**
|
|
108
|
-
- Control flow through functions
|
|
109
|
-
- Decision trees for complex logic
|
|
110
|
-
- Error handling paths
|
|
111
|
-
|
|
112
|
-
**Sequence Diagrams:**
|
|
113
|
-
- Function call sequences
|
|
114
|
-
- API interaction flows
|
|
115
|
-
- Database transaction flows
|
|
116
|
-
|
|
117
|
-
**Class Diagrams:**
|
|
118
|
-
- Object relationships
|
|
119
|
-
- Inheritance hierarchies
|
|
120
|
-
- Dependency structures
|
|
121
|
-
|
|
122
|
-
**Example Mermaid flowchart:**
|
|
123
|
-
```mermaid
|
|
124
|
-
graph TD
|
|
125
|
-
A[Input Validation] --> B{Valid Input?}
|
|
126
|
-
B -->|Yes| C[Process Data]
|
|
127
|
-
B -->|No| D[Return Error]
|
|
128
|
-
C --> E[Apply Business Logic]
|
|
129
|
-
E --> F[Return Result]
|
|
130
|
-
D --> G[Log Error]
|
|
131
|
-
```
|
|
132
|
-
|
|
133
|
-
### Step 5: Documentation & Auto-Save
|
|
134
|
-
|
|
135
|
-
**Save explanation with date prefix:**
|
|
136
|
-
|
|
137
|
-
Use `write_to_file` to create explanation file in `.code-captain/explanations/[DATE]-[target-name].md`
|
|
138
|
-
|
|
139
|
-
**File format:**
|
|
140
|
-
```markdown
|
|
141
|
-
# Code Explanation: [Target Name]
|
|
142
|
-
|
|
143
|
-
_Generated on [DATE]_
|
|
144
|
-
|
|
145
|
-
## Overview
|
|
146
|
-
[Natural language summary of purpose and functionality]
|
|
147
|
-
|
|
148
|
-
## Execution Flow
|
|
149
|
-
```mermaid
|
|
150
|
-
[Generated diagram showing control flow]
|
|
151
|
-
```
|
|
152
|
-
|
|
153
|
-
## Detailed Breakdown
|
|
154
|
-
[Step-by-step explanation of key logic and decision points]
|
|
155
|
-
|
|
156
|
-
## Architecture Context
|
|
157
|
-
[How this code fits within the broader system architecture]
|
|
158
|
-
|
|
159
|
-
## Usage Examples
|
|
160
|
-
[Practical examples of how to use this code]
|
|
161
|
-
|
|
162
|
-
## Related Components
|
|
163
|
-
[Links to other explanations and dependencies]
|
|
164
|
-
|
|
165
|
-
## Technical Analysis
|
|
166
|
-
[Performance characteristics, complexity, and optimization notes]
|
|
167
|
-
|
|
168
|
-
---
|
|
169
|
-
_Generated by Code Captain on [timestamp]_
|
|
170
|
-
```
|
|
171
|
-
|
|
172
|
-
### Step 6: Date Determination
|
|
173
|
-
|
|
174
|
-
**Primary method - File system timestamp:**
|
|
175
|
-
1. Create directory if not exists: `.code-captain/explanations/`
|
|
176
|
-
2. Create temporary file: `.code-captain/explanations/.date-check`
|
|
177
|
-
3. Read file creation timestamp from filesystem
|
|
178
|
-
4. Extract date in YYYY-MM-DD format
|
|
179
|
-
5. Delete temporary file
|
|
180
|
-
6. Store date for file naming
|
|
181
|
-
|
|
182
|
-
**Fallback method - User confirmation:**
|
|
183
|
-
If file system method fails:
|
|
184
|
-
1. Ask user: "What is today's date? (YYYY-MM-DD format)"
|
|
185
|
-
2. Validate format matches `^\d{4}-\d{2}-\d{2}$`
|
|
186
|
-
3. Store date for file naming
|
|
187
|
-
|
|
188
|
-
### Step 7: Present Results
|
|
189
|
-
|
|
190
|
-
**Display structured explanation in chat:**
|
|
191
|
-
- Overview with purpose and key functionality
|
|
192
|
-
- Visual diagram showing execution flow
|
|
193
|
-
- Detailed breakdown of logic and decision points
|
|
194
|
-
- Architecture context and system integration
|
|
195
|
-
- Technical analysis with performance notes
|
|
196
|
-
- Usage examples and related components
|
|
197
|
-
|
|
198
|
-
**Confirm auto-save:**
|
|
199
|
-
- Notify user that explanation saved to `.code-captain/explanations/[DATE]-[target-name].md`
|
|
200
|
-
- Provide file path for future reference
|
|
201
|
-
- Mention integration with other Code Captain commands
|
|
202
|
-
|
|
203
|
-
## Output Characteristics
|
|
204
|
-
|
|
205
|
-
**Technical level:** Intermediate complexity balancing accessibility with depth
|
|
206
|
-
**Context:** Always includes related functions, dependencies, and architectural context
|
|
207
|
-
**Visual elements:** Every explanation includes appropriate diagrams
|
|
208
|
-
**Comprehensive:** Shows how code fits in the entire system
|
|
209
|
-
**Saved format:** Markdown with Mermaid diagrams for future reference
|
|
210
|
-
|
|
211
|
-
## Integration with Code Captain Ecosystem
|
|
212
|
-
|
|
213
|
-
**Cross-command integration:**
|
|
214
|
-
- Saved explanations accessible by `/research` workflow for context
|
|
215
|
-
- Referenced by `/create-spec` workflow for understanding existing patterns
|
|
216
|
-
- Used by `/execute-task` workflow for implementation guidance
|
|
217
|
-
- Integrated with other workflows for comprehensive codebase understanding
|
|
218
|
-
|
|
219
|
-
**File organization:**
|
|
220
|
-
```
|
|
221
|
-
.code-captain/
|
|
222
|
-
└── explanations/
|
|
223
|
-
├── 2024-01-15-AuthenticationFlow.md
|
|
224
|
-
├── 2024-01-16-PaymentProcessor.md
|
|
225
|
-
├── 2024-01-16-UserService.md
|
|
226
|
-
└── 2024-01-17-SearchAlgorithm.md
|
|
227
|
-
```
|
|
228
|
-
|
|
229
|
-
Files named: `[DATE]-[target-name].md` (YYYY-MM-DD format)
|
|
230
|
-
|
|
231
|
-
## Error Handling
|
|
232
|
-
|
|
233
|
-
**Common issues and responses:**
|
|
234
|
-
- **Code not found**: "Could not locate [target]. Please check the path/name." Use `find_by_name` to suggest alternatives
|
|
235
|
-
- **Too complex**: "This code is very complex. Consider breaking into smaller explanations."
|
|
236
|
-
- **Limited context**: "Some context may be missing. Ensure related files are accessible."
|
|
237
|
-
|
|
238
|
-
**Fallback behaviors:**
|
|
239
|
-
- If diagrams fail to generate, provide text-based flow description
|
|
240
|
-
- If target is ambiguous, offer multiple options using `grep_search` results
|
|
241
|
-
- If code is too large, suggest breaking into smaller segments
|
|
242
|
-
|
|
243
|
-
**Resolution strategies:**
|
|
244
|
-
1. Use `codebase_search` to find alternative approaches
|
|
245
|
-
2. Break complex code into logical segments
|
|
246
|
-
3. Provide partial explanations with clear boundaries
|
|
247
|
-
4. Suggest related files or functions for additional context
|
|
248
|
-
|
|
249
|
-
## Diagram Types
|
|
250
|
-
|
|
251
|
-
**Flowcharts:** Control flow, decision trees, error handling paths
|
|
252
|
-
**Sequence diagrams:** Function calls, API interactions, database transactions
|
|
253
|
-
**Class diagrams:** Object relationships, inheritance, dependencies
|
|
254
|
-
**Architecture diagrams:** Component interactions, data flow, service communication
|
|
255
|
-
|
|
256
|
-
## Management Features
|
|
257
|
-
|
|
258
|
-
**Explanation discovery:**
|
|
259
|
-
- Use `find_by_name` to list all saved explanations
|
|
260
|
-
- Use `grep_search` to search explanation content
|
|
261
|
-
- Use `view_file` to read previous explanations for context
|
|
262
|
-
|
|
263
|
-
**Update detection:**
|
|
264
|
-
- Compare file modification times with explanation dates
|
|
265
|
-
- Suggest refreshing explanations for changed code
|
|
266
|
-
- Maintain explanation history and versioning
|
|
267
|
-
|
|
268
|
-
## Quality Standards
|
|
269
|
-
|
|
270
|
-
**Clarity:** Explanations understandable to developers at intermediate level
|
|
271
|
-
**Completeness:** Cover purpose, logic, context, and technical details
|
|
272
|
-
**Accuracy:** Reflect actual code behavior and architectural patterns
|
|
273
|
-
**Visual:** Include appropriate diagrams for better understanding
|
|
274
|
-
**Consistency:** Use standard format and terminology across explanations
|
|
275
|
-
|
|
276
|
-
## Windsurf Tools Used
|
|
277
|
-
|
|
278
|
-
- `find_by_name`: Locate target files, functions, and classes
|
|
279
|
-
- `view_file`: Read file contents and related code
|
|
280
|
-
- `view_code_item`: Examine specific code elements (classes, functions)
|
|
281
|
-
- `codebase_search`: Understand architectural context and dependencies
|
|
282
|
-
- `grep_search`: Find function definitions, usages, and patterns
|
|
283
|
-
- `write_to_file`: Save explanations to dated files
|
|
284
|
-
- `list_dir`: Explore directory structure for context
|
|
285
|
-
|
|
286
|
-
## Windsurf Features Used
|
|
287
|
-
|
|
288
|
-
- **Memories**: After explaining complex architectural patterns, ask Cascade to "create a memory of this architectural pattern and its usage"
|
|
289
|
-
|
|
290
|
-
---
|
|
291
|
-
|
|
292
|
-
*🧠 Understanding code through comprehensive explanation and visual insight.*
|
|
@@ -1,298 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Set up technical foundation and development infrastructure for greenfield or brownfield projects
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Initialize Workflow
|
|
6
|
-
|
|
7
|
-
## Overview
|
|
8
|
-
Set up technical foundation and development infrastructure by detecting if this is a greenfield (new) or brownfield (existing) project and executing the appropriate technical setup workflow.
|
|
9
|
-
|
|
10
|
-
## Detection Logic
|
|
11
|
-
|
|
12
|
-
**Scan current directory for indicators:**
|
|
13
|
-
- Presence of package.json, requirements.txt, Cargo.toml, go.mod, etc.
|
|
14
|
-
- Existing source code directories (src/, lib/, app/, etc.)
|
|
15
|
-
- Git repository status
|
|
16
|
-
- Configuration files
|
|
17
|
-
|
|
18
|
-
**Classify as:**
|
|
19
|
-
- **Greenfield**: Empty directory or minimal files
|
|
20
|
-
- **Brownfield**: Existing codebase with established structure
|
|
21
|
-
|
|
22
|
-
## Workflow Process
|
|
23
|
-
|
|
24
|
-
### Step 1: Project Type Detection
|
|
25
|
-
|
|
26
|
-
**Use Windsurf tools to analyze project state:**
|
|
27
|
-
|
|
28
|
-
- Use `list_dir` to scan current directory structure
|
|
29
|
-
- Use `find_by_name` to search for common project files (package.json, requirements.txt, etc.)
|
|
30
|
-
- Use `view_file` to check existing configuration files
|
|
31
|
-
- Use `codebase_search` to understand existing code patterns and architecture
|
|
32
|
-
|
|
33
|
-
**Detection criteria:**
|
|
34
|
-
- **Greenfield indicators**: Empty/minimal directory, no dependency files, no src/ directories
|
|
35
|
-
- **Brownfield indicators**: Existing dependency files, established directory structure, source code present
|
|
36
|
-
|
|
37
|
-
### Step 2A: Greenfield Workflow (New Projects)
|
|
38
|
-
|
|
39
|
-
**Phase 1: Technical Foundation Setup**
|
|
40
|
-
|
|
41
|
-
**Ask focused technical questions:**
|
|
42
|
-
1. **Project Type**: "What type of application are you building? (web app, API, mobile app, library, CLI tool, etc.)"
|
|
43
|
-
2. **Technical Constraints**: "Any required technologies, frameworks, or platforms?"
|
|
44
|
-
3. **Development Environment**: "What's your preferred development setup? (local, containerized, cloud-based)"
|
|
45
|
-
4. **Scale Requirements**: "Expected technical scale? (prototype, small team, enterprise)"
|
|
46
|
-
|
|
47
|
-
**Phase 2: Technology Recommendations**
|
|
48
|
-
|
|
49
|
-
Based on technical requirements, recommend:
|
|
50
|
-
- **Tech Stack**: Languages, frameworks, databases suitable for the project type
|
|
51
|
-
- **Architecture Pattern**: Monolith, microservices, serverless based on scale needs
|
|
52
|
-
- **Development Tools**: Testing frameworks, build tools, linting/formatting
|
|
53
|
-
- **Project Structure**: Directory layout, naming conventions, configuration
|
|
54
|
-
|
|
55
|
-
**Phase 3: Technical Foundation Setup**
|
|
56
|
-
|
|
57
|
-
**Create project structure:**
|
|
58
|
-
- Use `write_to_file` to create package/dependency files (package.json, requirements.txt, etc.)
|
|
59
|
-
- Use `write_to_file` to create Git configuration (.gitignore, .gitattributes)
|
|
60
|
-
- Use `write_to_file` to create development configuration (prettier, eslint, testing config)
|
|
61
|
-
- Use `write_to_file` to create build and deployment configuration (if applicable)
|
|
62
|
-
|
|
63
|
-
**Documentation Creation:**
|
|
64
|
-
|
|
65
|
-
1. **`.code-captain/docs/tech-stack.md`** - Technology stack decisions and rationale
|
|
66
|
-
2. **`.code-captain/docs/code-style.md`** - Coding standards and development patterns
|
|
67
|
-
3. **`README.md`** - Technical overview and setup instructions
|
|
68
|
-
|
|
69
|
-
**Tech Stack Documentation Template:**
|
|
70
|
-
```markdown
|
|
71
|
-
# Technology Stack
|
|
72
|
-
|
|
73
|
-
## Languages
|
|
74
|
-
- [Primary language with version]
|
|
75
|
-
- [Secondary languages if any]
|
|
76
|
-
|
|
77
|
-
## Frameworks & Libraries
|
|
78
|
-
- [Main framework with version and purpose]
|
|
79
|
-
- [Key dependencies with purposes]
|
|
80
|
-
|
|
81
|
-
## Infrastructure
|
|
82
|
-
- [Database technology]
|
|
83
|
-
- [Deployment platform]
|
|
84
|
-
- [CI/CD tools]
|
|
85
|
-
|
|
86
|
-
## Development Tools
|
|
87
|
-
- [Package manager]
|
|
88
|
-
- [Testing framework]
|
|
89
|
-
- [Linting/formatting tools]
|
|
90
|
-
|
|
91
|
-
## Architecture Pattern
|
|
92
|
-
[Monolith/Microservices/Serverless/etc. with reasoning]
|
|
93
|
-
```
|
|
94
|
-
|
|
95
|
-
**Code Style Documentation Template:**
|
|
96
|
-
```markdown
|
|
97
|
-
# Code Style Guide
|
|
98
|
-
|
|
99
|
-
## File Organization
|
|
100
|
-
[Directory structure patterns]
|
|
101
|
-
|
|
102
|
-
## Naming Conventions
|
|
103
|
-
- [Variable naming patterns]
|
|
104
|
-
- [Function naming patterns]
|
|
105
|
-
- [File naming patterns]
|
|
106
|
-
|
|
107
|
-
## Code Patterns
|
|
108
|
-
[Common patterns for the technology stack]
|
|
109
|
-
|
|
110
|
-
## Testing Patterns
|
|
111
|
-
[How tests are structured and named]
|
|
112
|
-
|
|
113
|
-
## Documentation Style
|
|
114
|
-
[Comment and documentation patterns]
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
### Step 2B: Brownfield Workflow (Existing Projects)
|
|
118
|
-
|
|
119
|
-
**Phase 1: Codebase Analysis**
|
|
120
|
-
|
|
121
|
-
**Scan and analyze existing project:**
|
|
122
|
-
- Use `codebase_search` to understand overall architecture and patterns
|
|
123
|
-
- Use `list_dir` to analyze file structure and organization patterns
|
|
124
|
-
- Use `view_file` to examine dependencies and technology stack
|
|
125
|
-
- Use `grep_search` to find code patterns, conventions, and architecture
|
|
126
|
-
- Use `view_file` to review configuration files and build processes
|
|
127
|
-
- Use `find_by_name` to locate testing setup and development tools
|
|
128
|
-
- Use `codebase_search` to identify documentation gaps and technical debt
|
|
129
|
-
|
|
130
|
-
**Analysis areas:**
|
|
131
|
-
- **File structure** and organization patterns
|
|
132
|
-
- **Dependencies** and technology stack
|
|
133
|
-
- **Code patterns**, conventions, and architecture
|
|
134
|
-
- **Configuration files** and build processes
|
|
135
|
-
- **Testing setup** and development tools
|
|
136
|
-
- **Documentation gaps** and technical debt
|
|
137
|
-
|
|
138
|
-
**Phase 2: Documentation Generation**
|
|
139
|
-
|
|
140
|
-
**Create comprehensive technical documentation:**
|
|
141
|
-
|
|
142
|
-
Use `write_to_file` to create:
|
|
143
|
-
|
|
144
|
-
1. **`.code-captain/docs/tech-stack.md`** - Current technology stack analysis
|
|
145
|
-
2. **`.code-captain/docs/code-style.md`** - Observed code patterns and conventions
|
|
146
|
-
3. **`.code-captain/docs/architecture.md`** - System architecture and technical decisions (if complex)
|
|
147
|
-
|
|
148
|
-
**Phase 3: Gap Analysis & Recommendations**
|
|
149
|
-
|
|
150
|
-
Identify and document:
|
|
151
|
-
- **Missing technical documentation**
|
|
152
|
-
- **Inconsistent code patterns**
|
|
153
|
-
- **Technical debt and improvement opportunities**
|
|
154
|
-
- **Testing coverage gaps**
|
|
155
|
-
- **Development workflow improvements**
|
|
156
|
-
- **Architecture optimization opportunities**
|
|
157
|
-
|
|
158
|
-
### Step 3: Directory Structure Setup
|
|
159
|
-
|
|
160
|
-
**Ensure Code Captain structure exists:**
|
|
161
|
-
|
|
162
|
-
Use `list_dir` to check and `write_to_file` to create if missing:
|
|
163
|
-
|
|
164
|
-
```
|
|
165
|
-
.code-captain/
|
|
166
|
-
├── docs/
|
|
167
|
-
│ ├── best-practices.md # Development best practices (pre-installed)
|
|
168
|
-
│ ├── code-style.md # Code conventions and patterns
|
|
169
|
-
│ ├── tech-stack.md # Technology decisions and rationale
|
|
170
|
-
│ └── architecture.md # System architecture (if complex)
|
|
171
|
-
└── research/ # Research outputs and technical analysis
|
|
172
|
-
```
|
|
173
|
-
|
|
174
|
-
### Step 4: Final Steps & Guidance
|
|
175
|
-
|
|
176
|
-
**For Greenfield Projects:**
|
|
177
|
-
```
|
|
178
|
-
🚀 Technical Foundation Complete!
|
|
179
|
-
|
|
180
|
-
Your development environment is now set up and documented:
|
|
181
|
-
- Technology stack documented and configured
|
|
182
|
-
- Development tools and standards established
|
|
183
|
-
- Project structure and configuration ready
|
|
184
|
-
|
|
185
|
-
## Recommended Next Steps:
|
|
186
|
-
|
|
187
|
-
### For Product Strategy (Recommended First):
|
|
188
|
-
/plan-product "your product idea" - Define product vision, strategy, and roadmap
|
|
189
|
-
|
|
190
|
-
### For Feature Development:
|
|
191
|
-
/create-spec "feature description" - Create detailed feature specifications
|
|
192
|
-
/execute-task - Implement features with TDD workflow
|
|
193
|
-
|
|
194
|
-
### For Research:
|
|
195
|
-
/research "topic" - Conduct systematic technical research
|
|
196
|
-
/create-adr "decision" - Document architectural decisions
|
|
197
|
-
|
|
198
|
-
Ready to define your product strategy and start building!
|
|
199
|
-
```
|
|
200
|
-
|
|
201
|
-
**For Brownfield Projects:**
|
|
202
|
-
```
|
|
203
|
-
🔍 Technical Foundation Analysis Complete!
|
|
204
|
-
|
|
205
|
-
Your existing project has been analyzed and documented:
|
|
206
|
-
- Current technology stack and architecture documented
|
|
207
|
-
- Code patterns and conventions identified
|
|
208
|
-
- Technical gaps and improvement opportunities noted
|
|
209
|
-
|
|
210
|
-
## Recommended Next Steps:
|
|
211
|
-
|
|
212
|
-
### For Product Strategy (Recommended First):
|
|
213
|
-
/plan-product "enhanced product vision" - Define product strategy and roadmap
|
|
214
|
-
|
|
215
|
-
### For Feature Development:
|
|
216
|
-
/create-spec "feature description" - Create detailed feature specifications
|
|
217
|
-
/execute-task - Implement features following established patterns
|
|
218
|
-
|
|
219
|
-
### For Technical Improvements:
|
|
220
|
-
/research "technical topic" - Research solutions for identified gaps
|
|
221
|
-
/create-adr "technical decision" - Document architectural improvements
|
|
222
|
-
|
|
223
|
-
Ready to define your product strategy and enhance your codebase!
|
|
224
|
-
```
|
|
225
|
-
|
|
226
|
-
## Integration with Code Captain Ecosystem
|
|
227
|
-
|
|
228
|
-
**Workflow relationship:**
|
|
229
|
-
- **Initialize** handles ONLY technical foundation
|
|
230
|
-
- **/plan-product** handles product strategy and vision
|
|
231
|
-
- Users need both for complete project setup
|
|
232
|
-
- **/plan-product** should be the next step before feature development
|
|
233
|
-
|
|
234
|
-
**Cross-workflow integration:**
|
|
235
|
-
- Documentation created here used by `/create-spec` for understanding patterns
|
|
236
|
-
- Tech stack analysis used by `/execute-task` for implementation guidance
|
|
237
|
-
- Architecture documentation used by `/create-adr` for decision context
|
|
238
|
-
- Gap analysis used by `/research` for improvement priorities
|
|
239
|
-
|
|
240
|
-
## Technical Implementation
|
|
241
|
-
|
|
242
|
-
**File creation process:**
|
|
243
|
-
1. Use `write_to_file` to create all documentation files
|
|
244
|
-
2. Ensure `.code-captain/docs/` directory exists
|
|
245
|
-
3. Create comprehensive content in each file
|
|
246
|
-
4. Verify file paths match expected locations
|
|
247
|
-
|
|
248
|
-
**Analysis process:**
|
|
249
|
-
- Use `codebase_search` for semantic understanding of existing code
|
|
250
|
-
- Use `find_by_name` for discovering project files and patterns
|
|
251
|
-
- Use `view_file` for examining specific configuration and code files
|
|
252
|
-
- Use `grep_search` for finding specific patterns and conventions
|
|
253
|
-
|
|
254
|
-
## Quality Standards
|
|
255
|
-
|
|
256
|
-
**Documentation completeness:**
|
|
257
|
-
- Tech stack with versions and justifications
|
|
258
|
-
- Code style with observable patterns
|
|
259
|
-
- Architecture decisions and rationale
|
|
260
|
-
- Clear setup and development instructions
|
|
261
|
-
|
|
262
|
-
**Analysis thoroughness:**
|
|
263
|
-
- Complete technology inventory
|
|
264
|
-
- Consistent pattern identification
|
|
265
|
-
- Gap analysis with actionable recommendations
|
|
266
|
-
- Integration point documentation
|
|
267
|
-
|
|
268
|
-
## Error Handling
|
|
269
|
-
|
|
270
|
-
**Common scenarios:**
|
|
271
|
-
- **Empty directory**: Proceed with greenfield workflow
|
|
272
|
-
- **Ambiguous project type**: Ask user for clarification
|
|
273
|
-
- **Missing permissions**: Guide user to resolve access issues
|
|
274
|
-
- **Complex architecture**: Break analysis into smaller components
|
|
275
|
-
|
|
276
|
-
**Fallback strategies:**
|
|
277
|
-
- If automated detection fails, ask user directly
|
|
278
|
-
- If file creation fails, provide manual instructions
|
|
279
|
-
- If analysis is incomplete, document known limitations
|
|
280
|
-
- If tools fail, provide alternative approaches
|
|
281
|
-
|
|
282
|
-
## Windsurf Tools Used
|
|
283
|
-
|
|
284
|
-
- `list_dir`: Explore project directory structure and organization
|
|
285
|
-
- `find_by_name`: Locate project files, configurations, and dependencies
|
|
286
|
-
- `view_file`: Examine existing code, configurations, and documentation
|
|
287
|
-
- `write_to_file`: Create technical documentation and configuration files
|
|
288
|
-
- `codebase_search`: Understand architecture, patterns, and codebase structure
|
|
289
|
-
- `grep_search`: Find specific patterns, conventions, and code structures
|
|
290
|
-
- `run_command`: Execute setup commands and validate configurations
|
|
291
|
-
|
|
292
|
-
## Windsurf Features Used
|
|
293
|
-
|
|
294
|
-
- **Memories**: After setup completion, ask Cascade to "create a memory of the technology stack and architectural decisions"
|
|
295
|
-
|
|
296
|
-
---
|
|
297
|
-
|
|
298
|
-
*🏗️ Building solid technical foundations for sustainable development.*
|