review-loop
Skill11 starsChanged 4 months agoMITView on GitHub
Use only when the user explicitly asks to review, fix, and re-review a branch or PR until clean, or when an active ship/checkpoint workflow invokes it — "run the review loop", "review and fix until it passes", "loop review on this PR".
- Deletes or force-pushes
- Commits and pushes
We split this skill into the rules it gives an agent
11 rules. 0 are common, 2 are distinctive, and 9 are very specific to this project.
0
Common
Most of the 42 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 19
Create LOOP_DIR=$(mktemp -d "${TMPDIR:-/tmp}/tgc-review-loop.XXXXXX") and tell the user progress: tail -f <LOOP_DIR>/status.
- Very specific: line 23
Stall watch while it runs: wait with one foreground Bash call (timeout: 600000), repeated as needed, never sleep across turns:
- Very specific: line 33
Only after the subagent's completion arrives: relay the final report, then rm -rf "$LOOP_DIR".
- Very specific: line 44
Run "${CLAUDE_PLUGIN_ROOT}/scripts/pr-context.sh" --local [argument].
- Very specific: line 65
Keep $LOOP_DIR/history.md with one section per review: verdict, mode, partial, fingerprints, what was fixed, and dismissals with reasons.
- Very specific: line 83
every file in git diff --name-only <last full target_sha>..HEAD is in that full review's coverage.
- Very specific: line 91
Fix round r: read ${CLAUDE_PLUGIN_ROOT}/skills/review-fix/SKILL.md and follow it in loop-driven mode with the latest findings.json.
- Distinctive: line 96
Fix the class: when a finding belongs to a defect family an earlier round already fixed (same value, invariant, or sibling call site), tell …
- Very specific: line 111
Before the push, discover and run the repo's full reproducible local gate from its instructions, pre-push hook, and project scripts.
- Distinctive: line 138
If it fails, stop and report instead of pushing.
- Very specific: line 155
If a PR exists, post one comment (gh pr comment <number> --body-file <file>) with the outcome, fix rounds, fixed findings, dismissals with …
“Common” is measured: kept by at least 6 in 10 of the 42 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
Review Loop — review → fix → re-review until clean
Proceed only when the surrounding user request explicitly asks for the loop (including
direct /tgc-skills:review-loop invocation) or tgc-skills:ship/tgc-skills:checkpoint
invokes it. It commits fixes and pushes once, so stop without that authorization.
Review with tgc-skills:review, fix with tgc-skills:review-fix, and repeat until a
review approves or a stop condition is reached. Fixes are committed locally and pushed
once at the end. Never merge, never force-push.
Keep the loop out of the main context
- Create
LOOP_DIR=$(mktemp -d "${TMPDIR:-/tmp}/tgc-review-loop.XXXXXX")and tell the userprogress: tail -f <LOOP_DIR>/status. - Launch one background
general-purposesubagent with the repo path, the optional argument,LOOP_DIR, and the workflow below. - Stall watch while it runs: wait with one foreground Bash call
(
timeout: 600000), repeated as needed, neversleepacross turns:for i in $(seq 19); do tail -n 1 "$LOOP_DIR/status" | grep -q ' exit ' && echo EXITED && break; [ -n "$(find "$LOOP_DIR/status" -mmin +15)" ] && echo STALE && break; sleep 30; doneEXITEDor the subagent's completion → step 4.STALE(no status line for 15 minutes) → read the status tail and send the subagent one message to resume from that line. Stale again → report the stall to the user with the status tail and theLOOP_DIRpath instead of waiting. A stale status is a stall signal, not proof the subagent exited, so keepLOOP_DIRand never push or clean up on its behalf. - Only after the subagent's completion arrives: relay the final report, then
rm -rf "$LOOP_DIR".
Subagent workflow
Shell state does not persist between commands. Keep LOOP_DIR, LOOP_BASE, the base,
and each review's outputs in your notes and paste them into each command. Run every step
in the foreground; a background job's result never wakes this subagent.
Setup and heartbeat
- Run
"${CLAUDE_PLUGIN_ROOT}/scripts/pr-context.sh" --local [argument]. It stops on the default branch, a branch argument that is not the checked-out branch, a PR from another repository or head branch, and a dirty tree (staged, unstaged, or untracked files are reported, never silently excluded). A non-zero exit isblocked; report its reason. Notenumber(may be empty),base, andbranch. Neversourceorevalits output. Fetch the base and record the start. Always reference the base ref quoted; a valid Git ref can contain shell metacharacters:
BASE_REF="<base>" git fetch origin "$BASE_REF" LOOP_BASE=$(git rev-parse HEAD): > "$LOOP_DIR/status", then append one line per state change (started, review dispatched, verdict, fixing, committed, gate, pushed,exit <outcome>):printf '%s %s\n' "$(date -u +%FT%TZ)" "<event>" >> "$LOOP_DIR/status"Keep
$LOOP_DIR/history.mdwith one section per review: verdict, mode, partial, fingerprints, what was fixed, and dismissals with reasons.
Loop — at most 3 fix rounds
The final confirming review does not count as a fix round.
Review k: invoke tgc-skills:review local out=$LOOP_DIR/review-<k> [PR]. The first
review is full. Every later review adds delta <previous target_sha> <previous findings>.
Record verdict, findings, target_sha, target_tree, mode, coverage, and
partial in history.md.
INCOMPLETE→ retry the same review once into a newout=directory. A secondINCOMPLETE→ exitblocked.REQUEST_CHANGES→ fix round, or exitmax-iterationsif 3 fix rounds are spent.APPROVEfrom a full review → exitclean.APPROVEfrom a delta review → exitcleanonly when all of these hold:- the last full review was not
partial; - every file in
git diff --name-only <last full target_sha>..HEADis in that full review'scoverage; - none of those changes touch migrations, dependency manifests or lockfiles, or auth, session, or permission code.
Otherwise run one confirming full review at the same
HEAD(nodelta). ItsAPPROVE→clean. Its findings → a fix round, ormax-iterationsafter round 3.- the last full review was not
Fix round r: read ${CLAUDE_PLUGIN_ROOT}/skills/review-fix/SKILL.md and follow it in
loop-driven mode with the latest findings.json. It is user-invocation-only, so the
Skill tool cannot load it, and a read file keeps its placeholders: replace each CLAUDE_PLUGIN_ROOT placeholder in it, and in every plugin file it points to, with ${CLAUDE_PLUGIN_ROOT}. It fixes, runs lint, typecheck, and the tests covering each
changed contract, and commits locally without pushing. Then go to the next review.
- Fix the class: when a finding belongs to a defect family an earlier round already
fixed (same value, invariant, or sibling call site), tell the fix pass to enumerate
every writer and consumer of that value across the repo and fix the whole class in one
commit. Record the enumeration in
history.md. - Non-converging: the same fingerprint still unresolved after two consecutive fix
rounds, or a round that commits nothing → exit
non-convergingwith the findings and the fix pass's reasons.
Exit
Outcomes: clean, max-iterations, non-converging, or blocked (unsafe state, two
INCOMPLETE reviews, auth or push failure, remote diverged). blocked never pushes.
1. Full local gate, once
Before the push, discover and run the repo's full reproducible local gate from its
instructions, pre-push hook, and project scripts. Do not claim that workflow run: lines
reproduce action steps, matrices, services, or external checks; with no local gate, say
CI remains authoritative. The gate must leave the tree clean. On a clean exit, hand
gate failures to a fix round as findings if one remains (then review again), else exit
max-iterations. On other exits, report the failure with the push.
2. Squash on a clean exit
Count only commits created after LOOP_BASE:
N=$(git rev-list --count "$LOOP_BASE"..HEAD)N=0orN=1: no rewrite.N>1: confirm you are still on the branch the loop started on and thatgit merge-base --is-ancestor "$LOOP_BASE" HEADsucceeds; if either check fails, stop and report instead of resetting. Otherwisegit reset --soft "$LOOP_BASE"and create one commit using the repo's convention (fallbackfix: address review findings).
The squash changes the SHA, not the tree. Bind the push to the reviewed tree:
test "$(git rev-parse 'HEAD^{tree}')" = "<final review target_tree>"If it fails, stop and report instead of pushing. Non-clean exits push the loop commits as they are.
3. Push once
Push to one explicit destination, origin and refs/heads/<branch>, whatever the
branch's upstream says. Right before pushing, run
git ls-remote --heads origin "refs/heads/<branch>". If it fails (network or auth), exit
blocked. If it prints nothing, the branch is unpublished. Otherwise its first field is
the remote tip: run git fetch origin "<branch>", and if
git merge-base --is-ancestor <remote tip> HEAD fails, the remote diverged: exit
blocked without retrying. Then run git push origin "HEAD:refs/heads/<branch>", adding
-u when the branch has no upstream. N=0 still pushes, so a clean but unpublished branch is published. Never
force-push.
4. Closing report
If a PR exists, post one comment (gh pr comment <number> --body-file <file>) with the
outcome, fix rounds, fixed findings, dismissals with reasons, local gate evidence,
unresolved items, the final reviewed tree, and the pushed SHA. Quote
gh pr checks <number> as it stands; checks still pending on the new push are reported
as pending, never as passed. Never post per-round comments.
Return the same facts and the final review verdict to the main session. Merging remains the user's action.
Other versions48 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 48
- didi/mpx★ 4ksame name
- blockscout/frontend★ 310same name
- microsoft/bocpy★ 184same name
- 9thLevelSoftware/legion★ 76same name
- microsoft/Trieste★ 53same name
- timharris707/skills★ 43same name
- spxrogers/agentsync★ 35same name
- mathruffian-dot/claude-motion-explainer★ 30same name
- mthines/agent-skills★ 20same name
- mmnto-ai/totem★ 18same name
38 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.
Used alongsideProjects with it also use motion-design, to-spec 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.
Dragoon0xSkillmotion-design
Animation as communication. Feedback, orientation, emphasis, delight. If motion doesn't serve one of these four purposes, it shouldn't exist. Use when evaluating animation quality, designing transitions, or deciding whether motion adds or subtracts.
Also in 3 projects that use this
GoogleSkillto-spec
Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
Also in 4 projects that use this
GoogleSkillimprove-codebase-architecture
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
Also in 5 projects that use this
NVIDIASkillresearch
Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.
Also in 5 projects that use this
MicrosoftSkilldiagnose
Use to systematically diagnose why scenarios fail — identifies root causes by analyzing agent traces, codebase, and behavioral patterns
Also in 3 projects that use this
photon-groveSkillunslop
Detects and rewrites generic, overly polished, or AI-sounding prose while preserving meaning. Use when the user asks to "unslop", humanize, de-AI, tighten, or review whether writing sounds generated.
Also in 3 projects that use this
- +5 more from google
In this repository12 other files it gives its agents.
- checkpointSkill
- cmux-orchestrateSkill
- explain-prSkill
- herdr-orchestrateSkill
- mergedSkill
- orchestrate-listSkill
- orchestrate-planSkill
- orchestrateSkill
- polishSkill
- review-fixSkill
- reviewSkill
- shipSkill
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.

