---

name: Fixing Bugs Systematically description: Diagnose and fix bugs through systematic investigation, root cause analysis, and targeted validation. Use when something is broken, errors occur, performance degrades, or unexpected behavior manifests.

Fixing Bugs Systematically

Structured protocol for isolating root causes and implementing focused fixes in existing features.

When to Use

• Something is broken and needs diagnosis and repair
• Error messages or unexpected behavior occurs
• Performance degradation in existing functionality
• Intermittent or hard-to-reproduce issues

Core Steps

1. Context & Reproduction

Read relevant documentation:

• docs/feature-spec/F-##-*.md for affected feature
• docs/user-stories/US-###-*.md for expected behavior and acceptance criteria
• docs/api-contracts.yaml if API-related
• docs/system-design.md for architecture context

Document the bug:

• Expected behavior (cite story AC or spec)
• Actual behavior (what's broken)
• Reproduction steps
• Feature ID (F-##) and Story ID (US-###) if known

2. Investigation

Simple bugs (obvious entry point)

Use direct investigation:

• Grep to locate error messages or related code
• Read suspected files to examine implementation
• Trace function calls and data transformations
• Check related files for connected logic

Complex bugs (multiple subsystems or unclear origin)

Delegate to async agents in parallel:

Spawn senior-engineer agents to:

• Trace error flow through specific subsystem
• Analyze related failure patterns
• Investigate runtime conditions

Spawn Explore agents to:

• Map data flow across multiple files
• Find all error handling for specific operation
• Locate configuration and integration points

Example: For authentication bug, spawn:

• Agent 1: "Trace auth flow from login endpoint to session creation"
• Agent 2: "Find all error handling and validation in auth module"
• Agent 3: "Locate session storage config and related code"

Wait for results using ./agent-responses/await {agent_id}

3. Root Cause Analysis

Generate hypotheses:

• List 3-8 potential root causes from investigation
• Rank by probability (evidence from code) and impact
• Select most likely cause(s)

Decision point:

• Fix immediately if root cause is obvious and confirmed
• Add validation if multiple plausible causes or runtime-dependent behavior

4. Validation (if needed)

Add minimal debugging:

• Logging at decision points
• Data inspection at boundaries
• Input/output logging at integration points

Test to confirm root cause before proceeding to fix.

5. Implementation

Fix the confirmed root cause:

• Keep changes minimal and focused
• Maintain API stability unless approved
• Follow existing patterns in codebase

Update documentation if needed:

• Add note in feature spec or changelog
• Update docs/api-contracts.yaml if contract changed (requires approval)
• For slash commands:
  • /manage-project/update/update-feature to correct spec
  • /manage-project/update/update-story if ACs were ambiguous
  • /manage-project/update/update-api if API changed (with approval)

6. Validation & Testing

Verify fix against acceptance criteria:

• Test all ACs from affected user stories
• Check 1-2 key edge cases and error states
• Run contract tests if API changed
• Verify events in docs/data-plan.md still fire correctly

7. Cleanup

• Remove all debugging and logging code
• Verify no temporary files remain

Investigation Strategy

For direct investigation:

• Use grep, read_file to understand subsystem
• Trace flows manually through related files
• Focus on specific area where bug manifests

When to validate before fixing:

• Multiple plausible root causes exist
• Runtime-dependent behavior
• Intermittent or hard-to-reproduce issues

For async investigation:

• Each agent investigates independent subsystem
• Run in parallel for speed
• Maximum 6 agents (diminishing returns)

Artifacts

Inputs:

• docs/feature-spec/F-##-*.md — Feature specs
• docs/user-stories/US-###-*.md — Expected behavior and ACs
• docs/api-contracts.yaml — API specs
• docs/system-design.md — Architecture context

Outputs:

• Investigation findings (inline notes or agent reports)
• Updated feature spec with bug resolution notes
• Fixed code with accompanying tests

Quick Reference

Scenario	Approach
Single subsystem, obvious entry	Direct investigation → immediate fix
Multiple subsystems, unclear origin	Spawn 2-4 agents in parallel → synthesize findings → fix
Runtime-dependent or intermittent	Add targeted logging → reproduce → analyze logs → fix
Multiple independent fixes needed	Pass investigation results to fix agents via artifact files