From sjh-skills
Self-reviews paper paragraphs (intro, abstract, method, related work) across five axes: logic, expression, detail, framing, reader orientation. For v1→v2 revision, not drafting from scratch.
How this skill is triggered — by the user, by Claude, or both
Slash command
/sjh-skills:paper-self-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Mechanical v1 → v2 iteration for paper paragraphs. Core belief: every v1 is a mix of logic gaps, repetition, detail leakage, framing errors, and reader-orientation failures. This skill does not write the first draft — it makes the revision loop deterministic instead of vibe-driven.
Mechanical v1 → v2 iteration for paper paragraphs. Core belief: every v1 is a mix of logic gaps, repetition, detail leakage, framing errors, and reader-orientation failures. This skill does not write the first draft — it makes the revision loop deterministic instead of vibe-driven.
Theoretical anchors:
paper-self-review / "self-check this paragraph"Not used for: typo / grammar / LaTeX compilation issues.
Before writing the intro (not after) — required. If the user cannot state the paper's core contribution in one sentence, stop:
Write the contribution in ≤ 25 words. If you cannot, you have not yet thought it through clearly. Do not start writing the intro.
— SPJ: "If you cannot state your contribution in one sentence, you don't yet have a paper."
Save that sentence. Every paragraph that follows must trace back to it.
Run all five axes after each paragraph. If any axis fails, rewrite the paragraph — do not patch locally. The reason: paragraph-level problems almost always cascade across sentences; surgical edits leave the structure broken.
Rule: Before drafting, write down the paragraph's "single task" in one sentence. Then every sentence must follow directly from the previous one.
Anti-patterns (canonical v1 symptoms):
Self-check questions:
Rule: After drafting, condense the paragraph's claim to a 5-word phrase (e.g., "method M beats baseline B"). Then check repetition at two scopes:
If the user pasted only one paragraph in isolation, do the local check fully and flag global repetition as "needs full-intro context to verify" — do not invent or assume what other paragraphs say.
Self-check questions:
For stylized examples (an introduction that repeats one claim four times), see references/anti-patterns.md.
Rule: When the intro touches on the method, each comparison conveys only two things — what was asked / what number was obtained. Symbol definitions, narrow-design rationale, and theoretical interpretation defer to §3 / §5.
Hard constraint: in the intro, method word count ≤ results word count.
Self-check questions:
Variant-A, Method-M) at this point in the intro?For a stylized example (a "Testing the hypothesis" paragraph that turned into half a §3), see references/anti-patterns.md.
Rule: Every claim must be framed positively (what IS true, what we DO find), not negatively (what others fail to do, what is missing). Your hypothesis is YOUR proposal — do not dress it as obvious intuition.
Sub-rules:
Positive, not negative: "We show X works" is stronger than "Previous work fails to do X." Frame prior work's limitation as a contrast that motivates your contribution, not as a criticism that leaves a vacuum. Example: instead of "others only modify inference but not training," write "we integrate component C directly into the training loop."
Hypothesis ≠ intuition: Do not write "The intuition behind these findings is simple" when introducing YOUR hypothesis. That phrase implies the claim is already established. Instead, frame it as a hypothesis with a "when" trigger: "We hypothesize that when the model invokes the external module, it has already encoded the necessary information in its intermediate output." Let the experiments prove it; the intro proposes it.
No abbreviations at key points: The first mention of a concept in a section must use its full descriptive name — the abbreviation alone assumes reader context that does not exist. Section titles, hypothesis statements, and contribution bullets are "key points." (Good example: a section title "Lightweight Training Preserves Visual Reasoning" rather than "LT Preserves VR".)
Declarative, not interrogative: Contribution bullets and findings should be stated as claims, not questions. "Can small-scale training transfer?" → "Small-scale training transfers to large-scale models." Questions belong in the introduction's motivation paragraph (to open the niche), not in your findings or contribution list.
Qualitative scale in intro, quantitative in body: In intro/abstract, describe results at the level of "across scales / under different training regimes / on N benchmarks." Concrete numbers ("+3.2pp on Benchmark-X") belong in §4/§5 tables. The intro sells the shape of the result, not the decimal.
Self-check questions:
Rule: The audience does not share your internal project context. Each section must be self-contained relative to its own scope, and the narrative must actively guide the reader toward your experimental design before revealing it.
Sub-rules:
Section self-containment: Each section maps to one paper (your own P3). Do not require the reader to recall background from P1/P2 to follow the current section. If §3 explains your method, it must establish its own motivation locally — do not rely on "as discussed in §1" for critical setup. A section that cannot stand alone if you hide all other sections has a dependency problem.
Guide the reader to your experiment: The best paper makes the reader think "I would design a similar experiment" before you reveal yours. This means: lay out the phenomenon → state what is unknown → make the natural next question obvious → then present your design as the answer. If your experiment feels surprising to the reader, you have not guided them well enough.
Big picture always visible: Every paragraph should let the reader know where they are in the argument arc. When you drill into a detail, one sentence must connect it back to the section's claim. A paragraph that serves the big picture implicitly (you know why it's there, but the reader doesn't) has failed this test.
No private terminology: If a concept has a project-internal name, the paper must define it at first use with enough context that an outsider can reconstruct the meaning. Never assume the reader's mental model matches yours — they are building it from your words alone.
Self-check questions:
When the user pastes a paragraph:
Either ask the user, or extract it yourself: what is this paragraph's "single task"? If you cannot extract it cleanly, send the paragraph back: it is not yet thought through, and word-choice edits will not fix it.
Axis 1 → 2 → 3 → 4 → 5. Surface only the single most severe issue per axis. Listing ten nits is unactionable; the user cannot revise breadth-first.
Output template:
## Single task (extracted)
<one sentence>
## Axis 1 — Logic
<the most severe jump + which anchor sentence is missing>
## Axis 2 — Expression
<5-word claim + how many times it repeats + which to keep, which to cut>
## Axis 3 — Detail
<which symbol / rationale should defer to §X>
## Axis 4 — Framing
<negative framing / false intuition / abbreviation / question-as-claim identified>
## Axis 5 — Reader Orientation
<self-containment gap / missing guidance / big-picture disconnect>
## Suggested revision (≤ 3 sentences, direction only — do not rewrite)
<direction, not v2 prose>
The default mode is diagnosis only — name the issue, point at the v1 sentence, give a direction. This is what trains the user's self-review reflex; rewriting on every request short-circuits the learning loop and produces another v1 next time.
When to give a reference v2 (allowed, mark it explicitly):
In these cases, after the five-axis diagnosis, give one reference rewrite and tag it: "reference only — please verify against the five axes; the diagnosis above is the more important output."
Never generate a v1 from scratch — if the user has not written anything yet, return them to the pre-flight one-sentence claim test.
Avoid the "reviewer #2" tone of "this is unclear, please revise".
| Symptom | Axis | Fix |
|---|---|---|
| 4–5 jumps in one paragraph | 1 | Split into N paragraphs, one task each |
| First/Second/Third filler | 1 | Check if the three points are paraphrases; if so, merge |
| Topic sentence and closing don't align | 1 | Rewrite topic sentence, or cut the drifted middle |
| Same 5-word claim repeats ≥ 2 times | 2 | Keep the strongest occurrence; cut the rest |
| Hypothesis paragraph repeats across 4 sentences | 2 | Keep 1; defer the rest to §3 |
| Intro mentions an undefined method symbol | 3 | Replace with natural-language contrast ("with vs. without the proposed component") |
| Intro explains "why narrow / why this design" | 3 | Cut; defer to §3.X |
| Method word count > result word count | 3 | Cut method description; add result numbers |
| "Others fail to / lack / do not" framing | 4 | Flip to positive: what we contribute, not what's missing |
| "The intuition is simple / obvious" for your hypothesis | 4 | Reframe as "We hypothesize that…" with epistemic marker |
| Abbreviation in section title / contribution bullet | 4 | Spell out the full descriptive name |
| Findings phrased as questions | 4 | Flip to declarative claims |
| Exact numbers in intro | 4 | Replace with qualitative shape ("across N benchmarks") |
| Section requires reading §1 to make sense | 5 | Add local motivation; make self-contained |
| Experiment design feels surprising to reader | 5 | Add build-up paragraph that makes the design feel inevitable |
| Paragraph serves big picture only implicitly | 5 | Add one connecting sentence to the section's claim |
| Project-internal jargon without definition | 5 | Define at first use or replace with descriptive term |
For worked examples behind axes 1–3, see references/anti-patterns.md.
references/anti-patterns.md — stylized v1 paragraphs and their five-axis diagnosisAxes 1–3 distilled from repeated review comments by Yinghao Xu. Axes 4–5 distilled from paper revision feedback by Ceyuan Yang.
npx claudepluginhub jiahao-shao1/sjh-skills --plugin sjh-skillsCritiques and generates academic paragraphs from atomic sentences (claims with citations). Delivers three variants: Speculative, Safe, Assertive for revisions or new prose.
Systematic self-review checklist for academic papers covering structure, logic consistency, citations, claim auditing, figure/table quality, and writing clarity.
Academic writing multi-agent orchestrator. TRIGGER when: user is editing .tex files, reviewing thesis/paper chapters, drafting academic content, checking writing quality, or analyzing research positioning. Coordinates specialist agents in parallel for review, research, drafting, polishing, figure work, bibliography auditing, and literature surveys.