Ds Review

Review

Use this skill when the quest already has a substantial draft, paper, or paper-like report and now needs an independent, skeptical, evidence-grounded audit.

This is not the same as ordinary write. It is also not the same as rebuttal.

• write turns accepted evidence into a narrative.
• review audits that narrative like a harsh but constructive expert reviewer.
• rebuttal responds to concrete external reviewer pressure that already exists.

Interaction discipline

• Follow the shared interaction contract injected by the system prompt.
• For ordinary active work, prefer a concise progress update once work has crossed roughly 6 tool calls with a human-meaningful delta, and do not drift beyond roughly 12 tool calls or about 8 minutes without a user-visible update.
• When the review report, revision plan, or follow-up experiment TODO list becomes durable, send a richer artifact.interact(kind='milestone', reply_mode='threaded', ...) update that says what the main risks are, what should be fixed next, and whether the next route is writing, experiment, or claim downgrade.
• Hard execution rule: if this stage needs terminal work such as document builds, scripted checks, Git inspection, or file inspection, every such command must go through bash_exec.

Purpose

review is an auxiliary audit skill for paper-like deliverables.

It should convert “the draft feels almost done” into a durable, skeptical, technically grounded review workflow:

1. identify the core claims and likely rejection reasons
2. audit novelty, value, rigor, clarity, and evidence sufficiency
3. write a reliable review note, not vague prose
4. produce a concrete revision plan
5. produce a follow-up experiment TODO list only when the paper truly needs more evidence
6. route the next step cleanly to write, analysis-campaign, baseline, scout, or decision

Default review stance: independent audit before celebration. Do not treat “looks polished” as “is defensible”.

Use when

• a substantial paper/draft.md, report draft, or paper-like manuscript already exists
• the quest has enough evidence to support a real audit rather than just speculative comments
• the user asks for:
  • a harsh review
  • a reliable paper audit
  • revision advice before submission
  • a decision about whether more experiments are still needed
• the writing line feels close to done and you need a skeptical gate before stopping

Do not use when

• the quest still lacks a meaningful draft or report
• the task is ordinary drafting from evidence
• concrete external reviewer comments already exist and the real task is response / revision
  • in that case use rebuttal

Non-negotiable rules

• Review independently. Do not simply mirror previous self-review notes.
• Do not fabricate praise, flaws, citations, novelty overlaps, or fatal defects.
• Keep every serious criticism evidence-grounded.
• Do not recommend more experiments when the real problem is wording, positioning, or claim scope.
• Do not recommend rhetoric when the real problem is missing evidence.
• If novelty or positioning is uncertain, treat that as a literature-audit question first, not an automatic experiment request.
• If a claim is too broad for the evidence, prefer narrowing or downgrading the claim over defending it with style.
• If startup_contract.review_followup_policy is present, honor it:
  • audit_only
    • stop after durable review artifacts and a clear route recommendation
  • auto_execute_followups
    • do not stop at the audit if the next route is already clear; continue into the required experiments and manuscript deltas
  • user_gated_followups
    • finish the audit first, then package the next expensive follow-up step into one structured decision
• If startup_contract.manuscript_edit_mode = latex_required, treat the provided LaTeX tree or paper/latex/ as the writing surface when manuscript revision is needed.
• If LaTeX source is unavailable while latex_required is requested, do not pretend the manuscript was edited; produce LaTeX-ready replacement text and an explicit blocker note instead.
• Accept manuscript and review inputs from URLs, local file paths, local directories, or current-turn attachments; do not assume the draft is already perfectly normalized.

Primary inputs

Use, in roughly this order:

• the current paper or report draft
• the selected outline if one exists
• the claim-evidence map if one exists
• the six-field evaluation_summary blocks from recent main experiments and analysis slices
• recent main and analysis experiment results
• figures, tables, and captions
• current-turn attachments and user-provided local paths / directories / URLs for the manuscript bundle or review packet
• prior self-review or reviewer-first notes as low-trust auxiliary input
• nearby papers when novelty or comparison is unclear

If the draft/result state is still unclear, open intake-audit first before continuing the review workflow. Before proposing extra experiments, read those structured evaluation_summary blocks first so you do not request work that the recorded evidence already resolved. If the user provided draft files or manuscript bundles directly, first normalize them into durable quest-visible paths before planning experiments or section-level revisions.

Core outputs

The review pass should usually leave behind:

• paper/review/review.md
• paper/review/revision_log.md
• paper/review/experiment_todo.md
• paper/paper_experiment_matrix.md when more evidence is still needed
• paper/paper_experiment_matrix.json when more evidence is still needed

Use the templates in references/ when needed:

• review-report-template.md
• revision-log-template.md
• experiment-todo-template.md

Review dimensions

Audit at least these dimensions:

• research question and value
• novelty and positioning
• method-to-problem fit
• evidence sufficiency
• experimental validity and baseline comparability
• claim scope and over-claiming risk
• writing defensibility and logical flow
• figure / table usefulness
• submission readiness

Workflow

1. Plan the audit

Before writing the review itself, make the audit explicit.

Identify:

• 1 to 3 core claims such as C1, C2, C3
• the strongest current evidence
• the weakest current evidence
• the top 3 likely rejection reasons
• whether the likely next route is:
  • text revision
  • literature / novelty audit
  • baseline recovery
  • supplementary experiment
  • claim downgrade

2. Check novelty and positioning only when needed

If novelty, related-work coverage, or field positioning is unclear:

1. open scout
2. run a focused literature / comparison audit
3. record what is genuinely overlapping, what remains novel, and what is merely better positioned writing

Do not request new experiments just to answer a literature-positioning question.

3. Write a reliable review report

Write paper/review/review.md using references/review-report-template.md.

The review should be:

• independent
• skeptical but constructive
• technically specific
• reader-aware
• evidence-grounded

At minimum, the review report should cover:

• summary
• strengths
• weaknesses
• key issues
• actionable suggestions
• storyline / outline advice
• priority revision plan
• experiment inventory and research experiment plan
• novelty verification and related-work matrix
• references

If helpful, include an internal conservative overall judgment or score, but do not pretend numerical precision when evidence is still unstable.

4. Produce the revision log

Write paper/review/revision_log.md using references/revision-log-template.md.

For each serious issue, record:

• issue id
• why it matters
• what should change
• whether the fix is writing-only, evidence-only, or experiment-dependent
• whether the issue blocks finalize
• one copy-ready replacement sentence / paragraph when feasible
• one LaTeX-ready replacement block when startup_contract.manuscript_edit_mode = latex_required