agentleFS
Sign inStart free
danielvm-gitdanielvm-git/bigpowers/skills/fix-bug/SKILL.md

fix-bug

Skill288 starsChanged 5 days agoMITView on GitHub

Bug fix orchestrator — active_flow fix_bug; reads specs/bugs/BUG-*.md; chains investigate-bug, develop-tdd, validate-fix. Use when user reports a defect.

40 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use improvement, build-feature and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • kiminmonacoSkill

    improvement

    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.

    Also in 4 projects that use this

  • sirakinbSkill

    build-feature

    Autonomous task loop that picks ready tasks, implements them, updates progress.txt, commits, and repeats. Use when asked to 'build feature', 'run the loop', or 'implement these tasks'.

    Also in 5 projects that use this

  • kiminmonacoSkill

    implement-feature

    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

    Also in 7 projects that use this

  • SentrySkill

    write-tests

    Write tests following project conventions. Use when adding new tests or modifying existing ones.

    Also in 6 projects that use this

  • JetBrainsSkill

    create-plan

    Research the codebase and create an implementation plan with architecture notes, design document, and track decomposition. Use when starting a new feature or large change.

    Also in 4 projects that use this

  • JasonPaffSkill

    implement-plan

    Execute implementation plan with structured tracking and validation using subagent architecture

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 40 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Create specs/bugs/BUG-*.md via investigate-bug (or inline in fix-bug step 1) describing the gate failure, then run the standard fix_bug …

    line 25
  2. Very specific:

    Step 1 — investigate-bug: If no specs/bugs/BUG-*.md, run investigate-bug first — it handles history check, RCA (via diagnose-root), fix …

    line 47
  3. Distinctive:

    Step 2 — diagnose-root: Run 4-phase RCA (reproduce → isolate → hypothesize → verify).

    line 48

“Common” is measured: kept by at least 6 in 10 of the 40 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Fix Bug

Boundary: Orchestrator flow — chains investigate-bug (entry point + RCA via diagnose-root) → develop-tdd → validate-fix. Does not implement RCA or write bug files directly.

Orchestrates fix_bug flow without mixing epic build state.

HARD GATE — Set specs/state.yaml active_flow: fix_bug and bug_cycle.current_step: 1 before starting.

Discovered gate failures (e51s04)

Valid entry without a user-reported bug when:

  • Preflight or CI is red at kickoff or verify-work
  • Golden suite or project baseline is red (bash scripts/run-verification-gates.sh or equivalent)
  • A reproducible gate failure during unrelated epic work exceeds quick-fix guardrails

Create specs/bugs/BUG-*.md via investigate-bug (or inline in fix-bug step 1) describing the gate failure, then run the standard fix_bug chain.

Five steps (bug_cycle in state.yaml)

StepSkill / action
1investigate-bug — create BUG-*.md with RCA
2diagnose-root — 4-phase root cause analysis
3develop-tdd — red-green against bug file verify steps
4validate-fix — re-run failing test, full suite, lint
5release-branch — PR or solo land the fix

Checkpoint / resume

Track progress via specs/state.yaml bug_cycle:

  • bug_cycle.current_step: current step (1–5)
  • bug_cycle.completed_steps: completed step numbers
  • handoff.next_skill: skill for the current step
  • On resume, read bug_cycle.current_step and continue from there

Process

  1. Step 1 — investigate-bug: If no specs/bugs/BUG-*.md, run investigate-bug first — it handles history check, RCA (via diagnose-root), fix approach, and writes the bug file. Increment bug_cycle.current_step to 2 on completion.
  2. Step 2 — diagnose-root: Run 4-phase RCA (reproduce → isolate → hypothesize → verify). Record findings in the bug file. Increment to step 3.
  3. Step 3 — develop-tdd: develop-tdd against the bug file's verify steps. Increment to step 4 on all-green.
  4. Step 4 — validate-fix: validate-fix — re-run failing test, full suite, typecheck, lint. Increment to step 5.
  5. Step 5 — release-branch: Land the fix via release-branch. Clear bug_cycle and active_flow when done.

Bug file SoT

One markdown file per bug with frontmatter:

---
bug_id: BUG-001
status: open
severity: high
scope: api
title: Short title
---

Verify

→ verify: test -d specs/bugs && test -f scripts/run-skill-verify.sh

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free