.claude/skills/fix-bug/SKILL.md
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
npx skillsauth add tddworks/claudebar fix-bugInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fix bugs using Chicago School TDD, root cause analysis, and rich domain design.
┌─────────────────────────────────────────────────────────────┐
│ 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 │
└─────────────────────────────────────────────────────────────┘
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 |
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)
We follow Chicago School TDD (state-based testing):
verify() calls - assert on resulting state insteadTest 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"
}
}
| Bug Location | Test Location |
|--------------|---------------|
| Sources/Domain/Monitor/ | Tests/DomainTests/Monitor/ |
| Sources/Domain/Provider/ | Tests/DomainTests/Provider/ |
| Sources/Infrastructure/CLI/ | Tests/InfrastructureTests/CLI/ |
swift test --filter "{TestSuiteName}"
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() { ... }
# Run the specific test (should PASS now)
swift test --filter "{TestSuiteName}"
# Run ALL tests to ensure no regressions
swift test
development
Guide for making improvements to existing ClaudeBar functionality using TDD. Use this skill when: (1) Enhancing existing features (not adding new ones) (2) Improving UX, performance, or code quality (3) User asks "improve X", "make Y better", or "enhance Z" (4) Small enhancements that don't require full architecture design For NEW features, use implement-feature skill instead.
development
Guide for implementing features in ClaudeBar following architecture-first design, TDD, rich domain models, and Swift 6.2 patterns. Use this skill when: (1) Adding new functionality to the app (2) Creating domain models that follow user's mental model (3) Building SwiftUI views that consume domain models directly (4) User asks "how do I implement X" or "add feature Y" (5) Implementing any feature that spans Domain, Infrastructure, and App layers
development
Manage ClaudeBar's GitHub Actions CI/CD pipelines: build, test, and release workflows. Use this skill when: (1) Setting up secrets for CI/CD (certificate, API key, Sparkle key, Codecov) (2) Creating a new release — tag-based or manual workflow_dispatch (3) Triggering or explaining the build.yml, tests.yml, or release.yml workflows (4) Debugging release failures (signing, notarization, appcast) (5) Managing beta vs stable channels for Sparkle auto-updates (6) User says "release a new version", "push a tag", "set up CI secrets", "why did the release fail"
development
Guide for adding new report cards to ClaudeBar that analyze local data sources and display metrics with comparison deltas. Use this skill when: (1) Adding a new report/analytics card (e.g., weekly summary, model breakdown, session stats) (2) Creating data analysis features that read local files and display aggregated metrics (3) Adding comparison cards that show "today vs previous" style deltas (4) Building any feature that follows the DailyUsage pattern (parse → aggregate → report → card)