@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,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,213 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Code Captain status report for project orientation and next actions
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Code Captain Status Workflow
|
|
6
|
-
|
|
7
|
-
## Overview
|
|
8
|
-
Provides comprehensive status report when starting work or switching context. Analyzes git state, active work, and project health to orient developers and suggest next actions.
|
|
9
|
-
|
|
10
|
-
## Core Functionality
|
|
11
|
-
|
|
12
|
-
### 1. Git Status & Context Analysis
|
|
13
|
-
Use `run_command` to gather git information:
|
|
14
|
-
- Current branch and relationship to main/origin
|
|
15
|
-
- Commits ahead/behind main branch
|
|
16
|
-
- Last commit message and timestamp
|
|
17
|
-
- Uncommitted changes summary
|
|
18
|
-
- Stash status
|
|
19
|
-
|
|
20
|
-
### 2. Active Work Detection
|
|
21
|
-
Use `codebase_search` and `view_file` to find:
|
|
22
|
-
- Code Captain specs in `.code-captain/specs/`
|
|
23
|
-
- Current task progress from most recent spec
|
|
24
|
-
- Completed vs pending tasks
|
|
25
|
-
- Current user story context
|
|
26
|
-
|
|
27
|
-
### 3. Project Health Check
|
|
28
|
-
Use `run_command` for language-specific checks:
|
|
29
|
-
- Can the project build/compile?
|
|
30
|
-
- Dependencies status (package.json, requirements.txt, etc.)
|
|
31
|
-
- Configuration issues
|
|
32
|
-
- Missing environment variables
|
|
33
|
-
|
|
34
|
-
### 4. Contextual Suggestions
|
|
35
|
-
Based on current state, suggest appropriate next commands.
|
|
36
|
-
|
|
37
|
-
## Implementation Steps
|
|
38
|
-
|
|
39
|
-
### Step 1: Git Analysis
|
|
40
|
-
```bash
|
|
41
|
-
# Use run_command for these git operations:
|
|
42
|
-
git status --porcelain # File changes
|
|
43
|
-
git log --oneline -5 # Recent commits
|
|
44
|
-
git log main..HEAD --oneline # Commits ahead
|
|
45
|
-
git log HEAD..main --oneline # Commits behind
|
|
46
|
-
git stash list # Stashed changes
|
|
47
|
-
git branch -v # Branch info
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
### Step 2: Code Captain Integration
|
|
51
|
-
Use `find_by_name` to locate specs:
|
|
52
|
-
```bash
|
|
53
|
-
# Find most recent spec directory
|
|
54
|
-
find .code-captain/specs -name "spec.md" -type f
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
Use `view_file` to read spec content and task progress:
|
|
58
|
-
- Read overall progress from user stories overview
|
|
59
|
-
- Parse individual story files for task completion
|
|
60
|
-
- Count completed tasks (marked with [x])
|
|
61
|
-
- Find next incomplete task
|
|
62
|
-
|
|
63
|
-
### Step 3: Project Health
|
|
64
|
-
Use `run_command` for health checks:
|
|
65
|
-
```bash
|
|
66
|
-
# Node.js
|
|
67
|
-
npm run build --if-present
|
|
68
|
-
node -c package.json
|
|
69
|
-
|
|
70
|
-
# Python
|
|
71
|
-
python -m py_compile main.py
|
|
72
|
-
pip check
|
|
73
|
-
```
|
|
74
|
-
|
|
75
|
-
### Step 4: Generate Status Report
|
|
76
|
-
|
|
77
|
-
**Output Format** (clean formatted text, not code blocks):
|
|
78
|
-
|
|
79
|
-
```
|
|
80
|
-
⚓ Code Captain Status Report
|
|
81
|
-
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
82
|
-
|
|
83
|
-
📍 CURRENT POSITION
|
|
84
|
-
Branch: feature/dashboard-websockets (2 commits ahead of main)
|
|
85
|
-
Last commit: "Add WebSocket connection hook" (2 hours ago)
|
|
86
|
-
Uncommitted: 3 modified files in src/components/
|
|
87
|
-
|
|
88
|
-
📋 ACTIVE WORK
|
|
89
|
-
Spec: Real-time Dashboard with WebSocket Integration
|
|
90
|
-
Progress: Story 2 (User receives real-time notifications) - In Progress
|
|
91
|
-
Tasks completed: 3/6 tasks (50%)
|
|
92
|
-
Next task: 2.4 Implement client-side WebSocket connection
|
|
93
|
-
|
|
94
|
-
🎯 SUGGESTED ACTIONS
|
|
95
|
-
• Continue with task 2.4 (WebSocket connection management)
|
|
96
|
-
• Commit current changes before switching tasks
|
|
97
|
-
• Review recent main branch changes
|
|
98
|
-
|
|
99
|
-
⚡ QUICK COMMANDS
|
|
100
|
-
Execute task workflow # Continue current task
|
|
101
|
-
Code cleanup workflow # Quick code improvements
|
|
102
|
-
Sync main workflow # Pull latest from main
|
|
103
|
-
```
|
|
104
|
-
|
|
105
|
-
## Task Progress Analysis
|
|
106
|
-
|
|
107
|
-
### Parsing Logic
|
|
108
|
-
For each story file in `user-stories/story-N-{name}.md`:
|
|
109
|
-
|
|
110
|
-
1. **Count completed tasks**:
|
|
111
|
-
```bash
|
|
112
|
-
grep -c "^\- \[x\].*✅" story-file.md
|
|
113
|
-
```
|
|
114
|
-
|
|
115
|
-
2. **Count total tasks**:
|
|
116
|
-
```bash
|
|
117
|
-
grep -c "^\- \[[x ]\]" story-file.md
|
|
118
|
-
```
|
|
119
|
-
|
|
120
|
-
3. **Find next incomplete task**:
|
|
121
|
-
```bash
|
|
122
|
-
grep -n "^\- \[ \]" story-file.md | head -1
|
|
123
|
-
```
|
|
124
|
-
|
|
125
|
-
4. **Extract status from story header**:
|
|
126
|
-
```bash
|
|
127
|
-
grep "^> \*\*Status:\*\*" story-file.md
|
|
128
|
-
```
|
|
129
|
-
|
|
130
|
-
### Status Detection
|
|
131
|
-
- `Not Started` - No tasks completed
|
|
132
|
-
- `In Progress` - Some tasks completed, some remaining
|
|
133
|
-
- `Completed ✅` - All tasks and acceptance criteria completed
|
|
134
|
-
|
|
135
|
-
## Error Handling
|
|
136
|
-
|
|
137
|
-
### Not a Git Repository
|
|
138
|
-
```
|
|
139
|
-
❌ Not in a git repository
|
|
140
|
-
Initialize git first: git init
|
|
141
|
-
```
|
|
142
|
-
|
|
143
|
-
### No Code Captain Structure
|
|
144
|
-
```
|
|
145
|
-
📋 ACTIVE WORK
|
|
146
|
-
No Code Captain specifications found
|
|
147
|
-
Project structure: Standard git repository
|
|
148
|
-
|
|
149
|
-
🎯 SUGGESTED ACTIONS
|
|
150
|
-
• Set up Code Captain workflow
|
|
151
|
-
• Create first feature specification
|
|
152
|
-
```
|
|
153
|
-
|
|
154
|
-
### Project Issues
|
|
155
|
-
```
|
|
156
|
-
⚠️ PROJECT ISSUES DETECTED
|
|
157
|
-
• package.json syntax error
|
|
158
|
-
• Missing critical dependencies
|
|
159
|
-
• Build process failing
|
|
160
|
-
|
|
161
|
-
🔧 SUGGESTED FIXES
|
|
162
|
-
• Fix package.json syntax
|
|
163
|
-
• Run npm install or equivalent
|
|
164
|
-
• Check build configuration
|
|
165
|
-
```
|
|
166
|
-
|
|
167
|
-
## Decision Tree for Suggestions
|
|
168
|
-
|
|
169
|
-
1. **Merge conflict?** → Suggest conflict resolution
|
|
170
|
-
2. **Working directory dirty?** → Suggest commit or stash
|
|
171
|
-
3. **Branch behind main?** → Suggest sync
|
|
172
|
-
4. **Active task?** → Suggest continue task
|
|
173
|
-
5. **Current task complete?** → Suggest next task
|
|
174
|
-
6. **No active work?** → Suggest create spec
|
|
175
|
-
7. **Always** → Suggest code cleanup
|
|
176
|
-
|
|
177
|
-
## Usage Patterns
|
|
178
|
-
|
|
179
|
-
### Morning Routine
|
|
180
|
-
Developer starts day, gets oriented on yesterday's work, sees exactly what to do next.
|
|
181
|
-
|
|
182
|
-
### Context Switching
|
|
183
|
-
After meetings or interruptions, quick reminder of current state, resume work efficiently.
|
|
184
|
-
|
|
185
|
-
### Project Handoff
|
|
186
|
-
When picking up someone else's work, understand current project state without diving into code.
|
|
187
|
-
|
|
188
|
-
## Performance Considerations
|
|
189
|
-
|
|
190
|
-
- Target <2 second execution time
|
|
191
|
-
- Limit git log queries to reasonable ranges
|
|
192
|
-
- Cache expensive operations when possible
|
|
193
|
-
- Use efficient file scanning with `find_by_name`
|
|
194
|
-
|
|
195
|
-
## Windsurf Tools Used
|
|
196
|
-
|
|
197
|
-
- `run_command`: Git operations, build checks
|
|
198
|
-
- `codebase_search`: Find specs and project structure
|
|
199
|
-
- `view_file`: Read spec content and progress
|
|
200
|
-
- `find_by_name`: Locate Code Captain files
|
|
201
|
-
- `grep_search`: Parse task completion status
|
|
202
|
-
- `list_dir`: Directory structure analysis
|
|
203
|
-
|
|
204
|
-
## Security & Privacy
|
|
205
|
-
|
|
206
|
-
- All analysis happens locally
|
|
207
|
-
- No external API calls or data transmission
|
|
208
|
-
- Git history and file contents remain private
|
|
209
|
-
- Sanitize sensitive information in output
|
|
210
|
-
|
|
211
|
-
---
|
|
212
|
-
|
|
213
|
-
*⚓ Keep your bearings, maintain your heading, and always know where you stand in the code.*
|