fix-bug
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.zipInstalls 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 modelKey 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
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
- Reproduce: Follow exact steps to trigger the bug
- Expected: What SHOULD happen (user's mental model)
- Actual: What IS happening (current behavior)
- Root cause: WHY it's happening (code analysis)
Locate in Architecture
Reference: docs/ARCHITECTURE.md
| Layer | Location | What to look for |
|---|---|---|
| Domain | Sources/Domain/ | Incorrect business logic, missing invariants |
| Infrastructure | Sources/Infrastructure/ | Parsing errors, CLI/API issues |
| App | Sources/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 Location | Test 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
- Minimal change: Fix only what's broken
- Domain first: Prefer fixing in domain layer when possible
- Maintain invariants: Domain should be self-validating
- 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
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.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| fix-bug (this skill) | 11 | 7mo | Review | Intermediate |
| python-testing-patterns | 77 | 2mo | Review | Intermediate |
| test-fixing | 1 | 9mo | Review | Intermediate |
| fixing-bugs-systematically | 1 | 8mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by tddworks
View all by tddworks →You might also like
python-testing-patterns
wshobson
Implement comprehensive testing strategies with pytest, fixtures, mocking, and test-driven development. Use when writing Python tests, setting up test suites, or implementing testing best practices.
test-fixing
mhattingpete
Run tests and systematically fix all failing tests using smart error grouping. Use when user asks to fix failing tests, mentions test failures, runs test suite and failures occur, or requests to make tests pass.
fixing-bugs-systematically
CaptainCrouton89
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.
moai-workflow-testing
modu-ai
Comprehensive development workflow specialist combining DDD testing, debugging, performance optimization, code review, PR review, and quality assurance into unified development workflows
investigate
MadAppGang
Unified entry point for code investigation. Auto-routes to specialized detective based on query keywords. Use when investigation type is unclear or for general exploration.
review
MatrixAges
Review uncommitted code changes to find unreasonable design, unfinished requirements, potential bugs, missed reuse opportunities, and optimization opportunities. Use when the user asks for a review of pending, uncommitted, or unpublished code changes and expects both findings and concrete improvemen