agentleFS
Sign inStart free
kenchriskenchris/review-loop/skills/triage/SKILL.md

triage

Skill4 starsChanged 17 days agoApache-2.0View on GitHub

Decide the review threads of a round without doing it one thread at a time. Reads every undecided thread (from Copilot, CI bots or people) against the code, proposes a verdict for each with the evidence, and records the ones you confirm in a single call. Use after `review-loop threads sync`, before `/retro`, when a round has more undecided threads than you want to decide by hand. Not for reviewing a change (use `pre-pr-review`), and not for working out why a review missed something (use `retro`, after the threads are decided).

189 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use writing-beats, setup-matt-pocock-skills and 10 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.
  • LesaniSkill

    writing-beats

    Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.

    Also in 66 projects that use this

  • GoogleSkill

    setup-matt-pocock-skills

    Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

    Also in 167 projects that use this

  • liufeng1976Skill

    setup-ts-deep-modules

    Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.

    Also in 42 projects that use this

  • SethGammonSkill

    ascii-diagram

    Generate perfectly aligned ASCII diagrams — architecture, flow, sequence, box-and-arrow. Uses a programmatic character-grid approach so alignment is guaranteed by math, not token prediction. Includes post-render verification.

    Also in 4 projects that use this

  • simo97Skill

    migrate-to-shoehorn

    Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

    Also in 68 projects that use this

  • LesaniSkill

    writing-shape

    Take a markdown file of raw material and shape it into an article through a conversational session — drafting candidate openings, growing the piece paragraph by paragraph, arguing about format (lists, tables, callouts, quotes) at each step. Use when the user has a pile of notes, fragments, or a rough draft and wants help turning it into something publishable.

    Also in 63 projects that use this

  • +1 more from Lesani
  • Other versions189 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 189

    1. mattpocock/skills★ 309ksame name
    2. withastro/astro★ 64ksame name
    3. vectorize-io/hindsight★ 60ksame name
    4. ogulcancelik/herdr★ 47ksame name
    5. herdrdev/herdr★ 47ksame name
    6. colinhacks/zod★ 44ksame name
    7. QuivrHQ/quivr★ 40ksame name
    8. The-Vibe-Company/quivr★ 40ksame name
    9. vercel-labs/add-skill★ 39ksame name
    10. vercel-labs/skills★ 39ksame name

    179 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 repository3 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 0 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 176 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read the code the reviewer saw: git show <commit_reviewed>:<path> around the line.

    line 19
  2. Very specific:

    Verify, do not trust: an outside comment is cheap and sometimes wrong, and so is a proposal.

    line 23
  3. Very specific:

    Do not propose fixed without a commit you have read.

    line 35
  4. Very specific:

    Do not edit code in this skill.

    line 36
  5. Very specific:

    Write the confirmed decisions to a temporary file, one per line, fields separated by a tab: the id (a piece of it is enough), the verdict, …

    line 53

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

Triage

A verdict is the owner's decision about one outside thread: fixed, wrong, already reported, real but not now. The ledger needs one for every thread before /retro can learn from the round, and deciding forty of them by hand is the part people skip. This skill does the reading and proposes; you confirm once; it records. Nothing is recorded that you did not confirm, and nothing is posted to GitHub.

You can start it, and so can the agent that fixed the round (it has read the code and the threads anyway). Either way it writes decisions to the ledger only after the owner has confirmed them in step 3: an agent never confirms for the owner.

1. Gather

  • review-loop threads worksheet lists what is undecided (and what was marked missed), each with the nearest entry of your own review report as a hint. If the ledger is empty or old, ask for the repository (owner/name) and run review-loop threads sync --repo owner/name first. Do not guess a repository.
  • With PR numbers as the argument, keep only those pull requests (review-loop threads list --verdict new --pr <n>).
  • For each thread read the whole thread, not the first line: the ledger ($THREADS_LEDGER, or reviews/threads-ledger.json in $REVIEWS_DIR) holds every comment. A later comment in the thread often says the author already answered.
  • Read the code the reviewer saw: git show <commit_reviewed>:<path> around the line. Then the code now, and what happened in between: git log --oneline <commit_reviewed>..HEAD -- <path> and the diff of any commit that touched that spot.

2. Decide a proposal for each thread

Verify, do not trust: an outside comment is cheap and sometimes wrong, and so is a proposal. Write the concrete reason ("top_k: 1.5 passes the check and reaches the sampler as 1") and confirm it in the code. Then take the first line that fits:

ProposalWhenWhat you attach
fixedthe comment is right, and a commit after commit_reviewed changed that spot to address itthe sha, after reading its diff
caughtthe comment is right, and an entry of the self-review report describes the same defectthe report and entry (nearness alone is not enough: read it)
missedthe comment is right, the self-review did not report it, and it is not fixed yetwhat it would take to fix
rejectedthe comment is wrong or does not applythe reason, from the code: what it does that makes the comment wrong
deferredreal, and the owner or the PR text says not nowthe quote, or leave it to the owner to say
left newyou could not confirm it either waywhat you would need to know
  • A comment from a person (not a bot) usually carries a design point. Propose a verdict if the code settles it, but mark it as a judgement for the owner, never as obvious.
  • Do not propose fixed without a commit you have read. Do not propose rejected without a reason a person can check.
  • Do not edit code in this skill. A real comment that is not fixed yet is missed, or left undecided, with what it would take.

3. Propose, once

Show one table, grouped by proposal, most important first:

id        where                    who        comment (short)                       proposal   evidence
a1b2c3d   js/secretCode.js:196     copilot    listener never removed                rejected   added once in init, page lives as long as the game

Under it: counts per proposal, the threads left undecided and why, and the list of human comments marked for the owner's judgement. Then ask once: apply all of it, or which ids to change or skip. Say exactly what you will run. "Apply all" is a valid confirmation, and so is a list of corrections.

For more than about 25 threads, read them in shares (by pull request or by file), up to three read-only readers, one share each. Say how many readers and which model before launching, as in pre-pr-review multipass. Check the proposals yourself before showing them.

4. Record

Write the confirmed decisions to a temporary file, one per line, fields separated by a tab: the id (a piece of it is enough), the verdict, the fixing commit or -, the note or -.

a1b2c3d	rejected	-	added once in init, the page lives as long as the game
e4f5a6b	fixed	9c8d7e6	range check added in 9c8d7e6

Then one call:

review-loop threads verdict --batch <file>

It checks every line first and records nothing if one line is wrong (an id that matches no thread or two, an unknown verdict), so a typo cannot leave a half-decided round.

5. Finish

Report how many were recorded and how many are still undecided. When none are left, suggest /retro round <name>. Optionally review-loop threads cases --evals evals --repo-dir . --tag turns the fixed ones into eval cases.

Rules

  • A verdict is the owner's decision. Never record one that was not confirmed.
  • A wrong comment is recorded as rejected with its reason: the reason is what keeps it out of the eval and stops it being fixed twice.
  • "Could not confirm" is an answer. Leave the thread undecided rather than guess.
  • Post nothing to GitHub, resolve no thread, change no code.

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