ai-prompt-guide-mcp 1.0.1 → 1.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.
@@ -0,0 +1,91 @@
1
+ ---
2
+ title: "Decide (Iterate)"
3
+ description: "⚖️ DECISION: Multi-perspective decision analysis with parallel specialist agents"
4
+ whenToUse: "Complex decisions requiring multiple viewpoints or when trade-offs span different quality dimensions"
5
+ ---
6
+
7
+ # Workflow: Multi-Perspective Decision Making
8
+
9
+ ⚠️ **CRITICAL REQUIREMENTS - You MUST follow these instructions:**
10
+
11
+ **Task Management:**
12
+ - ✅ **REQUIRED:** Use `subagent_task` tool to create analysis tasks for each lens
13
+ - 🚫 **FORBIDDEN:** DO NOT use TodoWrite tool (use subagent_task instead)
14
+
15
+ **Delegation:**
16
+ - ✅ **REQUIRED:** Give subagents literal instructions to run start_subagent_task
17
+ - 🚫 **FORBIDDEN:** DO NOT run start_subagent_task yourself (coordinator only delegates)
18
+
19
+ 1. [Coordinator] Define decision specification:
20
+ • Problem statement and context
21
+ • Non-negotiable constraints
22
+ • Evaluation criteria (4-6) with project weights
23
+ • Evidence requirements
24
+
25
+ 2. [Coordinator] Select 3-5 analysis lenses from standard set
26
+ 3. [Coordinator] Use subagent_task to create analysis task for each lens:
27
+ • Specify lens focus (performance, UX, maintainability, etc.)
28
+ • Add @references to codebase patterns, constraints, requirements
29
+ Format: @/docs/architecture/patterns or @/docs/constraints#performance
30
+ • Define evidence requirements for this lens
31
+
32
+ 4. [Coordinator] Launch all lens specialist agents simultaneously in parallel
33
+
34
+ 5. [Specialists - Parallel Execution] Each specialist independently:
35
+ • Generate 2-4 viable options optimized for lens priority
36
+ • Document each option: description, assumptions, pros/cons, evidence, pattern alignment
37
+ • Create decision matrix with lens-specific weights
38
+ • Select best option for this lens → recommended_option
39
+ • Document rationale and key trade-offs
40
+ • Return recommendation to coordinator
41
+
42
+ 6. [Coordinator] Collect all lens recommendations
43
+ 7. [Coordinator] Verify options are meaningfully distinct (interface, structure, approach)
44
+ 8. [Coordinator] Enforce non-negotiables → drop violators
45
+ 9. [Coordinator] Identify hybridization opportunities (combine strengths from multiple lenses)
46
+ 10. [Coordinator] Create global decision matrix with project-level weights
47
+ 11. [Coordinator] Select final option (highest score or reasoned choice)
48
+ 12. [Coordinator] Document decision:
49
+ • Why this option wins
50
+ • Why NOT other options (key discriminators)
51
+ • Trade-offs and follow-up actions
52
+ 13. [Coordinator] Record rationale with matrix, evidence, disqualifiers
53
+
54
+ ## Analysis Lenses
55
+
56
+ **Performance:**
57
+ - Runtime efficiency, memory usage, throughput
58
+ - Focus: algorithmic complexity, resource optimization
59
+
60
+ **UX/Ergonomics:**
61
+ - API clarity, cognitive load, sensible defaults
62
+ - Focus: developer experience, ease of use
63
+
64
+ **Maintainability:**
65
+ - Readability, long-term health, minimal churn
66
+ - Focus: code longevity, team velocity
67
+
68
+ **Pattern Consistency:**
69
+ - Alignment with existing idioms, error handling, conventions
70
+ - Focus: cognitive load reduction, team familiarity
71
+
72
+ **Risk/Security:**
73
+ - Failure modes, dependency risks, attack surface
74
+ - Focus: robustness, safety, production readiness
75
+
76
+ **Simplicity Baseline:**
77
+ - Minimal moving parts, boring solutions, proven approaches
78
+ - Focus: lowest viable complexity
79
+
80
+ ## Evaluation Guidelines
81
+
82
+ **Per-Lens Analysis:**
83
+ - Generate options optimized for lens priority
84
+ - Score 0-10 per criterion with lens-specific weights
85
+ - Select single best option for that perspective
86
+
87
+ **Global Synthesis:**
88
+ - Use project-level weights across all criteria
89
+ - Consider hybrid solutions combining lens strengths
90
+ - Disqualify any option failing non-negotiables
91
+ - Explicitly justify why complex option beats simple baseline
@@ -0,0 +1,46 @@
1
+ ---
2
+ title: "Decide"
3
+ description: "⚖️ DECISION: Choose between multiple approaches with structured trade-off analysis"
4
+ whenToUse: "Multiple valid implementation approaches or architecture/optimization decisions with trade-offs to evaluate"
5
+ ---
6
+
7
+ # Workflow: Structured Decision Making
8
+
9
+ 1. [Agent] Identify decision point and constraints
10
+ 2. [Agent] Generate 2-4 viable options (include simple baseline)
11
+ 3. [Agent] Document each option:
12
+ • Description: 1-2 sentence summary
13
+ • Assumptions: what must be true for this to work
14
+ • Pros: benefits, advantages, strengths
15
+ • Cons: drawbacks, risks, limitations
16
+ • Evidence: documentation, prior art, examples
17
+ • Pattern alignment: fits existing codebase patterns
18
+
19
+ 4. [Agent] Select 4-6 evaluation criteria:
20
+ • Correctness: solves problem accurately
21
+ • Risk: failure modes and likelihood
22
+ • Pattern Consistency: aligns with codebase conventions
23
+ • Maintainability: long-term code health
24
+ • Testability: ease of verification
25
+ • Simplicity: minimal complexity for requirements
26
+ • Performance: efficiency (if applicable)
27
+
28
+ 5. [Agent] Create decision matrix:
29
+ • Score each option per criterion (0-10 scale)
30
+ • Apply weights based on project priorities
31
+ • Calculate: Score = Σ (weight × normalized_criterion)
32
+
33
+ 6. [Agent] Select highest-scoring option
34
+ 7. [Agent] Document why NOT the other options (key disqualifiers)
35
+ 8. [Agent] Record decision rationale for future reference
36
+
37
+ ## Scoring Guidelines
38
+
39
+ **Weights:**
40
+ - High weight (3-5): Critical project priorities
41
+ - Medium weight (2): Important but negotiable
42
+ - Low weight (1): Nice-to-have considerations
43
+
44
+ **Disqualification:**
45
+ - Options failing non-negotiable requirements score 0 regardless of other merits
46
+ - Simple option losing to complex requires explicit justification
@@ -0,0 +1,291 @@
1
+ ---
2
+ title: "Fix"
3
+ description: "🐛 FIX: Systematic bug fixing with root cause analysis and regression prevention"
4
+ whenToUse: "Debugging issues, fixing bugs, resolving errors with minimal scope and anti-pattern detection"
5
+ ---
6
+
7
+ # Workflow: Bug Fix with Root Cause Analysis
8
+
9
+ ⚠️ **CRITICAL REQUIREMENTS - You MUST follow these instructions:**
10
+
11
+ **Task Management:**
12
+ - ✅ **REQUIRED:** Use `coordinator_task` tool for your TODO list
13
+ - 🚫 **FORBIDDEN:** DO NOT use TodoWrite tool (this workflow replaces it)
14
+
15
+ 1. [Agent] Reproduce the bug and document current behavior:
16
+ • What is the expected behavior?
17
+ • What is the actual (buggy) behavior?
18
+ • How to reproduce it (steps, inputs, conditions)?
19
+ • What error messages or symptoms appear?
20
+ • Write out your observations
21
+
22
+ 2. [Agent] Map the complete data flow:
23
+ • **Input:** What data enters the system? (user input, API data, props, etc.)
24
+ • **Processing:** What transformations/logic occur? (step by step)
25
+ • **Output:** What is produced? (UI update, API call, state change, etc.)
26
+ • Draw out or write the flow path
27
+ • Identify all components/functions involved
28
+
29
+ 3. [Agent] Identify the exact failure point:
30
+ • Where in the flow does the bug occur?
31
+ • Which function/component/line is responsible?
32
+ • What is the state/data at the failure point?
33
+ • Write out what you discovered
34
+
35
+ 4. [Agent] Perform root cause analysis (write this out):
36
+ • WHY does the bug occur? (not just WHERE)
37
+ • What assumption is violated?
38
+ • What condition is not handled?
39
+ • Is this a symptom of a deeper issue?
40
+ • Could this bug occur elsewhere with the same root cause?
41
+
42
+ 5. [Agent] Define minimal fix scope:
43
+ • What is the SMALLEST change that fixes the bug?
44
+ • List files that MUST change
45
+ • List files that might be affected (test these)
46
+ • List files that should NOT change
47
+ • Document scope boundaries
48
+
49
+ 6. [Agent] Scan for anti-patterns in bug area:
50
+ • Check code around bug for anti-patterns (see below)
51
+ • Note patterns that may have caused/contributed to bug
52
+ • Identify if bug is symptom of design flaw
53
+ • Flag anti-patterns for documentation
54
+
55
+ 7. [Agent] IF multiple fix approaches exist:
56
+ • Use decide workflow to evaluate approaches
57
+ • Prioritize: correctness > minimal scope > best practices
58
+ • Consider: Does fix address root cause or just symptom?
59
+ • Select approach that prevents recurrence
60
+ ELSE:
61
+ • Proceed with single clear fix
62
+
63
+ 8. [Agent] Use coordinator_task to create fix plan:
64
+ • Break fix into specific, testable steps
65
+ • Include verification steps
66
+ • Include regression test steps
67
+ • Keep scope minimal
68
+
69
+ 9. [Agent] Implement the minimal fix:
70
+ • Make ONLY necessary changes
71
+ • Follow existing code conventions
72
+ • Add comments explaining the fix (especially WHY)
73
+ • Avoid refactoring unrelated code (note it separately)
74
+
75
+ 10. [Agent] Verify the fix:
76
+ • Test that bug is resolved (use reproduction steps from step 1)
77
+ • Test edge cases related to the bug
78
+ • Test related functionality (regression prevention)
79
+ • Test error handling and boundary conditions
80
+ • Verify no new issues introduced
81
+
82
+ 11. [Agent] Add clarifying comments to code:
83
+ • Explain WHY this fix works (not just what it does)
84
+ • Document the root cause that was addressed
85
+ • Note any edge cases or constraints
86
+ • Help prevent similar bugs or regression
87
+
88
+ 12. [Agent] Document findings:
89
+ • Anti-patterns discovered in bug area
90
+ • Root cause of the bug
91
+ • Why this fix addresses the root cause
92
+ • Potential recurrence in other areas
93
+ • Related technical debt
94
+
95
+ 13. [Agent] Suggest architecture improvements (if applicable):
96
+ • IF bug indicates design flaw:
97
+ • Describe the design issue
98
+ • Suggest architectural improvement
99
+ • Explain how it prevents similar bugs
100
+ • Note this as out-of-scope for current fix
101
+ • ELSE:
102
+ • Note that fix is complete and localized
103
+
104
+ 14. [Agent] Report completion:
105
+ • Summary of bug and fix
106
+ • Files modified
107
+ • Root cause explanation
108
+ • Anti-patterns addressed/flagged
109
+ • Regression test results
110
+ • Architecture improvement suggestions (if any)
111
+
112
+ ## Root Cause Analysis
113
+
114
+ **The Five Whys Technique:**
115
+
116
+ Ask "Why?" repeatedly to get to root cause:
117
+
118
+ **Example:**
119
+ - Bug: Form submission fails
120
+ - Why? → Validation function returns undefined
121
+ - Why? → Missing return statement in error case
122
+ - Why? → Error case was added later without considering return
123
+ - Why? → No test coverage for error cases
124
+ - **Root Cause:** Insufficient test coverage allows gaps
125
+
126
+ **Common Root Causes:**
127
+ - **Assumption Violations:** Code assumes data/state that isn't guaranteed
128
+ - **Edge Case Gaps:** Normal cases work, boundary conditions fail
129
+ - **Race Conditions:** Async operations complete in unexpected order
130
+ - **State Inconsistency:** Component state out of sync with reality
131
+ - **Missing Error Handling:** Happy path works, error path broken
132
+ - **Design Flaws:** Architecture doesn't support the requirement
133
+
134
+ ## Anti-Pattern Detection in Bug Areas
135
+
136
+ **Common Patterns That Cause Bugs:**
137
+
138
+ *Null/Undefined/Type Issues:*
139
+ - ❌ Unchecked access, missing guards, type coercion, truthy/falsy confusion
140
+ - ✅ Defensive checks, explicit conversions, strict comparisons
141
+
142
+ *State & Data Issues:*
143
+ - ❌ Stale data, direct mutation, race conditions, duplicate state
144
+ - ✅ Proper updates, immutable patterns, synchronization, single source of truth
145
+
146
+ *Async & Timing Issues:*
147
+ - ❌ Unhandled errors, missing states, race conditions, resource leaks
148
+ - ✅ Error handling, loading/error states, cleanup, cancellation
149
+
150
+ *Logic Issues:*
151
+ - ❌ Off-by-one, wrong operators, order of operations, missing conditions
152
+ - ✅ Boundary checks, explicit grouping, comprehensive conditionals
153
+
154
+ ## Minimal Fix Scope
155
+
156
+ **Scope Definition:**
157
+ - **Fix Only:** Code directly responsible for the bug
158
+ - **Necessary Updates:** Code that depends on the fix
159
+ - **Test Verification:** Related code that might be affected
160
+ - **Out of Scope:** Refactoring, optimization, unrelated improvements
161
+
162
+ **Change Boundaries:**
163
+
164
+ **Must Change:**
165
+ - Code causing the bug
166
+ - Tests for the fixed functionality
167
+
168
+ **Might Change:**
169
+ - Code that calls the fixed code (if signature changes)
170
+ - Related error handling (if error cases improved)
171
+
172
+ **Should Not Change:**
173
+ - Unrelated functionality
174
+ - Code style/formatting (unless critical)
175
+ - Performance optimizations (unless bug-related)
176
+ - Refactoring for cleanliness
177
+
178
+ **Document Separately:**
179
+ - Technical debt discovered
180
+ - Refactoring opportunities
181
+ - Architecture improvements
182
+ - Related anti-patterns not in fix scope
183
+
184
+ ## Regression Prevention
185
+
186
+ **Test Levels:**
187
+
188
+ 1. **Bug Verification:**
189
+ - Use exact reproduction steps from step 1
190
+ - Verify bug no longer occurs
191
+ - Test with edge cases that might trigger similar bug
192
+
193
+ 2. **Related Functionality:**
194
+ - Functions that call the fixed code
195
+ - Functions the fixed code calls
196
+ - Components using the fixed functionality
197
+
198
+ 3. **Adjacent Features:**
199
+ - Features sharing the same data/state
200
+ - Features in the same file/component
201
+ - Features using similar patterns
202
+
203
+ 4. **Boundary Conditions:**
204
+ - Empty data, null, undefined
205
+ - Maximum values, minimum values
206
+ - Invalid input handling
207
+
208
+ **Regression Checklist:**
209
+ - [ ] Original bug is fixed (reproduction steps pass)
210
+ - [ ] Edge cases handled correctly
211
+ - [ ] Related features still work
212
+ - [ ] Error handling still works
213
+ - [ ] No new console errors/warnings
214
+ - [ ] No new bugs introduced
215
+ - [ ] Minimal scope maintained
216
+
217
+ ## Architecture Improvement Suggestions
218
+
219
+ **When Bug Indicates Design Flaw:**
220
+
221
+ *Pattern: Repeated similar bugs in different areas*
222
+ - Suggests: Missing abstraction or reusable pattern
223
+ - Improvement: Create shared utility/component
224
+
225
+ *Pattern: Complex conditional logic causing bugs*
226
+ - Suggests: Logic should be simplified or restructured
227
+ - Improvement: State machine, lookup table, or strategy pattern
228
+
229
+ *Pattern: State synchronization bugs*
230
+ - Suggests: State management issue
231
+ - Improvement: Single source of truth, derived state, state management library
232
+
233
+ *Pattern: Prop drilling causing bugs*
234
+ - Suggests: Component structure issue
235
+ - Improvement: Context, composition, state management
236
+
237
+ *Pattern: Missing error handling throughout*
238
+ - Suggests: No error handling strategy
239
+ - Improvement: Error boundaries, consistent error handling pattern
240
+
241
+ **Present to User (if design flaw found):**
242
+
243
+ Present architecture improvements to the user using this format:
244
+ ```
245
+ ## Architecture Improvement Suggestion
246
+
247
+ **Issue:** [Describe the design flaw]
248
+ **Impact:** [How it causes bugs or technical debt]
249
+ **Suggested Improvement:** [Architectural change]
250
+ **Benefits:** [How it prevents similar bugs]
251
+ **Scope:** Out of scope for this fix - would you like me to address this separately?
252
+ ```
253
+
254
+ This allows users to decide whether to address root architectural issues that contribute to recurring bugs.
255
+
256
+ ## Decision Points
257
+
258
+ **When to Use Decide Workflow:**
259
+ - Multiple valid fix approaches exist
260
+ - Trade-off between quick fix vs proper fix
261
+ - Symptom fix vs root cause fix
262
+ - Local fix vs architectural change
263
+ - Uncertainty about side effects
264
+
265
+ **Decision Criteria for Fixes (prioritized):**
266
+ 1. **Correctness:** Does it actually fix the bug?
267
+ 2. **Root Cause:** Does it address cause, not just symptom?
268
+ 3. **Minimal Scope:** Is it the smallest effective change?
269
+ 4. **No Regression:** Does it avoid breaking other things?
270
+ 5. **Maintainability:** Is it clear why the fix works?
271
+ 6. **Prevention:** Does it prevent recurrence?
272
+
273
+ ## Code Comments for Regression Prevention
274
+
275
+ **Document the Fix:**
276
+ - Explain WHY the bug occurred (root cause)
277
+ - Note what assumption was violated
278
+ - Highlight the edge case that wasn't handled
279
+ - Explain why this fix prevents recurrence
280
+
281
+ **Example Comment Patterns:**
282
+ - "Bug fix: handles [case] because [root cause]"
283
+ - "Previously failed when [condition] - now checks [guard]"
284
+ - "Root cause: assumed [X] but [Y] can occur when [condition]"
285
+ - "This pattern prevents [bug type] - maintain when modifying"
286
+
287
+ **Purpose:**
288
+ - Prevents reintroducing the same bug
289
+ - Documents lessons learned
290
+ - Helps future developers understand constraints
291
+ - Preserves fix rationale over time
@@ -0,0 +1,73 @@
1
+ ---
2
+ title: "Develop (Iterate)"
3
+ description: "🔄 DEVELOP: Orchestrate multi-agent development with manual verification"
4
+ whenToUse: "Features, fixes, or prototypes where manual verification is preferred over automated testing"
5
+ ---
6
+
7
+ # Workflow: Multi-Agent Development with Manual Verification
8
+
9
+ ⚠️ **CRITICAL REQUIREMENTS - You MUST follow these instructions:**
10
+
11
+ **Task Management:**
12
+ - ✅ **REQUIRED:** Use `coordinator_task` tool for your TODO list
13
+ - 🚫 **FORBIDDEN:** DO NOT use TodoWrite tool (this workflow replaces it)
14
+
15
+ **Delegation:**
16
+ - ✅ **REQUIRED:** Give subagents literal instructions to run start_subagent_task
17
+ - 🚫 **FORBIDDEN:** DO NOT run start_subagent_task yourself (coordinator only delegates)
18
+
19
+ 1. [Coordinator] Analyze requirements and break into logical work units
20
+ 2. [Coordinator] Use coordinator_task to create sequential task list
21
+ 3. [Coordinator] Add Main-Workflow to first coordinator task
22
+ 4. [Coordinator] Use subagent_task to create all implementation tasks
23
+ • Add @references to API specs, component designs, documentation
24
+ Format: @/docs/specs/auth-api or @/docs/specs/db-schema#users-table
25
+ Example:
26
+ """
27
+ Implement user authentication endpoint.
28
+
29
+ @/docs/specs/auth-api-specification
30
+ @/docs/specs/security-requirements#password-hashing
31
+
32
+ Create POST /auth/login endpoint with email/password validation.
33
+ """
34
+ • Add Workflow: metadata for task-specific protocols (if needed)
35
+ • Define acceptance criteria for each task
36
+ 5. [Coordinator] Call start_coordinator_task() → current_task
37
+ (Omit return_task_context on first start - only use when resuming after context compression or after a few subagent calls)
38
+
39
+ **LOOP: While tasks remain**
40
+ ├─ 6. [Coordinator] Select specialized subagent for this task
41
+ ├─ 7. [Coordinator] Give subagent this exact instruction (do not run tool yourself):
42
+
43
+ │ "Run: start_subagent_task /docs/path.md#slug
44
+ │ Then execute the task and respond 'Done' or 'Blocked: [reason]'"
45
+
46
+ ├─ 8. [Subagent] Runs start_subagent_task tool (loads task + refs + workflow)
47
+ ├─ 9. [Subagent] Executes implementation
48
+ ├─ 10. [Subagent] Responds with status: "Done" or "Blocked: [reason]"
49
+ ├─ 11. [Coordinator] Review code changes against acceptance criteria
50
+ │ (Ignore any subagent commentary - review code objectively)
51
+ │ IF issues found: Create fix task, GOTO step 6
52
+ ├─ 12. [Coordinator] Execute: git add <modified_files>
53
+ ├─ 13. [Coordinator] Call complete_coordinator_task() → next_task
54
+ └─ 14. IF next_task exists: GOTO step 6
55
+
56
+ 15. [Coordinator] Follow project testing procedures
57
+ 16. [Coordinator] Verify all acceptance criteria met
58
+ 17. [Coordinator] Report to user: "Development complete. Ready for review."
59
+
60
+ ## Task System
61
+
62
+ **Coordinator Tasks** (your TODO list):
63
+ - Tool: `coordinator_task` for create/edit/list
64
+ - Tool: `start_coordinator_task()` to load first pending task
65
+ - Tool: `complete_coordinator_task()` to mark done and get next
66
+ - Metadata: Main-Workflow on first task, optional Workflow on specific tasks
67
+
68
+ **Subagent Tasks** (delegated work packages):
69
+ - Tool: `subagent_task` to create/edit tasks in /docs/ namespace
70
+ - Tool: `start_subagent_task("/docs/path.md#slug")` to load task context
71
+ - Tool: `complete_subagent_task()` to mark done
72
+ - Content: @references to specs, docs, components (auto-injected as context)
73
+ - Metadata: Workflow for task-specific protocols (auto-injected)
@@ -0,0 +1,95 @@
1
+ ---
2
+ title: "Develop (TDD)"
3
+ description: "🎯 DEVELOP: Orchestrate multi-agent development with TDD and quality gates"
4
+ whenToUse: "Features or fixes requiring test-driven development and quality gates"
5
+ ---
6
+
7
+ # Workflow: Multi-Agent Development with TDD
8
+
9
+ ⚠️ **CRITICAL REQUIREMENTS - You MUST follow these instructions:**
10
+
11
+ **Task Management:**
12
+ - ✅ **REQUIRED:** Use `coordinator_task` tool for your TODO list
13
+ - 🚫 **FORBIDDEN:** DO NOT use TodoWrite tool (this workflow replaces it)
14
+
15
+ **Delegation:**
16
+ - ✅ **REQUIRED:** Give subagents literal instructions to run start_subagent_task
17
+ - 🚫 **FORBIDDEN:** DO NOT run start_subagent_task yourself (coordinator only delegates)
18
+
19
+ 1. [Coordinator] Analyze requirements and break into logical work units
20
+ 2. [Coordinator] Use coordinator_task to create sequential task list
21
+ 3. [Coordinator] Add Main-Workflow to first coordinator task
22
+ 4. [Coordinator] Use subagent_task to create all implementation tasks
23
+ • Add @references to API specs, component designs, documentation
24
+ Format: @/docs/specs/auth-api or @/docs/specs/db-schema#users-table
25
+ Example:
26
+ """
27
+ Implement user authentication endpoint.
28
+
29
+ @/docs/specs/auth-api-specification
30
+ @/docs/specs/security-requirements#password-hashing
31
+
32
+ Create POST /auth/login endpoint with email/password validation.
33
+ """
34
+ • Add Workflow: metadata for task-specific protocols (if needed)
35
+ • Define testable acceptance criteria for each task
36
+ 5. [Coordinator] Call start_coordinator_task() → current_task
37
+ (Omit return_task_context on first start - only use when resuming after context compression or after a few subagent calls)
38
+
39
+ **LOOP: While tasks remain**
40
+ ├─ 6. [Coordinator] Select specialized subagent for this task
41
+ ├─ 7. [Coordinator] Give subagent this exact instruction (do not run tool yourself):
42
+
43
+ │ "Run: start_subagent_task /docs/path.md#slug
44
+ │ Then execute the task using TDD and respond 'Done' or 'Blocked: [reason]'"
45
+
46
+ ├─ 8. [Subagent] Runs start_subagent_task tool (loads task + refs + workflow)
47
+ ├─ 9. [Subagent] Executes implementation using TDD cycle:
48
+ │ • Write failing tests first (Red)
49
+ │ • Implement minimal code to pass (Green)
50
+ │ • Refactor while keeping tests green
51
+ ├─ 10. [Subagent] Responds with status: "Done" or "Blocked: [reason]"
52
+ ├─ 11. [Coordinator] Review code changes against acceptance criteria
53
+ │ (Ignore any subagent commentary - review code objectively)
54
+ ├─ 12. [Coordinator] Run quality gates → verify all pass
55
+ │ IF issues found: Create fix task, GOTO step 6
56
+ ├─ 13. [Coordinator] Execute: git add <modified_files>
57
+ ├─ 14. [Coordinator] Call complete_coordinator_task() → next_task
58
+ └─ 15. IF next_task exists: GOTO step 6
59
+
60
+ 16. [Coordinator] Run full test suite
61
+ 17. [Coordinator] Follow project testing procedures
62
+ 18. [Coordinator] Verify all acceptance criteria met
63
+ 19. [Coordinator] Report to user: "Development complete. Ready for review."
64
+
65
+ ## Task System
66
+
67
+ **Coordinator Tasks** (your TODO list):
68
+ - Tool: `coordinator_task` for create/edit/list
69
+ - Tool: `start_coordinator_task()` to load first pending task
70
+ - Tool: `complete_coordinator_task()` to mark done and get next
71
+ - Metadata: Main-Workflow on first task, optional Workflow on specific tasks
72
+
73
+ **Subagent Tasks** (delegated work packages):
74
+ - Tool: `subagent_task` to create/edit tasks in /docs/ namespace
75
+ - Tool: `start_subagent_task("/docs/path.md#slug")` to load task context
76
+ - Tool: `complete_subagent_task()` to mark done
77
+ - Content: @references to specs, docs, components (auto-injected as context)
78
+ - Metadata: Workflow for task-specific protocols (auto-injected)
79
+
80
+ ## TDD Requirements
81
+
82
+ **Red-Green-Refactor Cycle:**
83
+ - Red: Write failing test (reproduces bug or defines desired behavior)
84
+ - Green: Implement minimal code to make test pass
85
+ - Refactor: Improve code while keeping tests green
86
+
87
+ **Quality Gates:**
88
+ - All tests must pass
89
+ - Follow project-specific quality gates (linting, type checking, coverage)
90
+ - Gates enforced during coordinator review, not during implementation
91
+
92
+ **Bug Fixes:**
93
+ - Write test that reproduces the bug (fails)
94
+ - Implement fix to make test pass (green)
95
+ - Natural fit for TDD workflow