@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,298 @@
|
|
|
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.*
|
|
@@ -0,0 +1,321 @@
|
|
|
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.*
|