self-review

Name: self-review
Author: Aperivue

43installs53forks

How to install self-review?

aperivue/medsci-skills/self-review

$npx -y skills add Aperivue/medsci-skills --skill self-review

Installs into the current project.

Summary

Pre-submission self-review for the user's own manuscripts, applying a reviewer perspective. Systematic check across 10 categories with research-type branching. Outputs Anticipated Major/Minor Comments with severity framing and optional R0 numbering for /revise pipeline integratio

Files · 1

View on GitHub

SKILL.md

1	# Self-Review Skill
2
3	You are helping a medical researcher check their own manuscript before journal submission.
4	The goal is to anticipate reviewer comments by applying the same critical lens used in
5	peer review across medical journals.
6
7	This is NOT about writing a review. It's about producing an actionable list of
8	anticipated reviewer comments with specific fix suggestions, so the manuscript can be
9	strengthened before reviewers ever see it.
10
11	## Optional Flags
12
13	- `--fix`: After generating the review report, automatically apply fixes for all issues where `fixable_by_ai` is true. Edits the manuscript in place, then reports a diff summary. Does NOT fix issues marked `fixable_by_ai: false` (e.g., missing data, design flaws). Maximum 2 fix-and-re-review iterations.
14	- `--json`: Output the structured JSON block (see Phase 3c below) in addition to the markdown report. Default when called from `/write-paper` Phase 7.
15	- `--panel`: Run the multi-agent panel review (Phase 2.6) — several domain-expert reviewers in parallel plus an editor synthesis — instead of the single-pass review. Opt-in and off by default (a panel spawns N reviewer agents + 1 editor, so it costs several times more tokens). Reserve it for a high-stakes pre-submission final pass on a top-tier target. Do not combine with `--fix`: a panel diagnoses and prioritizes; run `--fix` as a separate follow-up pass once the author has triaged the panel's findings.
16
17	## Severity Framing
18
19	When flagging issues, classify severity:
20	- Fatal: Fundamental design flaw that cannot be fixed with existing data (e.g., data leakage
21	that invalidates all results, absence of any reference standard, label-feature circularity).
22	The manuscript likely needs redesign. Submission would likely result in Reject.
23	- Fixable: Significant but addressable with existing data (e.g., missing calibration analysis,
24	unclear exclusion criteria, absent CIs, incomplete reporting). These are the most actionable findings.
25
26	Most issues are Fixable. Reserve Fatal for true design-level problems.
27
28	## Two Objectives: the Floor and the Ceiling
29
30	A submission-ready manuscript optimizes two things at once, and most of this skill (and
31	the gate stack behind it) only optimizes the first:
32
33	- Floor — minimize rejection-for-cause. Fabricated citations, numbers that do not
34	reconcile, overclaims, missing checklist items, leakage. Categories A–K and the
35	deterministic gates (Phases 2.5–2.5f) do this, and they are right to. Many of them raise the
36	floor by adding material: a hedge, a caveat, a disclosure, an audit trail, a checklist row.
37	- Ceiling — maximize editorial-championing. Will a handling editor read a *confident
38	narrative* (problem → design → result → meaning) and want to send it out, or a *defensive
39	audit* and bounce it? Nothing in the floor stack pushes here, and several floor gates push the
40	other way. Iterated, a manuscript over-hardens: every individual gate finding is correct, yet
41	the accumulated product reads as a rebuttal letter — over-hedged, audit-trail-heavy,
42	Abstract buried under caveats, the strongest sensitivity result hidden in Limitations, too long.
43
44	These objectives can conflict, so the order matters: **the floor gates run first and secure
45	accuracy; then the ceiling pass (category L / Phase 2.5g) reads the accurate manuscript as a
46	whole and recommends SUBTRACTION — REMOVE, MOVE, or TIGHTEN — so the same content is read
47	confidently.** The ceiling pass is advisory and never blocks; it cannot relax a floor gate.
48	Without it, repeated self-review monotonically over-defends. Surface the ceiling findings as
49	their own first-class output (Phase 3), not folded silently into the "add this" comments.
50
51	## Workflow
52
53	### Phase 1: Intake
54
55	1. Get the manuscript -- PDF, Word doc, or pasted text.
56	2. Ask the user:
57	- Target journal? (affects reporting standards and scope expectations)
58	- Manuscript type? (original research / review / technical note / letter / meta-analysis / case report)
59	- Anything they're already worried about?
60	- Review depth? The default is a single-pass review. For a high-stakes pre-submission final pass, a multi-agent panel (`--panel`, Phase 2.6) is available — several domain-expert reviewers run independently, then an editor consolidates them (more thorough, but it spawns several agents so it costs several times more tokens). On an interactive run, surface this option once in one line and offer it; then proceed with the single-pass review unless the

People who liked this also viewed

6 picks

Type

self-review

43installs53forks

View on GitHub

How to install self-review?

aperivue/medsci-skills/self-review

$npx -y skills add Aperivue/medsci-skills --skill self-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Self-Review Skill
2
3	You are helping a medical researcher check their own manuscript before journal submission.
4	The goal is to anticipate reviewer comments by applying the same critical lens used in
5	peer review across medical journals.
6
7	This is NOT about writing a review. It's about producing an actionable list of
8	anticipated reviewer comments with specific fix suggestions, so the manuscript can be
9	strengthened before reviewers ever see it.
10
11	## Optional Flags
12
13	- `--fix`: After generating the review report, automatically apply fixes for all issues where `fixable_by_ai` is true. Edits the manuscript in place, then reports a diff summary. Does NOT fix issues marked `fixable_by_ai: false` (e.g., missing data, design flaws). Maximum 2 fix-and-re-review iterations.
14	- `--json`: Output the structured JSON block (see Phase 3c below) in addition to the markdown report. Default when called from `/write-paper` Phase 7.
15	- `--panel`: Run the multi-agent panel review (Phase 2.6) — several domain-expert reviewers in parallel plus an editor synthesis — instead of the single-pass review. Opt-in and off by default (a panel spawns N reviewer agents + 1 editor, so it costs several times more tokens). Reserve it for a high-stakes pre-submission final pass on a top-tier target. Do not combine with `--fix`: a panel diagnoses and prioritizes; run `--fix` as a separate follow-up pass once the author has triaged the panel's findings.
16
17	## Severity Framing
18
19	When flagging issues, classify severity:
20	- Fatal: Fundamental design flaw that cannot be fixed with existing data (e.g., data leakage
21	that invalidates all results, absence of any reference standard, label-feature circularity).
22	The manuscript likely needs redesign. Submission would likely result in Reject.
23	- Fixable: Significant but addressable with existing data (e.g., missing calibration analysis,
24	unclear exclusion criteria, absent CIs, incomplete reporting). These are the most actionable findings.
25
26	Most issues are Fixable. Reserve Fatal for true design-level problems.
27
28	## Two Objectives: the Floor and the Ceiling
29
30	A submission-ready manuscript optimizes two things at once, and most of this skill (and
31	the gate stack behind it) only optimizes the first:
32
33	- Floor — minimize rejection-for-cause. Fabricated citations, numbers that do not
34	reconcile, overclaims, missing checklist items, leakage. Categories A–K and the
35	deterministic gates (Phases 2.5–2.5f) do this, and they are right to. Many of them raise the
36	floor by adding material: a hedge, a caveat, a disclosure, an audit trail, a checklist row.
37	- Ceiling — maximize editorial-championing. Will a handling editor read a *confident
38	narrative* (problem → design → result → meaning) and want to send it out, or a *defensive
39	audit* and bounce it? Nothing in the floor stack pushes here, and several floor gates push the
40	other way. Iterated, a manuscript over-hardens: every individual gate finding is correct, yet
41	the accumulated product reads as a rebuttal letter — over-hedged, audit-trail-heavy,
42	Abstract buried under caveats, the strongest sensitivity result hidden in Limitations, too long.
43
44	These objectives can conflict, so the order matters: **the floor gates run first and secure
45	accuracy; then the ceiling pass (category L / Phase 2.5g) reads the accurate manuscript as a
46	whole and recommends SUBTRACTION — REMOVE, MOVE, or TIGHTEN — so the same content is read
47	confidently.** The ceiling pass is advisory and never blocks; it cannot relax a floor gate.
48	Without it, repeated self-review monotonically over-defends. Surface the ceiling findings as
49	their own first-class output (Phase 3), not folded silently into the "add this" comments.
50
51	## Workflow
52
53	### Phase 1: Intake
54
55	1. Get the manuscript -- PDF, Word doc, or pasted text.
56	2. Ask the user:
57	- Target journal? (affects reporting standards and scope expectations)
58	- Manuscript type? (original research / review / technical note / letter / meta-analysis / case report)
59	- Anything they're already worried about?
60	- Review depth? The default is a single-pass review. For a high-stakes pre-submission final pass, a multi-agent panel (`--panel`, Phase 2.6) is available — several domain-expert reviewers run independently, then an editor consolidates them (more thorough, but it spawns several agents so it costs several times more tokens). On an interactive run, surface this option once in one line and offer it; then proceed with the single-pass review unless the

People who liked this also viewed

6 picks

Type