A systematic testing-led approach to debugging code.

Install

mkdir -p .claude/skills/fix-bug && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/2834" && unzip -o skill.zip -d .claude/skills/fix-bug && rm skill.zip

Installs to .claude/skills/fix-bug

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Guide for fixing bugs in ClaudeBar following Chicago School TDD and rich domain design. Use this skill when:
(1) User reports a bug or unexpected behavior
(2) Fixing a defect in existing functionality
(3) User asks "fix this bug" or "this doesn't work correctly"
(4) Correcting behavior that violates the user's mental model
324 chars · catalog description✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Intermediate

Key capabilities

  • Executes the Chicago School TDD cycle (Red-Green-Refactor)
  • Identifies root causes via step-by-step reproduction
  • Validates fixes with failing test cases
  • Verifies existing functionality through regression tests

How it works

It forces a strict workflow where a test must fail for the identified bug before any implementation code is modified.

Inputs & outputs

You give it
Bug description or failure steps
You get back
Reproduction test case and minimal functional fix

When to use fix-bug

  • Debugging reported issues
  • Refactoring code with safety tests
  • Fixing production defects

About this skill

Fix Bug in ClaudeBar

Fix bugs using Chicago School TDD, root cause analysis, and rich domain design.

Workflow

┌─────────────────────────────────────────────────────────────┐
│  1. REPRODUCE & UNDERSTAND                                   │
├─────────────────────────────────────────────────────────────┤
│  • Reproduce the bug                                         │
│  • Identify expected vs actual behavior                      │
│  • Locate the root cause in code                             │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│  2. WRITE FAILING TEST (Red)                                 │
├─────────────────────────────────────────────────────────────┤
│  • Write test that exposes the bug                           │
│  • Test should FAIL before fix                               │
│  • Test should verify CORRECT behavior                       │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│  3. FIX & VERIFY (Green)                                     │
├─────────────────────────────────────────────────────────────┤
│  • Implement minimal fix                                     │
│  • Test now PASSES                                           │
│  • All existing tests still pass                             │
└─────────────────────────────────────────────────────────────┘

Phase 1: Reproduce & Understand

Identify the Bug

  1. Reproduce: Follow exact steps to trigger the bug
  2. Expected: What SHOULD happen (user's mental model)
  3. Actual: What IS happening (current behavior)
  4. Root cause: WHY it's happening (code analysis)

Locate in Architecture

Reference: docs/ARCHITECTURE.md

LayerLocationWhat to look for
DomainSources/Domain/Incorrect business logic, missing invariants
InfrastructureSources/Infrastructure/Parsing errors, CLI/API issues
AppSources/App/View state issues, binding problems

Domain Invariants

Check if the bug violates domain invariants that should be maintained:

// Example: QuotaMonitor should maintain selection invariants
// - selectedProviderId should always point to an enabled provider
// - Domain should be self-validating (no external "ensure" calls needed)

Phase 2: Write Failing Test (Red)

Chicago School TDD

We follow Chicago School TDD (state-based testing):

  • Test state changes and return values, not interactions
  • Focus on the "what" (observable outcomes), not the "how" (method calls)
  • Mocks stub dependencies to return data, not to verify calls
  • No verify() calls - assert on resulting state instead

Test Pattern

Test the CORRECT behavior, not the bug:

@Suite
struct {Component}Tests {

    @Test func `{describes correct behavior}`() {
        // Given - setup that triggers the bug scenario
        let settings = makeSettingsRepository()
        let claude = ClaudeProvider(probe: MockUsageProbe(), settingsRepository: settings)
        claude.isEnabled = false  // Bug trigger condition

        // When - action that should work correctly
        let monitor = QuotaMonitor(providers: AIProviders(providers: [claude, codex]))

        // Then - assert EXPECTED behavior (will FAIL before fix)
        #expect(monitor.selectedProviderId == "codex")  // Not "claude"
    }
}

Test Location

Bug LocationTest Location
Sources/Domain/Monitor/Tests/DomainTests/Monitor/
Sources/Domain/Provider/Tests/DomainTests/Provider/
Sources/Infrastructure/CLI/Tests/InfrastructureTests/CLI/

Run Test (Should FAIL)

swift test --filter "{TestSuiteName}"

Phase 3: Fix & Verify (Green)

Fix Guidelines

  1. Minimal change: Fix only what's broken
  2. Domain first: Prefer fixing in domain layer when possible
  3. Maintain invariants: Domain should be self-validating
  4. No over-engineering: Don't refactor unrelated code

Domain Design Principles

When fixing domain bugs, ensure:

// 1. Domain maintains its own invariants
public init(...) {
    // Validate on construction
    selectFirstEnabledIfNeeded()  // Called internally, not externally
}

// 2. Public API hides implementation details
public func setProviderEnabled(_ id: String, enabled: Bool) {
    provider.isEnabled = enabled
    if !enabled {
        selectFirstEnabledIfNeeded()  // Private - called automatically
    }
}

// 3. Private methods for internal invariant maintenance
private func selectFirstEnabledIfNeeded() { ... }

Verify Fix

# Run the specific test (should PASS now)
swift test --filter "{TestSuiteName}"

# Run ALL tests to ensure no regressions
swift test

Checklist

  • Bug reproduced and understood
  • Root cause identified in code
  • Failing test written (exposes bug)
  • Test FAILS before fix
  • Minimal fix implemented
  • Test PASSES after fix
  • All existing tests still pass
  • Domain invariants maintained (if applicable)
  • CHANGELOG updated with fix description

When not to use it

  • When a project lacks a test suite
  • For UI/styling issues where TDD is not applicable

Prerequisites

Existing test suite

Limitations

  • Slower than quick-patch methods
  • Strictly relies on the ability to reproduce bugs in a test environment

How it compares

It prevents 'fix-by-guess' by requiring a failing test as the foundational requirement for every correction.

Compared to similar skills

fix-bug side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
fix-bug (this skill)117moReviewIntermediate
python-testing-patterns772moReviewIntermediate
test-fixing19moReviewIntermediate
fixing-bugs-systematically18moNo flagsIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

Search skills

Search the agent skills registry