| name | strategic-revision |
| description | Use when you receive referee comments for a paper (R&R, revise-and-resubmit) and need a DAG-validated revision master plan — atomic task extraction, dependency mapping, computational critical-path analysis, execution blocks, venue strategy. Merges /parse-reviews ingestion with Sihvonen's strategic-revision architecture. |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash(mkdir*), Bash(cp*), Bash(ls*), Bash(latexmk*), Bash(python*), Bash(uv*), AskUserQuestion, Task |
| argument-hint | [path-to-reviews-pdf or no arguments for guided setup] |
Strategic Revision — From Referee PDF to DAG-Validated Master Plan
Read a referee comments PDF and produce:
- Standardised tracking files (per-reviewer markdown, LaTeX verbatim, comment tracker, review analysis)
- A computationally validated revision master plan (atomic tasks, DAG, execution blocks A-E, critical path, bottlenecks)
Provenance: DAG validation + critical-path architecture adapted from Jukka Sihvonen's strategic-revision skill (https://github.com/jusi-aalto/strategic-revision). the user's ingestion layer (correspondence scaffolding, LaTeX verbatim, R&R routing, venue strategy, coaching) retained.
When to Use
- Received reviewer reports for a paper (journal or conference)
- Starting an R&R cycle and need to set up tracking + plan revision strategy
- Want both structured referee artifacts AND a dependency-mapped action roadmap
When NOT to Use
- Writing the actual response letter (use generated response blocks as a starting point, then write manually)
- Reviewing someone else's paper (use
/proofread or peer-reviewer agent)
- Internal review synthesis only — use
/synthesise-reviews instead
Inputs
Gather via interview if not provided:
- Reviews PDF path — auto-discovered or user-provided (see below)
- Project path — root of the research project (auto-detect from cwd if possible)
- Venue slug — e.g.,
ejor, facct-2026, management-science
- Revision round — integer, default 1
- Response deadline — date if known, otherwise "TBD"
- Coordinating author — who is leading the response
PDF Auto-Discovery
Search for the reviews PDF in this order. Use the first match; if multiple PDFs found at a location, list them and ask the user to pick.
to-sort/*.pdf — most likely landing spot after downloadcorrespondence/referee-reviews/{venue}-round{n}/*.pdfcorrespondence/referee-reviews/*.pdf- Ask the user for the path if nothing found
Output Location
correspondence/referee-reviews/{venue}-round{n}/
├── {venue}-round{n}-reviews.pdf (copy of input PDF — source NEVER moved; taxonomy name per rules/submission-file-archive.md, 2026-07-03)
├── {venue}-round{n}-rebuttal.md (empty — for response draft)
├── reviews/ (individual reviewer files)
│ ├── reviewer-1.md
│ └── ...
├── analysis/
│ ├── comment-tracker.md (atomic comment matrix with R&R + 5-cat classification)
│ ├── review-analysis.md (strategic overview + venue strategy)
│ └── reviewer-comments-verbatim.tex (LaTeX transcription)
└── plan/
├── REVISION_MASTER_PLAN.md (six-phase Sihvonen plan — atomic tasks, DAG, blocks, risks)
├── revision_tasks.json (DAG input — see references/task-schema.md)
└── revision_dag_analysis.json (computational output — parallel batches, critical path, bottlenecks)
Source PDF preservation: The original PDF is only ever copied to {venue}-round{n}-reviews.pdf. Never move, rename, or delete the source.
Principle: correspondence/ holds exchanges with reviewers. Internal review work goes in docs/{venue}/internal-reviews/.
Submission-history stamp: ingesting a reviews PDF is a submission event — append a history: row (event: reviews-in, round: r{n}, files: pointing at {venue}-round{n}-reviews.pdf) to the paper's vault submission entry per rules/submission-file-archive.md § history. When the revision is later resubmitted, that resubmission appends its own response-sent + submitted rows (usually via /session-close sync).
No-overwrite rule: If outputs already exist, version them (comment-tracker-v2.md, REVISION_MASTER_PLAN-v2.md). Always flag before writing.
Protocol — 11 Phases
The skill runs 11 sequential phases. Detailed step-by-step procedure: references/phases.md.
| # | Phase | Output | Source |
|---|
| 1 | Setup | Scaffolded directories + copied PDF | FB |
| 2 | Read Reviews | Structured per-reviewer data in memory | FB |
| 3 | Individual Reviewer Files | reviews/reviewer-{N}.md | FB |
| 4 | LaTeX Verbatim Transcription | reviewer-comments-verbatim.tex (compiled) | FB |
| 5 | Atomic Parsing | Every distinct request as own SourceID (R1.a3, EiC.2b) | JS |
| 6 | Classification | 5-cat (STRUCTURAL/ARGUMENTATIVE/EMPIRICAL/CLARIFICATION/EDITORIAL) + R&R routing (NEW ANALYSIS / CLARIFICATION / DISAGREE / MINOR) | Both |
| 7 | Dependency Mapping (DAG) | Upstream Blockers + Collateral Risks tables → revision_tasks.json | JS |
| 8 | Structural DAG Validation | dag_validator.py --validate-only gate check | JS |
| 9 | Critical Path Sequencing | Execution Blocks A-E + GO/NO-GO gate after Block A | JS |
| 10 | Risk & Conflict Resolution + Coaching | Reviewer conflicts, process risks, interactive coaching (Major/Critical only) | Both |
| 11 | Computational Optimization + Review Analysis | Parallel batches, critical path, bottlenecks + venue strategy (CABS/CORE/SJR) | Both |
JS = Sihvonen phases. FB = the user phases. Both = merged.
Phase Dependencies
- Phases 1-4 (ingestion) must complete before Phase 5 begins
- Phase 8 is a hard gate: cycles → return to Phase 7, do not advance to Phase 9
- Phase 11 requires the Phase 9 block assignments before running full DAG analysis
- Phase 10 coaching runs only on Major/Critical comments (skip Minor/Editorial)
DAG Validation Quick Reference
Phase 8 (structural gate):
cd correspondence/referee-reviews/{venue}-round{n}/plan
python dag_validator.py revision_tasks.json --validate-only
Phase 11 (full analysis):
python dag_validator.py revision_tasks.json
Copy dag_validator.py from skills/strategic-revision/scripts/ into the plan directory before running. Requires networkx (uv pip install networkx if missing).
Full validator documentation: references/dag-validation.md.
Task JSON schema: references/task-schema.md.
R&R routing rules: references/rr-routing.md.
Classification: Two Axes
Every atomic task gets both classifications recorded in the comment tracker:
Category (5-cat, Sihvonen): structural intent of the change
- 🔴 STRUCTURAL — moves, cuts, reorganizations
- 🟠 ARGUMENTATIVE — theory, narrative, logical framing
- 🟡 EMPIRICAL — new regressions, data work, robustness
- 🟢 CLARIFICATION — definitions, justifications, explanations
- 🔵 EDITORIAL — formatting, typos, figures, terminology
R&R Routing (FB): workflow routing
- NEW ANALYSIS — needs code/data work
- CLARIFICATION — textual fix only
- DISAGREE — author push-back with rebuttal
- MINOR — trivial or editorial
The two axes are orthogonal: a STRUCTURAL task is usually a CLARIFICATION routing; an EMPIRICAL task is usually NEW ANALYSIS; ARGUMENTATIVE with DISAGREE signals a rebuttal-heavy revision.
Strategic Coaching (Phase 10)
For each Major or Critical comment, walk the user through:
- Understanding: reviewer's core concern — methodology, theory, or framing?
- Position: Agree / Partially agree / Disagree (with core rebuttal if Disagree)
- Risk: likelihood of reviewer escalation if pushed back on
- Response sketch: one-sentence strategy (not full response)
Record in the comment tracker with two new columns: Position + Strategy.
Rules:
- Only Major/Critical get coaching. Minor/Editorial auto-classify as Agree.
- the user can say "skip coaching" to auto-classify all remaining as Agree.
- Maximum 2 rounds of dialogue per comment.
- Do not write the actual response letter — that remains the user's job.
Venue Strategy (Phase 11)
Populate the Publication Strategy section of review-analysis.md:
- Strategy A (minimal revision): venues that would accept the paper as-is despite reviewer concerns
- Strategy B (substantial revision): equal-or-higher prestige venues worth targeting if authors invest in addressing major concerns
- Conferences: check CORE rankings via
.context/resources/venue-rankings.md (CSV: .context/resources/venue-rankings/core_2026.csv)
- Journals: check CABS AJG via
.context/resources/venue-rankings.md (CSV: .context/resources/venue-rankings/abs_ajg_2024.csv). For SJR, query Elsevier Serial Title API (SCOPUS_API_KEY required). Flag journals below CABS 3 only with strong rationale.
- Recommendation table: 3-5 venues ranked with rationale. First option should always be "revise for current venue" if acceptance probability >~30%.
- Key Decision: frame the core trade-off (speed vs. impact, minimal vs. substantial effort).
Critical Rules
- Verbatim means verbatim. Never paraphrase reviewer text in
reviewer-comments-verbatim.tex. Copy exactly.
- Every comment gets a SourceID. No reviewer concern is lost. If in doubt, give it its own ID.
- Atomic tasks only. If a paragraph contains 3 distinct requests, create 3 rows — never collapse.
- No invented requests. Every task traces to a verbatim quote.
- Don't overwrite. Version outputs if present.
- Compile the LaTeX.
reviewer-comments-verbatim.tex must build cleanly before Phase 5.
- Phase 8 is a hard gate. Cycles block Phase 9. Fix the DAG, re-run validation.
- Phase 11 is mandatory. Do not skip computational optimization — parallel batches and critical path override manual sequencing where they conflict.
- Don't write response letters. The skill produces plans and trackers; writing the rebuttal is the user's job. To inventory what actually changed between the submitted and revised manuscript as raw material for the rebuttal, run
/latex-diff (submitted revision vs working tree) — it reports the change list; it does not write the letter.
- GO/NO-GO gate after Block A. If empirical foundation changes key conclusions, escalate to authors before advancing.
Fold-in mode — second-review extension of an existing DAG
When a paper that already has a /strategic-revision package receives a second independent review (a new referee report, an AI self-review, a co-author critique, a conference discussant, a fresh paper-critic / referee2-reviewer pass), extend the existing DAG instead of starting over.
Trigger: "fold in this review", "process this second review", /strategic-revision --fold-in <path>, or recognising the situation from context (existing plan/revision_tasks*.json + new review file).
What it produces (preserving v1; never overwriting):
plan/revision_tasks-v{N}.json + plan/revision_dag_analysis-v{N}.json — incremented version- v{N} addendum appended to
plan/REVISION_MASTER_PLAN.md and analysis/comment-tracker.md (the same files, not new ones)
- A cross-review picture: where the reviews overlap, what each catches that the other misses, and whether either is a superset (usually neither is — the union is the real picture)
- New review gets its own
reviews/<source-N>.md and its own row in reviews/INDEX.md; v1's row is untouched
Why this matters: re-running the full skill loses the v1 verification trail (which findings were checked, which converted to DISAGREE, which got Coaching positions). Fold-in preserves that trail. The DAG itself is the durable artifact; reviews are inputs that grow it.
Full step-by-step (including the OVERLAP / MERGE / NEW disposition axis, versioning convention, and the cross-review picture template): references/fold-in-protocol.md.
Templates
Located in templates/referee-comments/:
comment-tracker.md — atomic matrix with R&R columnsreview-analysis.md — strategic overview templatereviewer-comments-verbatim.tex — LaTeX transcription template
Cross-References
/latex-diff — diff the submitted vs revised manuscript (git revision or backup vs working tree) to build the "summary of changes" and confirm every committed revision has a rebuttal line. Read-only; raw material for the letter, not the letter itself./proofread — proofread the response letter before submission/bib-validate — run after revision to check bibliography/pre-submission-report — full quality check before resubmissionpaper-critic agent — self-review of the revised paper/synthesise-reviews — merge internal review agent reports (different use case — not referee comments)references/phases.md — detailed 11-phase protocolreferences/rr-routing.md — R&R routing signal wordsreferences/dag-validation.md — DAG validator usage + Phase 6 detailsreferences/task-schema.md — revision_tasks.json JSON schemareferences/fold-in-protocol.md — second-review extension protocol (preserves v1 trail; appends v{N} addendums)scripts/dag_validator.py — NetworkX-based DAG validator (copy to plan dir before running)
