fix
Skill52 starsChanged 49 days agoMITView on GitHub
Debug and fix a reported defect, such as a failing build or tests, runtime or console errors, regressions, merge conflicts, red PR checks. Triggers "fix", "broken", "not working", "merge conflict", "fix CI".
82 other projects use a version of this.
Adopted by
Most recently taken up by
- tyrantpiper/travel-pwatheir own version, first seen Nov 8, 2026
- Eclipter/agentstheir own version, first seen Nov 8, 2026
- Bhenderlong/vallorix-mcp-plugintheir own version, first seen Nov 8, 2026
- KadirHarmanc/nazar-skilltheir own version, first seen Nov 8, 2026
- zedarvates/frugal-skillstheir own version, first seen Nov 8, 2026
- ribato22/vibechecktheir own version, first seen Nov 8, 2026
Used with
Projects with it also use feature, frontend-code-review and 8 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.
bradtraversySkillfeature
Manage current feature workflow - start, review, explain or complete
Also in 10 projects that use this
chendongqiSkillfrontend-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
GoogleSkillpr-creator
Also in 4 projects that use this
PJuniszewskiSkillcook
Feature development with guardrails. Plan → Review → Code → Ship.
Also in 3 projects that use this
vbrevikSkillwork
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 AzureSkilltest
Also in 12 projects that use this
Other versions82 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 82
- react/react★ 252ksame name
- facebook/react★ 252ksame name
- motiondivision/motion★ 35ksame name
- parcadei/Continuous-Claude★ 3.9ksame name
- parcadei/Continuous-Claude-v2★ 3.9ksame name
- parcadei/Continuous-Claude-v3★ 3.9ksame name
- crbnos/carbon★ 2.8ksame name
- Akylas/OSS-DocumentScanner★ 2.6ksame name
- kdlbs/kandev★ 1.1ksame name
- GoogleCloudPlatform/magic-modules★ 975same name
72 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository27 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/AGENTS.mdAGENTS.md
- auditSkill
- autoresearchSkill
- buildSkill
- case-studySkill
- ccSkill
- codexSkill
- componentSkill
- context-docSkill
- dr-initSkill
- dr-reviewSkill
- freezeSkill
- handoffSkill
- harvestSkill
- hookSkill
- orchestrateSkill
- poke-holesSkill
- proof-of-workSkill
- refactorSkill
- retroSkill
- review-batchSkill
- share-learningSkill
- shipSkill
- storiesSkill
- triageSkill
- zero-tech-debtSkill
The file
We split this skill into the rules it gives an agent
12 rules. 0 are common, 8 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 75 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
Use Context7 only when the user configured it.
- Distinctive: line 45
No fix until the causal chain from trigger to symptom is complete, with file:line evidence at each link.
- Very specific: line 48
Learn: - If this was a non-obvious fix, the auto-memory system in ~/.claude/CLAUDE.md captures it.
- Distinctive: line 52
Follow the AGENTS.md guardrails (Bug Fix Scope, 2-Iteration Limit, Name the Cause, Verify After Every Fix).
- Very specific: line 86
Standalone Codex branch: follow the lifecycle and serialization rules at the top.
- Very specific: line 100
If the codex-verifier spawn fails, or it reports that Bash was stripped (forked skill contexts), run bun …
- Distinctive: line 112
Learning stored: If applicable
- Distinctive: line 122
If the failure is unresolved git merge conflicts (not a code bug), skip the explore/tester loop:
- Distinctive: line 127
Run compile, lint, and relevant tests.
- Distinctive: line 132
Avoid broad refactors while resolving conflicts — separate PR for cleanup.
- Very specific: line 136
If the failure is on a pushed branch with an open PR (not a local bug), use gh pr checks as the source of truth — it covers all PR-attached …
- Distinctive: line 149
If the failure is clearly unrelated to the PR and already fixed on main, merge main into the branch instead of bloating the PR with …
“Common” is measured: kept by at least 6 in 10 of the 75 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.
Files
Bug Fix Workflow
Standalone Codex
Skip Claude's !command interpolation below. Run git
branch --show-current, git log --oneline -5, and git status --porcelain
explicitly. Create each new agent with spawn_agent, continue a live agent with
send_message, trigger another turn for an idle existing agent with
followup_task, wait with wait_agent, and stop a current turn with
interrupt_agent only when necessary. Never spawn codex-verifier and never
run codex-run.ts from inside Codex.
Writers share the working tree unless the live host explicitly offers isolation. Give every writer non-overlapping ownership and serialize the test-writer, implementer, and verification writer phases. Only read-only reviewers may overlap. Wait until the explorer finishes before starting a test writer; wait until that writer finishes before implementation. Codex implementers are not promised Claude worktree isolation.
Use Context7 only when the user configured it. Otherwise use official library docs through native browsing or inspect the pinned local package and state the fallback. This package does not auto-run unpinned registry MCP packages.
You are in Maestro orchestration mode. Delegate immediately to specialized agents.
Current State
- Branch: !
git branch --show-current 2>/dev/null || echo "unknown" - Recent commits: !
git log --oneline -5 2>/dev/null || echo "no commits" - Uncommitted changes: !
git status --porcelain 2>/dev/null | head -10
Workflow
- Clarify - If the report admits more than one reading (which surface, which environment, what "fixed" looks like), run clarifying rounds through the host's question tool until no fork is left, before exploring; a report that names the file, the symptom, and the expected behaviour skips this. When a round runs and the user named no Linear issue, add one question: create one now (recommended: yes)? Create it per the
shipskill's "Linear issue" step and put its ID in the branch name. Never open a round only for this:/shipcreates the issue anyway - Explore - Spawn
exploreagent to understand the affected codebase area - Reproduce - Spawn
testeragent to create a failing test if possible - Diagnose - Analyze findings to identify root cause. Commits named in the bug report are hypotheses, not conclusions — blame the actually-affected file's history before fixing; regressions often ride in earlier on the same branch as the change that got blamed. Before blaming, fetch the team-knowledge index and read any note whose title matches the error's nouns; the fetch command is in docs/knowledge-system.md (fail-open — skip if
ghis unavailable)- A prediction must name something not yet looked at (another code path, an observable the first hypothesis did not touch). One that restates the symptom or only re-reads the suspect line is rejected.
- The user's own uncommitted edits are hypothesis 1. Test them:
git stash push -u -m <unique-tag>, rerun the reproducer, then restore only the entry this run created: find itsstash@{n}by the tag ingit stash list,git stash apply --index stash@{n}so staged state comes back too, andgit stash drop stash@{n}only after the apply succeeds. Never pop other entries. If the push reports nothing to save, restore nothing. - No fix until the causal chain from trigger to symptom is complete, with file:line evidence at each link. "Somehow X leads to Y" is a gap.
- Implement - Spawn
implementeragent to fix the issue - Verify - Spawn
testeragent to confirm the fix - Learn - If this was a non-obvious fix, the auto-memory system in
~/.claude/CLAUDE.mdcaptures it; for team-wide gotchas use/share-learningto post to the team-knowledge repo
Scope Rules
Follow the AGENTS.md guardrails (Bug Fix Scope, 2-Iteration Limit, Name the Cause, Verify After Every Fix). Only modify files directly related to the bug.
Autonomous fix-verify loop: once the reproducer exists, set
/goal the reproducer test passes and the full suite is green, or stop after 5 attempts
to keep iterating without re-prompting. Keep the 2-iteration scope rule in mind when
choosing the stop clause.
Agent Delegation
Spawn explore and tester first — these accept thin prompts because they discover what they need from the codebase:
Agent(explore, "Investigate the bug: $ARGUMENTS. Find relevant files, trace the issue.")
Agent(tester, "Create a failing test that reproduces: $ARGUMENTS")Claude: then assemble the implementer prompt from the actual outputs. The Claude implementer runs in an isolated worktree with no access to prior agent results, so paste real content — not placeholders, not references:
- The user's original ask (
$ARGUMENTS) verbatim - The exact file paths + line ranges
explorereported (copy them in) - The recommended fix
exploreidentified, quoted line-by-line — not "based on findings" - The build/test command the tester wrote (or repro steps)
- Scope: "only the files listed above; do not refactor adjacent code"
Now spawn:
Agent(implementer, "<the assembled briefing above — all five items inline>")
Agent(reviewer, "Quick review of the fix for quality and edge cases")Standalone Codex branch: follow the lifecycle and serialization rules at
the top. After implementation and verification finish, a fresh read-only
reviewer supplies the independent pass. Skip the Claude bridge branch below.
Any fix that produced a diff gets a cross-model review in parallel with the reviewer, when the Codex bridge is available — a non-Claude family is the cheapest insurance against a logic error you just wrote:
Agent(codex-verifier, "Cross-model review of the fix diff. Focus on correctness and security. Report findings by severity.")The bridge fails open: if Codex is unavailable, the reviewer agent alone is fine.
If the codex-verifier spawn fails, or it reports that Bash was stripped (forked skill contexts), run bun "$HOME/.claude/src/scripts/codex-run.ts" review directly instead — never skip the cross-model pass.
Skip the implementer step if explore reports the bug is non-reproducible or
already fixed in current HEAD.
Output
Return a concise summary:
- Root cause: What was wrong
- Fix applied: What changed
- Files modified: List of files
- Verification: How it was tested
- Learning stored: If applicable
Remember
- On an OS, device, vendor, or network blocker, apply the AGENTS.md stop-loss: about 20 minutes or 30 tool calls, then a written diagnosis (ruled out with evidence, likely cause, ranked next options) instead of another attempt
Variant: Merge Conflicts
If the failure is unresolved git merge conflicts (not a code bug), skip the explore/tester loop:
- Detect conflicts:
git diff --name-only --diff-filter=Ulists conflicted paths. - Resolve each conflict with minimal, correctness-first edits. Prefer preserving both sides when safe; otherwise choose the variant that compiles and keeps public behavior stable.
- Regenerate lockfiles with the package manager (
bun install,npm install, etc.) rather than hand-editing. - Run compile, lint, and relevant tests.
- Stage resolved files and summarize key decisions in the commit message.
Guardrails:
- Avoid broad refactors while resolving conflicts — separate PR for cleanup.
Variant: Failing PR CI
If the failure is on a pushed branch with an open PR (not a local bug), use gh pr checks as the source of truth — it covers all PR-attached checks, not just GitHub Actions:
- Resolve the PR:
gh pr view --json number,url,headRefName. - Inspect attached checks:
gh pr checks --json name,bucket,state,workflow,link. - For each failed check, fetch logs:
- GitHub Actions:
gh run view RUN_ID --log-failed. - External services: follow the check
linkto the provider.
- GitHub Actions:
- Extract the first actionable error. Apply the smallest safe fix.
- Push and re-check. The check set can change between runs — re-read
gh pr checksafter every push. To wait for the result, use theshipskill's Step 9 watch; do not write a polling loop.
Guardrails:
- Fix one actionable failure at a time.
- If the failure is clearly unrelated to the PR and already fixed on main, merge main into the branch instead of bloating the PR with unrelated fixes.
- For flaky checks, retry once and report flake evidence rather than chasing a phantom fix.
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
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.

