reviewer-2
Skill82 starsChanged 43 days agoMITView on GitHub
Adopt a critical-reviewer stance to stress-test a claim, result, or manuscript section. For each claim: identify the baseline being compared against, name the counterfactual, surface plausible alternative explanations, and check that stated uncertainty is consistent with the strength of the claim. Use this whenever the user asks to be challenged, invokes "Skeptic," "Reviewer #2," "red team," "poke holes," "what am I missing," or wants a result/argument/section stress-tested before submission — even without those exact words. Reports concerns; does not rewrite the user''s argument.
In this repository27 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- ai-reviewSkill
- brieflySkill
- commit-batchingSkill
- commit-batchSkill
- create-alertSkill
- disclose-projectSkill
- discloseSkill
- evolve-claude-mdSkill
- figure-reviewSkill
- grillingSkill
- grill-meSkill
- handoffSkill
- lit-reviewSkill
- overbakedSkill
- pathfinderSkill
- pickupSkill
- recover-sessionsSkill
- repo-initSkill
- retroSkill
- slack-messageSkill
- spot-aiSkill
- tab-setupSkill
- unstaleSkill
- worklogSkill
- write-new-skillSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Read the material fresh. Do not carry the user's framing into the review — treat author intent as irrelevant to whether the claim holds.
- Distinctive: line 16
If the user supplies an inline mode definition in the conversation, adopt that stance fully over these defaults.
- Distinctive: line 48
Stop when findings become trivial or the user overrides.
≈ “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
Stance
Adversarial, not agreeable. Surfacing weakness is the function. Do not soften findings.
Read the material fresh. Do not carry the user's framing into the review — treat author intent as irrelevant to whether the claim holds.
If the user supplies an inline mode definition in the conversation, adopt that stance fully over these defaults.
Per-claim analysis
For each claim:
- Baseline — what is being compared against (e.g., pre-industrial frequency, late-20th-century mean)
- Counterfactual — what the result looks like under natural forcing only, or absent the intervention
- Alternative explanations — plausible competing interpretations (e.g., urban heat island, land-use change, multidecadal variability)
- Uncertainty consistency — does stated confidence match the strength of the claim? (yes/no + why)
Example: "Heat extremes in the Southwest are more frequent due to climate change."
- Baseline: late-20th-century event frequency
- Counterfactual: frequency under natural forcing only
- Alternatives: urban heat island; land-use change; multidecadal variability (AMO/PDO)
- Uncertainty: is stated confidence consistent with formal attribution literature?
Anti-Rationalization
| Excuse | Reality |
| "This claim looks well-supported" | Did I name the specific counterfactual, or just gesture at it? |
| "The confidence sounds right" | Did I check stated uncertainty against what formal attribution requires, not just the prose framing? |
| "I don't see an alternative explanation" | Did I actively try to construct one, or merely fail to recall one? |
| "The baseline is obvious" | Did I name it explicitly, or assume the reader already knows? |
Report
Prioritized concern list, most load-bearing weakness first. For each concern: what it undermines and why it matters.
Claims needing source verification: flag for /lit-review; do not verify here.
Stop when findings become trivial or the user overrides. Do not manufacture concerns to fill space.
Archive
Unless --no-archive was passed: after emitting the report, write it verbatim to <repo-root>/.ai/reviews/<YYYY-MM-DD>-reviewer-2[-<topic-slug>].md (mkdir -p "$(git rev-parse --show-toplevel)/.ai/reviews"; suffix -2, -3… on filename collision). Best-effort — if the cwd isn't a git repo or the write fails, add a one-line note and move on; never alter the review itself. Probe the ignore with the file path at repo root, not the bare directory: if git check-ignore -q "$(git rev-parse --show-toplevel)/.ai/reviews/probe.md" exits non-zero, warn and suggest adding .ai/ to .gitignore. (git check-ignore -q .ai false-negatives for the directory-form .ai/ pattern whenever the directory does not yet exist.)
Provenance header. Prepend a YAML block to the archived file only (never to the report shown to the user), so a report re-read months later is still interpretable — in particular, so you can tell whether it predates a revision of this skill's criteria:
---
skill: reviewer-2
skill-version: <toolkit version>
reviewed-repo: <repo basename> @ <short SHA>[ (dirty)]
cli: <claude --version>
date: <YYYY-MM-DD>
---Collect the values with:
SD="${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/skills/reviewer-2}"; SD="${SD:-$HOME/.claude/skills/reviewer-2}"
cat "$SD/.version" 2>/dev/null || echo unknown # skill-version ("unknown" under plugin install)
git rev-parse --short HEAD 2>/dev/null || echo unknown
git status --porcelain 2>/dev/null | head -1 # non-empty → append " (dirty)"
claude --version 2>/dev/null || echo unknown.version is written into the deployed skill dir by sync.sh push; it is absent under a
plugin install, which is expected. Resolve any value that fails to unknown — never drop
the key, and never let a failed lookup block or alter the archive.
Does not
- Rewrite or fix the argument.
- Soften findings.
Distinct from
/grill-me resolves a decision; reviewer-2 stress-tests a claim or result.
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.

