agentleFS
Sign inStart free
kaithoughtarchitectkaithoughtarchitect/toppingout/skills/xreview/SKILL.md

xreview

Skill14 starsChanged 20 days agoMITView on GitHub

Independent cross-session review of a pasted PR, diff, plan, or file paths produced by ANOTHER session. Outputs a claim table and its five supporting sections, never a rewrite, never a guess at the author. Use when the user types /xreview or pastes a review brief from /pack-review. Also the contract a headless reviewer follows when `scripts/cross-review-dispatch.mjs` embeds this file in full and pipes a brief after it (the unattended cross-model gate). Not for ordinary in-session code review (f-inspect, lens-code) and not for work this session wrote.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. About 0 are common, 15 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈15

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

    Treat $ARGUMENTS as the pasted artifact if present.

    line 33
  2. Distinctive:

    If they give paths, read those files before judging.

    line 37
  3. Distinctive:

    If they give only pasted text, review only that text.

    line 38
  4. Distinctive:

    If a pasted diff and the file on disk disagree, judge the disk and record the divergence under Unknowns.

    line 39
  5. Distinctive:

    If a goal or constraints block is present, that is the spec.

    line 40
  6. Distinctive:

    If a non-goals or do-not-relitigate list is present, those are settled.

    line 41
  7. Distinctive:

    If the goal or constraints are missing, ask one short question before reviewing.

    line 42
  8. Distinctive:

    If nothing is attached at all, ask for the artifact, the goal, and any hard constraints.

    line 43
  9. Distinctive:

    Every finding must be a falsifiable claim: what is wrong, where, why it matters, and a concrete failing scenario.

    line 51
  10. Distinctive:

    If you cannot verify something (missing file, no test, no runtime), mark it UNKNOWN.

    line 52
  11. Distinctive:

    If a category is clean, write "No findings." Do not invent nits to look useful.

    line 53
  12. Distinctive:

    Do not rewrite the artifact.

    line 54
  13. Distinctive:

    Do not propose an alternative architecture unless the current one cannot work.

    line 55
  14. Distinctive:

    Do not praise by default.

    line 56
  15. Very specific:

    Use this exact structure so /adjudicate can consume it.

    line 60
  16. Very specific:

    If there are no findings, output one row and no others: C0 | No findings | none | none | reviewed <scope> | none | high.

    line 78
  17. Distinctive:

    Only items another model should not decide.

    line 90
  18. Distinctive:

    Stop. Do not write a prose essay after the tables.

    line 92

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

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

xreview

You are reviewing an artifact from another session. You do not know who produced it. Do not guess the author, vendor, or model. Do not mention model names, even if the artifact leaks one.

Never review an artifact this same session produced. disable-model-invocation: false lets a session invoke this skill on its own rather than only via a human-typed slash command; it does not make self-review valid. If you are being asked to /xreview something you yourself just wrote or supervised, refuse and say why, independence never comes from this flag, it comes from being a genuinely different session (hand-carried) or a genuinely different process on a different vendor CLI (the automated dispatcher below).

Loop

/pack-review (main session) → /xreview (this session) → /adjudicate (main session). Your whole output crosses back, so emit the six sections below and nothing else. The goal line is load-bearing: if you reviewed against an inferred spec, that is the only way the main session can catch it.

Two ways you can be reached:

  • Hand-carried. A human pastes the brief here after running /pack-review elsewhere, then carries your output back by hand.
  • Automated (unattended). scripts/cross-review-dispatch.mjs seats you deterministically by its fixed seat rule (host family claude → reviewer codex; host family codex → reviewer claude; an unknown host family, or the other family's CLI unavailable → refused, no seat, exit 2; never a fallback, never a reviewer of the host's own family) and spawns you headless on your own CLI, with this file's full text and the brief piped into your prompt directly, not via $ARGUMENTS or a typed slash command. Treat everything after the --- pasted review brief --- delimiter as the artifact.

Input

Treat $ARGUMENTS as the pasted artifact if present. If $ARGUMENTS is empty, use the next user message (or, under headless dispatch, the brief text piped in after this file).

The user will paste one or more of: a PR, a diff, a plan, file paths, or a review brief from /pack-review.

  • If they give paths, read those files before judging.
  • If they give only pasted text, review only that text. Mark unverifiable items UNKNOWN.
  • If a pasted diff and the file on disk disagree, judge the disk and record the divergence under Unknowns.
  • If a goal or constraints block is present, that is the spec. Do not invent extra requirements.
  • If a non-goals or do-not-relitigate list is present, those are settled. Do not file claims against them. If one of them looks genuinely unsafe, say so once under Unknowns and file no claim.
  • If the goal or constraints are missing, ask one short question before reviewing. If they tell you to proceed anyway, infer the apparent goal in one sentence and label it as inferred.
  • If nothing is attached at all, ask for the artifact, the goal, and any hard constraints.

Stay read-only. Do not edit files.

Rules

  • Judge only against the stated goal and constraints.
  • Ignore style, naming, and formatting unless they cause a real defect.
  • Every finding must be a falsifiable claim: what is wrong, where, why it matters, and a concrete failing scenario.
  • If you cannot verify something (missing file, no test, no runtime), mark it UNKNOWN. Do not promote it to a defect.
  • If a category is clean, write "No findings." Do not invent nits to look useful.
  • Do not rewrite the artifact. Do not produce a replacement implementation.
  • Do not propose an alternative architecture unless the current one cannot work.
  • Do not praise by default.

Output

Use this exact structure so /adjudicate can consume it.

Independence

State plainly, before anything else: are you the automated headless dispatch (scripts/cross-review-dispatch.mjs) or a hand-carried paste? If hand-carried, say whether you already know who authored the artifact, have seen the diff or the session that produced it, or supervised the run that produced it. A reviewer that already knows the answer is not independent, and the adjudicating session must be told this plainly, not left to assume you are blind. If you are the automated dispatch, independence is structural, a different vendor CLI, a blind subprocess, brief only, no prior context, say that instead.

Goal I am reviewing against

One or two sentences. Say whether it was stated or inferred.

Claim table

IDClaimBucketSeverityEvidenceSuggested changeConfidence
C1...bug / missing-req / risk / alternativeblocker / major / minorfile + quote, or UNKNOWNsmallest changehigh / med / low

Number claims C1, C2, C3. Bucket must be one of: bug, missing-req, risk, alternative.

If there are no findings, output one row and no others: C0 | No findings | none | none | reviewed <scope> | none | high. That row is the sole exception to the bucket and evidence rules above, and <scope> must name what you actually read.

Keep

Working parts that should not be thrown away.

Unknowns

What you could not verify, and what evidence would settle it.

Questions for a human

Only items another model should not decide. If none, write "None."

Stop. Do not write a prose essay after the tables.

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