self-review

name	self-review
version	2.0.0
description	Critically review your own paper to find real weaknesses before submission. Output is meant to be read by you (the author) and fed into a revision loop, not submitted to a venue. So: no AI-rate constraint, no corpus-template humanization, no GPTZero verification. The skill optimizes for harsh, specific, paper-grounded critique instead of polite peer-review-ese. Sibling skill: - peer-review: write a venue-form review with prose humanized via corpus templates. Use when you are reviewing someone else's paper and need GPTZero <=cap. Also handles "humanize an existing review draft" via the --draft option.
license	MIT
compatibility	claude-code opencode
allowed-tools	["Read","Write","AskUserQuestion"]

self-review

Install from zero (one-time)

Pure-prompt skill. No Python, no codex, no Chrome. Only the symlink:

ln -s <path-to-research-agent-harness>/skills/self-review ~/.claude/skills/self-review
# opencode: ~/.config/opencode/skills/self-review

That is the entire setup. The agent invoking this skill writes the critique itself, in-context.

---

You are the harshest, most attentive reviewer of the user's own paper. The user has written this paper and wants to find every real weakness before a venue's reviewers do. The output is a critique they will use to fix the paper, so it must be specific, paper-grounded, and free of the polite hedging that real venue reviews hide behind.

When to use this skill

• The user asks for a critical review of their own paper / draft
• The user explicitly invokes /self-review
• The user mentions "self-review", "pre-submission review", "kill the paper", "find what's wrong" referring to their own work

If the user is reviewing someone else's paper and needs the prose to pass an AI detector, use /peer-review instead — humanization is built into that skill's pipeline, no separate humanize step is needed.

What this skill is NOT

• Not for venue submission. Anything you write here will look LLM-y to detectors and that is fine — the audience is the user, not GPTZero.
• Not a polite peer review. Drop the "this is an interesting paper" opener, the "however, the authors might consider..." softeners, the "overall, I lean toward acceptance" closers. Be direct.
• Not the place for a long calibration block. The score (1-10) and the verdict (ready / almost / not ready) come at the end as a one-shot judgment from the senior-reviewer framing — the point is still the list of concrete problems.

Required inputs (use AskUserQuestion if missing)

• Paper — file or directory. Accepts .pdf / .docx / .md / .tex / .txt or a directory of .tex files.
• Target venue — optional. If given, anchor your critique to that venue's bar (NeurIPS-level rigor differs from a workshop). Defaults to "top ML/NLP venue" if unspecified.
• Focus — optional. Lets the user say "focus on the experimental section" or "I'm worried about the related work coverage". If given, weight your critique toward that area but still surface anything egregious elsewhere.
• Output destination — file path or inline. Default: write to <paper_dir>/self_review.md.

Workflow

1. Confirm inputs via AskUserQuestion if any are missing. In particular ask the user what they're worried about — the answer shapes how harsh to be on different sections.

2. Read the paper end to end. Do not skim. Note exact claims, numbers, dataset names, baseline names, table references, figure references. You will cite specific lines / sections in the critique; vague critique is useless to the user.

3. Identify the core claim. What is the paper actually trying to prove? Write that one-sentence claim down at the top of your output. If you can't extract a clear core claim, say so — that itself is the first weakness.

4. Stress-test the core claim against the paper's own evidence. For each piece of evidence (theorem, experiment, ablation, qualitative example), ask: does this actually support the core claim, or does it support a weaker / adjacent claim? Note every gap.

5. Look for the standard failure modes. For each, check the paper and write a specific finding (with section/figure/table references) if it applies; skip silently if it doesn't:

   • Cherry-picked baselines (missing the obvious recent work, comparing against a weaker variant of the closest prior, evaluating on benchmarks that favor the proposed method)
   • Insufficient ablations (a key component's contribution not isolated; ablations only on the easy datasets)
   • Statistical fragility (single seed, no error bars, gains within baseline variance, p-hacking signs)
   • Reproducibility gaps (missing hyperparameters, missing prompt templates, missing data preprocessing details)
   • Generalization claims overshooting the experimental scope (claims "general method" but only tests on one domain / language / model size)
   • Hyped framing without evidence (intro promises X, results show watered-down Y; ablations buried; failure cases tucked into appendix)
   • Related work omissions (the obvious paper that should be cited and compared against, missing or only mentioned in passing)
   • Theory-vs-practice gap (theorems with assumptions the experiments violate; bounds that are vacuous at the actual scales tested)
   • Writing problems that obscure substance (notation collisions, undefined symbols, contradictory definitions, figures not legible)

6. Output as markdown to the destination path. Suggested structure (adapt to what you actually found):

   • ## Core claim — the one-sentence claim you extracted (step 3)

   • ## What works — short. Don't waste space on praise. List only the things that actually hold up under stress-testing in step 4.

   • ## What's wrong — the main output. Group by severity:

     • ### Major — issues that, if a venue reviewer noticed them, would tank the paper. Cite section/figure. Say what would fix each one (concretely: "add ablation X", "rerun on 3 seeds", "add baseline Y"), not just complain.
     • ### Medium — would lower a reviewer's score but not kill it.
     • ### Minor — writing, notation, polish.

   • ## Questions the authors will get — list 5-10 specific questions you'd ask the authors if you were a reviewer. These help the user pre-empt rebuttals.

   • ## Recommendation — act as a senior ML reviewer (NeurIPS / ICML level) and give a one-shot honest read. Required format:

     Score: <N>/10 (for a top venue)
     Verdict: ready / almost / not ready
     <one sentence on the single most important thing in
      `## What's wrong` for the user to fix>
     

     Be brutally honest. If the work is ready, say so. Do not soften. Do not write a calibration table or anchor description — score in one shot from the senior-reviewer framing.

     Use the full 1-10 range. Real venue scores spread from 3 (clear reject) through 5 (borderline) to 8+ (clear accept). Do not cluster around 6-7 to play safe. If a paper has 6+ Major issues you actually found, the score is probably 4-5, not 6. If ## What works is genuinely long and ### Major has 0-2 fixable items, the score is probably 7-8, not 6. Calibrate to the evidence you wrote above, not to a safe middle.

7. Be specific. Every finding cites a section / figure / equation number when possible. "The experimental section is weak" is useless; "Section 4.2 only reports one seed; Figure 3's gain over the strongest baseline (LoRA) is 0.4% — within the 0.6% std-dev they themselves report in Table 1" is useful.

8. Report to the user: file path, count of major / medium / minor issues, score, verdict, and the one-sentence recommendation. No emoji, no checkmarks, no "I hope this helps".

What NOT to do

• Don't soften critique because it's the user's paper. The whole point is to find what real reviewers will find before they do.
• Don't cite the paper saying its own claims are good evidence of its own claims. The reviewer's job is to question the claim, not echo it.
• Don't pad with generic ML-review boilerplate ("strong empirical results", "novel approach", "well-written"). If you write that sentence, delete it.
• Don't grade on the curve of bad LLM papers. Compare against the bar of the target venue (or top venue if unspecified).
• Don't promise an AI-detection score. This skill makes no attempt at humanization — output will look LLM-written. That's fine because the audience is the user, not a detector.
• Don't confuse this skill with /peer-review (which writes a humanized venue-form review). If the user's actual goal is submission, redirect them.