Bugfix
End-to-end workflow for investigating, diagnosing, and fixing bugs. Orchestrates environment analysis (/analyze-local or /analyze-prod), evidence collection, bug report preparation, fix planning, and implementation by the appropriate engineering role.
1. Receive Bug Report
Gather the bug description from the user:
- What is the expected behavior?
- What is the actual behavior? (error message, wrong output, crash, performance issue)
- Steps to reproduce (if known)
- Environment: local (Docker) or production (cloud K8s)?
- When did it start? (after deploy, config change, or unknown)
- Severity: P1 (outage), P2 (degraded), P3 (minor), P4 (cosmetic)
If the user provides partial information, extract what you can and fill gaps during analysis. For P1/P2 — skip detailed intake and proceed immediately to Step 2.
2. Analyze Environment
Based on the environment, delegate to the appropriate analysis sub-workflow:
| Environment |
Sub-workflow |
When to use |
| Local Docker / Docker Compose |
/analyze-local |
Bug observed in local dev environment |
| Cloud production (GKE/AKS/EKS, managed DB) |
/analyze-prod |
Bug observed in production or staging |
| Code-only (no infra) |
Skip to Step 3 |
Bug is in application logic, no environment analysis needed |
Run the sub-workflow. It will:
- Apply the appropriate diagnostic role (
Agent(sre-engineer) or Agent(devops-engineer))
- Collect environment snapshot (container/pod status, logs, metrics, networking)
- Identify infrastructure-level issues
- Present diagnosis
If the sub-workflow resolves the issue (e.g., container restart, config fix) — skip to Step 8.
If the root cause is in application code — continue to Step 3 with the collected evidence.
3. Detect Stack and Apply Engineer Role
Determine the affected service's tech stack and apply the appropriate engineering role:
- Read project's
CLAUDE.md — tech stack declaration
- Scan project files —
package.json, pom.xml, requirements.txt, go.mod, etc.
- Check evidence from Step 2 — which service's logs show the error? What language is the stack trace in?
Role assignment:
| Stack Signal |
Role |
Next.js, React, TypeScript, .tsx files |
Agent(frontend-engineer) |
Spring Boot, Java, .java files |
Agent(java-engineer) |
FastAPI, Python, .py files |
Agent(python-engineer) |
| Terraform, Dockerfile, Helm, CI/CD |
Agent(devops-engineer) |
| ML model, training pipeline, inference |
Agent(ml-engineer) |
| Multiple stacks affected |
Apply all relevant roles |
| Unknown / general |
Agent(software-engineer) |
Announce the applied role(s) to the user.
4. Collect Evidence
Gather all evidence into a structured collection. Combine data from Step 2 (environment analysis) with code-level investigation:
Use the applied role's debugging methodology to trace the bug:
- Read error stack traces to identify the failing code path
- Search codebase for related functions, error handlers, and data flows
- Check recent changes (
git log -n 20 --oneline) for potential regressions
- Identify the minimal reproduction case
5. Prepare Bug Report
Compile findings into a structured bug report. Present to the user for review:
## Bug Report
### Summary
[One sentence: what is broken]
### Severity: [P1 | P2 | P3 | P4]
### Environment
- **Type**: [local | production]
- **Service**: [name]
- **Stack**: [detected] | **Role**: [applied]
### Expected Behavior
[What should happen]
### Actual Behavior
[What actually happens — include error messages]
### Steps to Reproduce
1. [step]
2. [step]
3. [observed error]
### Evidence
- **Stack trace**: [snippet or reference]
- **Logs**: [relevant entries]
- **Metrics**: [if applicable]
- **Affected code**: [file:line references]
### Root Cause Analysis
[Technical explanation of why the bug occurs]
### Affected Components
- [file/module 1] — [how it's affected]
- [file/module 2] — [how it's affected]
Wait for user confirmation before proceeding to fix.
6. Plan the Fix
Create an ordered fix plan following the applied role's guidelines:
- Root cause fix — address the actual cause, not symptoms
- Minimal change — smallest change that fixes the bug without side effects
- Regression test — test that would have caught this bug
- Related fixes — any adjacent issues discovered during investigation
Present the plan:
## Fix Plan
### Root Cause
[What caused the bug — one sentence]
### Changes
1. [file] — [what to change and why]
2. [file] — [what to change and why]
...
### Tests
1. [test file] — [test that reproduces and verifies the fix]
2. [test file] — [regression test for edge cases]
### Risk Assessment
- **Blast radius**: [which features could be affected by this change]
- **Rollback**: [how to revert if the fix causes issues]
Wait for user approval before implementing.
7. Implement the Fix
Execute the approved plan step by step.
For each change:
- State what you are about to do (file, change summary)
- Implement the fix following the applied role's code quality standards
- Verify the code compiles/parses without errors
Then write tests:
- Regression test: Reproduces the original bug — must fail without fix, pass with fix
- Edge case tests: Cover related scenarios discovered during investigation
- Run the full test suite to catch regressions
Rules:
- Fix the root cause, not the symptom
- Minimal, focused changes — do not refactor unrelated code
- Follow existing code patterns and conventions
- No new warnings or linter errors
- If the fix is more complex than expected — stop and discuss with the user
8. Verify the Fix
Verify the bug is resolved in the appropriate environment:
For local bugs:
- Run the reproduction steps — confirm the bug no longer occurs
- Run the full test suite — all tests pass (new + existing)
- If Docker-based: rebuild and verify with
/analyze-local (optional)
For production bugs:
- Verify the fix locally first
- Deploy through normal CI/CD pipeline (do NOT hotfix production directly)
- After deploy: re-run relevant checks from
/analyze-prod to confirm resolution
- Monitor error rates and SLIs for regression
Verification checklist:
If any check fails — fix and re-verify.
9. Summary
Present the completed bugfix:
- Bug: one-sentence summary
- Severity: P1–P4
- Environment: local / production
- Role(s) applied: which roles were used
- Root cause: technical explanation
- Fix: what was changed (files, brief description)
- Tests added: count and description
- Verification: how it was confirmed fixed
- Prevention: recommendations to avoid similar bugs (e.g., add validation, improve error handling, add monitoring)
Integration
- Sub-workflows:
/analyze-local, /analyze-prod (environment diagnostics)
- Follow-up:
/run-tests (verify fix), /pre-commit (quality gate), /create-pr (submit fix)
- Skills:
code-review skill (review fix), testing-procedures skill (test strategy)
1---2name: bugfix-33description: End-to-end bugfix workflow — analyze environment (local Docker or cloud production), collect evidence, prepare bug report, plan fix, apply appropriate engineer role, implement and verify the fix.4---5
6# Bugfix
7
8End-to-end workflow for investigating, diagnosing, and fixing bugs. Orchestrates environment analysis (`/analyze-local` or `/analyze-prod`), evidence collection, bug report preparation, fix planning, and implementation by the appropriate engineering role.
9
10## 1. Receive Bug Report
11
12Gather the bug description from the user:
13
14- **What is the expected behavior?**
15- **What is the actual behavior?** (error message, wrong output, crash, performance issue)
16- **Steps to reproduce** (if known)
17- **Environment**: local (Docker) or production (cloud K8s)?
18- **When did it start?** (after deploy, config change, or unknown)
19- **Severity**: P1 (outage), P2 (degraded), P3 (minor), P4 (cosmetic)
20
21If the user provides partial information, extract what you can and fill gaps during analysis. For P1/P2 — skip detailed intake and proceed immediately to Step 2.
22
23## 2. Analyze Environment
24
25Based on the environment, delegate to the appropriate analysis sub-workflow:
26
27| Environment | Sub-workflow | When to use |
28|---|---|---|
29| Local Docker / Docker Compose | `/analyze-local` | Bug observed in local dev environment |
30| Cloud production (GKE/AKS/EKS, managed DB) | `/analyze-prod` | Bug observed in production or staging |
31| Code-only (no infra) | Skip to Step 3 | Bug is in application logic, no environment analysis needed |
32
33Run the sub-workflow. It will:
34- Apply the appropriate diagnostic role (`Agent(sre-engineer)` or `Agent(devops-engineer)`)
35- Collect environment snapshot (container/pod status, logs, metrics, networking)
36- Identify infrastructure-level issues
37- Present diagnosis
38
39**If the sub-workflow resolves the issue** (e.g., container restart, config fix) — skip to Step 8.
40
41**If the root cause is in application code** — continue to Step 3 with the collected evidence.
42
43## 3. Detect Stack and Apply Engineer Role
44
45Determine the affected service's tech stack and apply the appropriate engineering role:
46
471. **Read project's `CLAUDE.md`** — tech stack declaration
482. **Scan project files** — `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, etc.
493. **Check evidence from Step 2** — which service's logs show the error? What language is the stack trace in?
50
51**Role assignment:**
52
53| Stack Signal | Role |
54|---|---|
55| Next.js, React, TypeScript, `.tsx` files | `Agent(frontend-engineer)` |
56| Spring Boot, Java, `.java` files | `Agent(java-engineer)` |
57| FastAPI, Python, `.py` files | `Agent(python-engineer)` |
58| Terraform, Dockerfile, Helm, CI/CD | `Agent(devops-engineer)` |
59| ML model, training pipeline, inference | `Agent(ml-engineer)` |
60| Multiple stacks affected | Apply all relevant roles |
61| Unknown / general | `Agent(software-engineer)` |
62
63Announce the applied role(s) to the user.
64
65## 4. Collect Evidence
66
67Gather all evidence into a structured collection. Combine data from Step 2 (environment analysis) with code-level investigation:
68
69<evidence_checklist>
70- **Error output**: Full error message, stack trace, exit code
71- **Logs**: Relevant log entries (timestamped) from the affected service
72- **Reproduction**: Can you reproduce locally? Consistent or intermittent?
73- **Scope**: Which endpoints / features / components are affected?
74- **Timeline**: When did it start? What changed? (recent commits, deploys, config)
75- **Data**: Specific inputs that trigger the bug (request payload, user ID, dataset)
76- **Metrics** (if from prod): Error rate, latency change, affected user count
77- **Related code**: Files, functions, lines most likely involved
78</evidence_checklist>
79
80Use the applied role's debugging methodology to trace the bug:
81- Read error stack traces to identify the failing code path
82- Search codebase for related functions, error handlers, and data flows
83- Check recent changes (`git log -n 20 --oneline`) for potential regressions
84- Identify the **minimal reproduction case**
85
86## 5. Prepare Bug Report
87
88Compile findings into a structured bug report. Present to the user for review:
89
90```
91## Bug Report
92
93### Summary
94[One sentence: what is broken]
95
96### Severity: [P1 | P2 | P3 | P4]
97
98### Environment
99- **Type**: [local | production]
100- **Service**: [name]
101- **Stack**: [detected] | **Role**: [applied]
102
103### Expected Behavior
104[What should happen]
105
106### Actual Behavior
107[What actually happens — include error messages]
108
109### Steps to Reproduce
1101. [step]
1112. [step]
1123. [observed error]
113
114### Evidence
115- **Stack trace**: [snippet or reference]
116- **Logs**: [relevant entries]
117- **Metrics**: [if applicable]
118- **Affected code**: [file:line references]
119
120### Root Cause Analysis
121[Technical explanation of why the bug occurs]
122
123### Affected Components
124- [file/module 1] — [how it's affected]
125- [file/module 2] — [how it's affected]
126```
127
128Wait for user confirmation before proceeding to fix.
129
130## 6. Plan the Fix
131
132Create an ordered fix plan following the applied role's guidelines:
133
1341. **Root cause fix** — address the actual cause, not symptoms
1352. **Minimal change** — smallest change that fixes the bug without side effects
1363. **Regression test** — test that would have caught this bug
1374. **Related fixes** — any adjacent issues discovered during investigation
138
139Present the plan:
140
141```
142## Fix Plan
143
144### Root Cause
145[What caused the bug — one sentence]
146
147### Changes
1481. [file] — [what to change and why]
1492. [file] — [what to change and why]
150...
151
152### Tests
1531. [test file] — [test that reproduces and verifies the fix]
1542. [test file] — [regression test for edge cases]
155
156### Risk Assessment
157- **Blast radius**: [which features could be affected by this change]
158- **Rollback**: [how to revert if the fix causes issues]
159```
160
161Wait for user approval before implementing.
162
163## 7. Implement the Fix
164
165Execute the approved plan step by step.
166
167**For each change:**
1681. State what you are about to do (file, change summary)
1692. Implement the fix following the applied role's code quality standards
1703. Verify the code compiles/parses without errors
171
172**Then write tests:**
1731. **Regression test**: Reproduces the original bug — must fail without fix, pass with fix
1742. **Edge case tests**: Cover related scenarios discovered during investigation
1753. Run the full test suite to catch regressions
176
177**Rules:**
178- Fix the root cause, not the symptom
179- Minimal, focused changes — do not refactor unrelated code
180- Follow existing code patterns and conventions
181- No new warnings or linter errors
182- If the fix is more complex than expected — stop and discuss with the user
183
184## 8. Verify the Fix
185
186Verify the bug is resolved in the appropriate environment:
187
188**For local bugs:**
189- Run the reproduction steps — confirm the bug no longer occurs
190- Run the full test suite — all tests pass (new + existing)
191- If Docker-based: rebuild and verify with `/analyze-local` (optional)
192
193**For production bugs:**
194- Verify the fix locally first
195- Deploy through normal CI/CD pipeline (do NOT hotfix production directly)
196- After deploy: re-run relevant checks from `/analyze-prod` to confirm resolution
197- Monitor error rates and SLIs for regression
198
199**Verification checklist:**
200- [ ] Original bug no longer reproduces
201- [ ] Regression test passes
202- [ ] Full test suite passes (no new failures)
203- [ ] No new warnings or linter errors
204- [ ] No unrelated files modified
205- [ ] Code follows project conventions and role guidelines
206
207If any check fails — fix and re-verify.
208
209## 9. Summary
210
211Present the completed bugfix:
212
213- **Bug**: one-sentence summary
214- **Severity**: P1–P4
215- **Environment**: local / production
216- **Role(s) applied**: which roles were used
217- **Root cause**: technical explanation
218- **Fix**: what was changed (files, brief description)
219- **Tests added**: count and description
220- **Verification**: how it was confirmed fixed
221- **Prevention**: recommendations to avoid similar bugs (e.g., add validation, improve error handling, add monitoring)
222
223## Integration
224
225- **Sub-workflows**: `/analyze-local`, `/analyze-prod` (environment diagnostics)
226- **Follow-up**: `/run-tests` (verify fix), `/pre-commit` (quality gate), `/create-pr` (submit fix)
227- **Skills**: `code-review` skill (review fix), `testing-procedures` skill (test strategy)