/ds-review

name: ds-review
description: Use when a draft, paper, or paper-like report is substantial enough for an independent skeptical audit before finalization, rebuttal, or revision routing.
skill_role: companion
license: MIT
metadata:
  author: ResearAI/DeepScientist
  version: "1.0.0"

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-repo