agentleFS
EternallLightEternallLight/tgc-skills/skills/review-loop/SKILL.md

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
  1. Very specific:

    Create LOOP_DIR=$(mktemp -d "${TMPDIR:-/tmp}/tgc-review-loop.XXXXXX") and tell the user progress: tail -f <LOOP_DIR>/status.

    line 19
  2. Very specific:

    Stall watch while it runs: wait with one foreground Bash call (timeout: 600000), repeated as needed, never sleep across turns:

    line 23
  3. Very specific:

    Only after the subagent's completion arrives: relay the final report, then rm -rf "$LOOP_DIR".

    line 33
  4. Very specific:

    Run "${CLAUDE_PLUGIN_ROOT}/scripts/pr-context.sh" --local [argument].

    line 44
  5. Very specific:

    Keep $LOOP_DIR/history.md with one section per review: verdict, mode, partial, fingerprints, what was fixed, and dismissals with reasons.

    line 65
  6. Very specific:

    every file in git diff --name-only <last full target_sha>..HEAD is in that full review's coverage.

    line 83
  7. Very specific:

    Fix round r: read ${CLAUDE_PLUGIN_ROOT}/skills/review-fix/SKILL.md and follow it in loop-driven mode with the latest findings.json.

    line 91
  8. Distinctive:

    Fix the class: when a finding belongs to a defect family an earlier round already fixed (same value, invariant, or sibling call site), tell …

    line 96
  9. Very specific:

    Before the push, discover and run the repo's full reproducible local gate from its instructions, pre-push hook, and project scripts.

    line 111
  10. Distinctive:

    If it fails, stop and report instead of pushing.

    line 138
  11. Very specific:

    If a PR exists, post one comment (gh pr comment <number> --body-file <file>) with the outcome, fix rounds, fixed findings, dismissals with …

    line 155

“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.

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

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

  1. Create LOOP_DIR=$(mktemp -d "${TMPDIR:-/tmp}/tgc-review-loop.XXXXXX") and tell the user progress: tail -f <LOOP_DIR>/status.
  2. Launch one background general-purpose subagent with the repo path, the optional argument, LOOP_DIR, and the workflow below.
  3. Stall watch while it runs: wait with one foreground Bash call (timeout: 600000), repeated as needed, never sleep across 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; done
    EXITED or 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 the LOOP_DIR path instead of waiting. A stale status is a stall signal, not proof the subagent exited, so keep LOOP_DIR and never push or clean up on its behalf.
  4. 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

  1. 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 is blocked; report its reason. Note number (may be empty), base, and branch. Never source or eval its output.
  2. 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)
  3. : > "$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.md with 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 new out= directory. A second INCOMPLETE → exit blocked.
  • REQUEST_CHANGES → fix round, or exit max-iterations if 3 fix rounds are spent.
  • APPROVE from a full review → exit clean.
  • APPROVE from a delta review → exit clean only when all of these hold:

    • the last full review was not partial;
    • every file in git diff --name-only <last full target_sha>..HEAD is in that full review's coverage;
    • 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 (no delta). Its APPROVE → clean. Its findings → a fix round, or max-iterations after round 3.

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-converging with 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=0 or N=1: no rewrite.
  • N>1: confirm you are still on the branch the loop started on and that git merge-base --is-ancestor "$LOOP_BASE" HEAD succeeds; if either check fails, stop and report instead of resetting. Otherwise git reset --soft "$LOOP_BASE" and create one commit using the repo's convention (fallback fix: 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.

Download now (ZIP)

  • Other versions48 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 48

    1. didi/mpx★ 4ksame name
    2. blockscout/frontend★ 310same name
    3. microsoft/bocpy★ 184same name
    4. 9thLevelSoftware/legion★ 76same name
    5. microsoft/Trieste★ 53same name
    6. timharris707/skills★ 43same name
    7. spxrogers/agentsync★ 35same name
    8. mathruffian-dot/claude-motion-explainer★ 30same name
    9. mthines/agent-skills★ 20same name
    10. 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.
    • Dragoon0xSkill

      motion-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

    • GoogleSkill

      to-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

    • GoogleSkill

      improve-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

    • NVIDIASkill

      research

      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

    • MicrosoftSkill

      diagnose

      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-groveSkill

      unslop

      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.

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.