agentleFS
Sign inStart free
SnoozleStudioSnoozleStudio/opencode-wp-settings/skills/fix/SKILL.md

fix

Skill4 starsChanged 3 days agoMITView on GitHub

Debug and fix bugs, errors, and failures — including merge conflicts and failing CI checks. Use for "fix", "broken", "not working", "bug", "error", "failing". Runs explore → reproduce → diagnose → implement → verify, with the 2-iteration limit and bug-fix scope confinement.

85 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use feature, frontend-code-review and 9 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.
  • bradtraversySkill

    feature

    Manage current feature workflow - start, review, explain or complete

    Also in 10 projects that use this

  • chendongqiSkill

    frontend-code-review

    Trigger when the user requests a review of frontend files (e.g., `.tsx`, `.ts`, `.js`). Support both pending-change reviews and focused file reviews while applying the checklist rules.

    Also in 4 projects that use this

  • GoogleSkill

    pr-creator

    Also in 4 projects that use this

  • PJuniszewskiSkill

    cook

    Feature development with guardrails. Plan → Review → Code → Ship.

    Also in 3 projects that use this

  • vbrevikSkill

    work

    Use when the user says 'plan', 'todo', 'copy plan', 'append plan', 'resume plan', 'priorities', or 'what's next'.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    test

    Also in 12 projects that use this

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 78 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    2-iteration limit: after 2 failed attempts, stop, summarize, present 2-3 alternatives, ask

    line 36

“Common” is measured: kept by at least 6 in 10 of the 78 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

Bug Fix Workflow

Bugs get fixed immediately — no "should I?" questions. But never stack untested fixes.

Hard bugs (intermittent, environment-specific, resistant to the loop below) escalate to the diagnosing-bugs skill: reproduce → minimize → hypothesize → instrument → fix → regression-test. This workflow covers standard bugs; use it unless the symptoms say otherwise.

Workflow

  1. Explore — spawn explore to map the affected area (neutral prompts: "analyze the logic and report all findings", not "find the bug")
  2. Reproduce — get the failure on screen. Run the failing command/flow, capture the error. No repro = no diagnosis
  3. Diagnose — name the root cause in one sentence before touching code. Commits named in the bug report are hypotheses, not conclusions — blame the actually-affected file's history; regressions often rode in earlier on the same branch. If the sentence needs "I think"/"maybe", gather more signal (screenshots, computed styles, logs)
  4. Implement — spawn implementer with a complete briefing (verbatim ask, file paths, scope). Scope confinement: only files directly related to the bug; no adjacent refactors; no dependency upgrades
  5. Verify — run the canonical verification chain (build → format:all:check → phpcs → phpstan, see docs/verification-chain.md). Build after EVERY fix attempt, confirm green before moving on
  6. Learn — non-obvious fix? Append a dated entry to the project's AGENTS.md self-evolving learnings log

Rules

  • 2-iteration limit: after 2 failed attempts, stop, summarize, present 2-3 alternatives, ask
  • Regression vs contract change: a test/check failing after your change is either a regression (fix the code, never relax the check) or an intentional contract change (update implementation + assertion in the same diff, say which contract changed). When unsure, treat as regression
  • Failing PR CI: gh pr checks is the source of truth; fix one actionable failure at a time; if unrelated to the PR and already fixed on main, merge main in instead
  • Merge conflicts: resolve hunk by hunk by intent; regenerate lockfiles, never hand- edit; no broad refactors mid-conflict

Output

Root cause (one sentence) / fix applied / files modified / verification commands + result / learning stored (if any). Fail loud if anything was skipped or mocked.

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