fix-github-issues
Skill5 starsChanged 10 days agoMITView on GitHub
Verify, triage, fix, and close review-bot GitHub issues one finding at a time.
In this repository57 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architecture-satisfactionSkill
- autopilotSkill
- browser-testSkill
- chatter-scoutSkill
- closeoutSkill
- codebase-designSkill
- code-reviewSkill
- code-smells-auditSkill
- commitSkill
- dependency-auditSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- fix-ci-failuresSkill
- fix-nightwatch-issuesSkill
- fix-posthog-issuesSkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- harness-toolsSkill
- housekeeperSkill
- implementSkill
- implement-specSkill
- improve-codebase-architectureSkill
- laravel-herd-worktreesSkill
- panelSkill
- prototypeSkill
- prSkill
- prune-testsSkill
- releaseSkill
- repository-cleanupSkill
- researchSkill
- resolve-review-commentsSkill
- resolving-merge-conflictsSkill
- retroSkill
- run-afterSkill
- scratch-cleanupSkill
- scratch-statusSkill
- setupSkill
- sweepSkill
- tddSkill
- teachSkill
- to-questionnaireSkill
- to-specSkill
- to-ticketsSkill
- triage-github-prSkill
- triageSkill
- ui-designSkill
- upgrade-planSkill
- verifySkill
- wait-whatSkill
- wayfinderSkill
- which-skillSkill
- wizardSkill
- writing-for-agentsSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 16
Project context: Read .agents/github-review.md when the repo has one.
- Very specific: line 51
Verify each line, delegate a set of more than 5, and run the second pass against the project's auto-dismiss and never-dismiss lists before …
- Distinctive: line 72
Run that test file against the repo's configured test database when you can.
- Distinctive: line 116
If you later find a misclassified finding, reopen the issue with a correction note.
- Very specific: line 123
Remove nothing before this step.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Fix GitHub Issues
Work the open issues that a review bot filed. Each issue is a container of findings: some are legit, some stale, some wrong. Every finding earns its own verdict from the code on the default branch, never from the issue's headline. An issue closes only when no legit finding is left in it, and a fix counts only once it reaches the default branch.
Project context. Read .agents/github-review.md when the repo has one. Its
sections ## Review bots (with the bot's issue label), ## Auto-dismiss,
## Never dismiss, and ## Stack facts (what the bots get wrong) hold this repo's
facts; a missing section means the default here. Then follow the repo's AGENTS.md /
CLAUDE.md rules for tests, lint, cache clears, and a dirty tree.
1. Build the working set
Find the default branch (written <default> below), run git fetch origin, and
verify everything against origin/<default>, not a local branch. List every open issue
with the bot label (or the ones the user named), newest first. The calls, and the
check that the list is not cut off at its limit, are in references/mechanics.md.
Walk order is newest to oldest, but let evidence reorder it. A newer diff that introduced a defect an older issue already flagged makes the older finding LEGIT, and you fix both in one commit chain. A newer commit that fixed an older finding makes that finding STALE: cite the sha.
Completion criterion: every open issue in scope is listed, newest first, with fewer issues than the limit.
2. Classify every finding
For each issue, read its body and every comment (note any "fixed in <sha>" or "false
positive" from earlier runs). Read the commits it reviewed. Then write one line per
finding:
Finding N: [STALE | AUTO-DISMISS | HALLUCINATION | LEGIT] — <one-line evidence>Finding 1: STALE — fixed in bf707fde3, see app/Foo.php:42Finding 3: HALLUCINATION — rg 'BarPolicy::class' returns 0; symbol does not existFinding 4: LEGIT — app/Auth.php:88 still uses < instead of <=, exploitable on token boundary
Verify each line, delegate a set of more than 5, and run the second pass against the
project's auto-dismiss and never-dismiss lists before any code, all by
Verify findings, with origin/<default> as the ref.
You re-read the LEGIT code for the fix anyway.
Completion criterion: every finding in the working set has a line, and the second pass is done.
3. Fix the legit ones
Work on a new branch fix/issues-<run> from origin/<default>, always in a worktree
(Branch or worktree). The main checkout
stays on the branch the run found it on, including when that tree is clean.
Per LEGIT finding: make the minimal change, with no drive-by refactors. Prove it per the
tdd skill's What needs a test: a test for
behaviour, run that test file green; verify for a presentation change. A user message to stop the
tests ends test commands for the rest of the run: the last focused result stands, and
the commits continue. Commit each fix on its own (Conventional
Commits, explicit staging). Put fixes #NNN only on the commit that resolves the
issue's last legit finding, so the issue closes at the right moment.
Run that test file against the repo's configured test database when you can. A run that needs its own database names and registers it by Scratch databases.
A LEGIT finding you cannot fix (a secret rotation, infra, a human decision) keeps the issue OPEN; step 5 names the blocker.
Completion criterion: every fixable LEGIT finding has a commit on fix/issues-<run>,
with a green test where it needs one, and every unfixable one is named.
4. Land the fixes
An issue closes only when its fixes #NNN commit reaches <default>, so a local
commit fixes nothing yet. Show the user the commits and the issues each one closes, say
where they will go, and land them without asking: push to <default> by default; open a
pull request instead when branch protection or the repo's rules forbid direct pushes. A
user instruction in the input or the conversation ("open a PR", "keep them local")
overrides both. The commands are in Land.
Once they are landed, the main checkout is still the branch recorded at the start (The checkout stays). The fix branch stays in its worktree. Do the same check if the run stops early.
Completion criterion: the commits are on <default>, in an open pull request, or kept
local by the user's instruction, and git branch --show-current in the main checkout
is still the starting branch.
5. Post a disposition
Post one comment per issue in the working set, with one bullet per finding (calls in Disposition and close):
- Finding 1 (X): fixed in <sha>
- Finding 2 (Y): stale — superseded by <sha>
- Finding 3 (Z): auto-dismiss — <category>
- Finding 4 (W): hallucination — symbol does not exist at claimed location- Fixed on
<default>: the push closed it; post the comment after. - Nothing legit: post the comment, then close the issue.
- Fix in an open pull request or kept local: the issue stays open; the comment says where the fix is.
- A LEGIT finding you cannot fix: the issue stays open; the comment names the blocker.
If you later find a misclassified finding, reopen the issue with a correction note.
Completion criterion: every issue has its comment, and gh issue view N --json state
agrees with it.
6. Clean up
Remove nothing before this step. Then clean up what you created by
laravel-herd-worktrees' What is left rule (Clean up):
a worktree and its databases whose fixes are on <default> (or that fixed nothing) go
without asking; a refused worktree, and one whose fixes are in an open pull request or
kept local, go into the one question. What stays stays registered, for repository-cleanup.
Completion criterion: everything removable is removed, any question is answered, or you
created nothing. Report the tally:
fixed, stale, auto-dismiss, hallucination, and blocked. Name each fix not yet on
<default>, and each worktree or database kept. Mark the blocked count and each kept
item ⚠️; no other marks.
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.

