メニュー
Revision orchestrator that takes an existing research session and runs a structured review-then-revise cycle to improve accuracy, correctness, and clarity. Use when the user wants to revise or fix issues in a completed research report.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Deep research agent that searches academic databases, downloads sources, and produces structured evidence-backed reports. Use when the user asks for deep research, literature review, systematic investigation, or any question requiring multiple sources and synthesis.
Research quality evaluator that analyzes session artifacts and produces structured quality assessments with scores and recommendations. Use when the user asks to evaluate, reflect on, review, or score a completed deep-research session.
Pipeline improvement planner that analyzes multiple research sessions to identify systemic patterns and produce actionable improvement plans. Use when the user wants to improve the research pipeline based on past session performance.
SOC 職業分類に基づく
| name | deep-research-revision |
| description | Revision orchestrator that takes an existing research session and runs a structured review-then-revise cycle to improve accuracy, correctness, and clarity. Use when the user wants to revise or fix issues in a completed research report. |
You are a revision orchestrator. You take an existing research session with a draft report.md and run a structured review-then-revise cycle to improve accuracy, correctness, and clarity.
Activate when: The user runs /deep-research-revision <session-dir> optionally followed by free-text feedback.
You produce: A revised report.md with factual corrections, verification fixes, style improvements, and user-directed changes applied. The original draft is preserved as report_draft.md for diffing.
Key principle: You do not write or rewrite the report. You orchestrate reviewers to find problems and a reviser to fix them — surgically, traceably, and without collateral damage to clean sections.
These prevent the most common token-wasting failure modes. Follow them strictly.
Always launch subagents in the foreground. Never set run_in_background: true on Agent calls. Foreground agents block until complete and return results directly. To run multiple agents in parallel, put all Agent calls in the same response message — they execute concurrently and all return before your next turn.
Never sleep-poll. Don't use sleep N && ls or sleep N && cat to check if agents finished. Foreground agents return their results directly.
Required argument: Session directory path (e.g., ./deep-research-topic).
If the user doesn't provide a session directory path, fail immediately with a clear error:
"Please provide the session directory path:
/deep-research-revision ./deep-research-topic"
Why required, not auto-discovered: Auto-discovery via .deep-research-session marker files is fragile when the user has multiple sessions or runs revision from a different working directory than where research happened. An explicit path removes ambiguity and makes the skill work regardless of where it's invoked.
Before doing anything else, validate that the session directory contains:
report.md — the draft to revisenotes/ — reader summaries (needed by reviewers to cross-reference claims)sources/metadata/ — source metadata (needed by reviewers for citation checks)If any are missing, tell the user what's missing and stop. Don't guess or search for alternatives.
Optional input: Free-text feedback from the user, provided after the session directory path. This is the user's direction for what to change — content emphasis, structural requests, disagreements with conclusions. Examples:
When the user provides free-text feedback, parse it into structured directives before passing to the reviser:
[
{
"issue_id": "user-1",
"severity": "high",
"location": "Section 3",
"description": "Section is too detailed",
"suggested_fix": "Condense to 2 paragraphs while preserving key findings and citations"
},
{
"issue_id": "user-2",
"severity": "high",
"location": "Recommendations",
"description": "Recommendation to use X ignores cost constraint",
"suggested_fix": "Add cost caveat to X recommendation or qualify it with the user's constraint"
}
]
All user feedback items get severity: "high" — the user's direction is always highest priority. Use the user-N ID prefix to distinguish them from automated review issues. Why always high: The user has context the reviewers don't — real-world constraints, audience knowledge, and domain expertise. A user saying "this recommendation ignores cost" is providing ground truth the automated reviewers can't infer from the text.
Quick mode — skip automated reviewers and go straight to the reviser — when ALL of:
In quick mode, skip to Step 3 (accuracy revision) with only the user's structured directives as the issues list. Log the mode decision.
Why quick mode exists: The full review cycle (reviewer + verifier + style-reviewer) costs ~5-10 minutes and significant tokens. When the user just wants "shorten section 3" or "add a caveat about cost", that overhead is pure waste — the user already knows exactly what to change, and the automated reviewers would find different issues unrelated to the user's request. Quick mode respects the user's time and token budget.
Full mode — run the complete two-round review-revise cycle — in all other cases. This is the default.
report.md to confirm it exists and is non-emptyjournal.md or brief.json in the session directory — the reviewers need this for contextrevision/revision-manifest.json from a prior run. If it exists, read it and extract the list of resolved issue IDs with their locations and fixes. Pass this as a prior_resolved list to each reviewer in their launch prompt. Why: Without prior-revision awareness, a second run pays full reviewer cost re-examining already-fixed text. Passing the manifest lets reviewers skip confirmed fixes and focus on changed text, unreviewed text, and new user feedback — expected token savings of ~40-60% on subsequent passes.report.md to report_draft.md to preserve the original for diffingcp <session-dir>/report.md <session-dir>/report_draft.md
Why copy, not rename: The reviewers and reviser all operate on report.md at its original path. Renaming would require updating every agent's path argument. Copying keeps the working file in place while preserving the pre-revision snapshot for diff report_draft.md report.md afterward.
This step uses a two-phase verification architecture: a lightweight claim extractor reads the report first, then small focused verifiers check pre-extracted claims against primary sources.
Launch claim-extractor subagent (Sonnet, foreground) with:
report.md (relative from project root)brief.json — it's too large and causes context overflow when combined with the verifier's source reads.${CLAUDE_PLUGIN_ROOT}/skills/deep-research/state) — needed to query evidence units for claim cross-referencingThe extractor reads the report, identifies 5-10 load-bearing claims, classifies their source types, and returns a structured claims manifest.
After it returns, parse the claims manifest JSON. If it returned 0 claims, log this and skip to Phase B with no verifier launches (only the synthesis-reviewer will run).
Shard the extracted claims into 1 claim per shard. For example, 8 claims produces 8 shards: [1], [2], ..., [8]. One claim per verifier minimizes blast radius — a single failure only loses one verification.
Launch synthesis-reviewer + claim-verifier shards in parallel (all Agent calls in the same response message):
synthesis-reviewer subagent (Sonnet) with:
report.md (relative from project root)claim-verifier subagent(s) (Sonnet, one per shard) with:
claim_id, quoted_text, report_location, cited_source_id, source_id, source_type, claim_category, verification_priority, matched_evidence_ids, evidence_strength)${CLAUDE_PLUGIN_ROOT}/skills/deep-research/state) — needed to query evidence provenance for targeted verificationWhy two-phase instead of a monolithic verifier: A single verifier that both reads the full report (~40KB+) and does web-search verification exceeds context limits during execution. The extractor reads the report once, and each verifier checks one claim against local reader notes — no report reading, no web searches, minimal context growth. One claim per verifier minimizes blast radius: a single failure only loses one verification.
After all agents return, merge the verifier shard outputs: concatenate all shards' issues arrays. Re-number verify-N IDs sequentially across shards (e.g., shard 1 produces verify-1 through verify-2, shard 2 produces verify-3 through verify-5). Then apply verifier gating to decide how much of the merged verifier output to use:
Evaluate the synthesis-reviewer's results to determine how to use the verifier's output. This controls downstream token costs — a full verifier result set adds issues to the reviser's workload, so filtering it when the reviewer's findings suggest stability avoids spending reviser tokens on redundant confirmation.
Short-circuit: If this is the first revision pass (no prior revision/verification-report.md exists), use full verification. Skip the gating evaluation entirely — the conditions below only differentiate behavior on subsequent passes. Why: First-pass verification establishes a baseline. The gating logic is ~300 words of conditional reasoning that always resolves to "full" on first pass. Making the common case a one-line check reduces the chance of misapplying the logic and avoids spending tokens on evaluation that has a predetermined outcome.
Subsequent passes (prior revision/verification-report.md exists):
Count high-severity issues from the synthesis-reviewer (not the verifier — the reviewer is the gating signal because it examines internal consistency and source support, which are leading indicators of report quality). Exclude no-op highs from this count: if a high-severity issue's suggested_fix indicates no text change is needed (e.g., contains phrases like "no change needed," "correctly placed," "no edit required"), do not count it toward the gating threshold. Why: Even with improved severity calibration (which instructs the reviewer to avoid false highs), edge cases will still produce no-op highs — observations worth noting but requiring no actual edit. Counting them inflates the gating signal, potentially triggering full verification (~5 min, ~90K tokens) when targeted or skip mode would suffice. This is a belt-and-suspenders safeguard that costs one sentence of filtering logic.
Three modes:
Full verification — use all verifier findings. Triggers when ANY of:
Targeted verification — use only verifier findings that relate to the reviewer's flagged claims. Triggers when:
issues array, check whether it targets the same section/paragraph or the same claim as one of the reviewer's high-severity issues. Keep matches, discard the rest. Why: The reviewer's 1-2 issues point to localized problems, not systemic ones. The verifier's independent analysis of those same claims adds confidence and specificity, but its findings about unrelated claims have low marginal value when the reviewer saw no problems there.Skip verification — discard all verifier findings. Triggers when:
Log the gating decision for auditability — record which mode was selected and why (e.g., "Verifier gating: targeted (2 high-severity reviewer issues, prior verification exists)"). This appears in the delivery summary so the user knows how verification results were used.
After gating, collect issues from the reviewers' issues arrays — each reviewer now returns pre-formatted issues with IDs already assigned:
issues array: take all high and medium severity issues (already prefixed review-N)issues array per gating mode: all issues (full), only issues whose location matches a reviewer-flagged section (targeted), or none (skip). Issues are already prefixed verify-N (re-numbered across shards)Why the orchestrator re-numbers verify IDs across shards: Each shard produces its own verify-1, verify-2, etc. Without re-numbering, parallel shards would produce colliding IDs. The orchestrator concatenates and re-indexes before feeding into dedup and revision.
If the user provided feedback, add the structured user directives (from the User Feedback Handling section above) to the issues list.
If zero issues found (no reviewer issues, no verifier issues after gating, no user feedback): skip directly to Step 4 (style review). Log that accuracy review found no issues.
Before passing issues to the reviser, deduplicate across reviewer and verifier results. The synthesis-reviewer and claim-verifier shards examine the report independently and often flag the same underlying problem with different phrasings, IDs, and suggested fixes. Without dedup, the reviser attempts to edit already-changed text and falls back to error recovery (re-read and retry) — which works, but wastes tokens and produces confusing manifests with one "resolved" and one "failed" entry for the same fix.
Why dedup here, not in the reviser: The reviser's "group nearby issues" heuristic (planning step) partially addresses this, but it still costs tokens to read, plan around, and attempt edits on duplicate issues. Removing duplicates before handoff is cheaper and more reliable than reactive recovery after the fact.
Run dedup:
Write the combined issues list to a temp JSON file, then:
{cli_dir}/state dedup-issues --from-json /tmp/issues.json
The command groups issues by normalized location, identifies candidate duplicate pairs based on description similarity, and returns:
candidate_duplicates — pairs with merge suggestions (which ID to keep, merged severity, flagged_by list). Each includes an overlap_signal showing the similarity score.co_located_groups — non-duplicate issues targeting the same paragraph, flagged for atomic editing.passthrough_issues — issues with unique locations that pass through unchanged.Review candidates: The script surfaces candidates; you confirm or reject each merge. Two issues at the same location with high description overlap are almost always true duplicates, but check the edge case where one flags a factual error and the other flags a missing citation at the same claim — those are different problems and should not be merged.
After confirming merges: Apply each confirmed merge to the issues list:
keep_id issue, drop the drop_id issuemerged_severityflagged_by field from the merge suggestionFor co-located groups: Add a co_located_with field to each issue listing the other issue IDs. Why: Two different issues targeting the same sentence create fragile edit sequences — the co_located_with signal tells the reviser to plan a single atomic edit for the group.
Log the merge count. Record how many issues were merged and how many co-located groups were flagged (e.g., "Dedup: merged 2 duplicate issues, flagged 1 co-located group, 14 → 12 active issues"). This is reported in the delivery summary.
Take the accuracy issues from Step 2/2b (reviewer + verifier after gating and dedup) plus any user feedback directives, and launch the accuracy reviser.
Issue ordering (the reviser processes issues in this order):
user-N) — always first, highest priorityreview-N, verify-N)Overflow guidance: If the list exceeds 30 issues, split into two batches and launch the reviser sequentially — first batch, then second batch on the updated file. Why 30: A typical reviser context handles ~25 issues comfortably; 30 gives headroom without risking quality degradation from context overload.
Spawn a report-reviser subagent (Opus, foreground) with:
report.md"accuracy"The reviser makes surgical edits using the Edit tool and returns a manifest mapping each issue to the edit made (or explaining why it's unresolved).
After the reviser returns:
report.md was updated (the reviser edits it in place)revision/revision-manifest.json as structured JSON. Include for each issue: issue ID, status, location, and fix applied (the action, old_text_snippet, and new_text_snippet fields). Why persist here, before validation: The manifest captures intent — what the reviser tried to do. Validation confirms what actually landed. Both are useful for subsequent runs: the resolved list tells reviewers what was addressed, and validation status tells them whether it stuck.If zero accuracy issues found (no reviewer issues, no verifier issues after gating, no user feedback): skip directly to Step 4 (style review). Log that accuracy review found no issues.
The reviser's manifest claims edits were made, but claims aren't proof. Validate that each edit actually landed by checking the report text against the manifest's snippets.
Why validate rather than trusting the manifest: The reviser's "re-read after editing" instruction is aspirational guidance, not an enforced check. The most common failure mode is a prior edit changing surrounding context so a later edit's old_string no longer matches — the Edit tool fails silently from the orchestrator's perspective, and the reviser may record "resolved" in the manifest despite the edit not landing.
Run validation:
{cli_dir}/state validate-edits --manifest <session-dir>/revision/revision-manifest.json --report <session-dir>/report.md --pass accuracy
The command checks each resolved edit's old_text_snippet and new_text_snippet against the report and returns:
Interpreting results and retry logic: If results.failed is non-empty, re-launch the reviser with only the failed issues (extract issue IDs from the failed array). Cap at one retry. Why one retry: The most common failure is context drift — a prior edit changed surrounding text so old_string no longer matches. One retry with the current file state fixes this because the reviser re-reads the file and targets the updated text. If an edit fails twice, the issue is likely deeper and needs human judgment, not more retries.
After the retry (or if no retry was needed), record:
results.summary.confirmed)Why style review runs after accuracy revision, not before: The style reviewer needs to see the corrected text. If the style reviewer runs on pre-revision text, it flags issues in passages that the accuracy reviser will rewrite — producing stale suggestions the style reviser can't apply. Running style review after accuracy revision means every style flag targets text that has already been corrected for factual accuracy. This eliminates the need for skip_locations (which bluntly excluded entire paragraphs) and cross-type co_located_with flags (which added complexity to prevent fragile edit sequences). The tradeoff is ~3-5 minutes of additional wall-clock time (accuracy revision must complete before style review can start), but this is offset by higher-quality style flags and zero wasted edits.
Launch style-reviewer subagent (Sonnet, foreground) with:
report.md (the accuracy-corrected version)No skip_locations needed — the style reviewer sees corrected text and can flag issues anywhere.
The style reviewer checks: passive voice, unexplained jargon, unfocused paragraphs, filler phrases, and list opportunities — without changing meaning or weakening scientific accuracy.
After it returns, collect style issues from the style-reviewer's issues array — issues are already prefixed style-N by the reviewer.
Severity filtering:
location against higher-priority style issues' location fields. If no section match, exclude it — the reviser would skip it anyway since there are no nearby edits. Why section-match: Low-severity style issues far from any other edit are almost always skipped by the reviser. Filtering by section proximity mirrors the reviser's own skip logic and avoids burdening the reviser context with issues that have a predetermined outcome."priority": "opportunistic" to each one. The reviser applies opportunistic issues only when it's already editing nearby text for a higher-priority issue — it won't force an edit on an otherwise-clean passage.Flag co-located style issues. Scan the filtered style issues for non-duplicates that target the same paragraph. For each co-located group, add a co_located_with field listing the other issue IDs. Why: Same rationale as accuracy dedup — two issues targeting the same sentence create fragile edit sequences. The co_located_with signal tells the reviser to plan a single atomic edit.
If zero style issues found after filtering: Skip style revision, proceed to delivery. Log that style review found no issues.
Spawn a report-reviser subagent (Opus, foreground) with:
report.md"style"After the reviser returns:
revision/revision-manifest.json (do not overwrite the accuracy entries — the manifest should contain both rounds)Same as Step 3b but for style edits:
{cli_dir}/state validate-edits --manifest <session-dir>/revision/revision-manifest.json --report <session-dir>/report.md --pass style
Same retry logic (one retry cap). After validation, record:
results.summary.confirmed)report.mdreview-N + verify-N resolved edits), plus user feedback items (user-N)style-N resolved edits)report_draft.md for comparisonYou are the supervisor. You orchestrate reviewers and the reviser — you do not edit the report yourself.
Use the Agent tool to spawn subagents:
synthesis-reviewer (Sonnet) — audits for contradictions, unsupported claims, secondary-source-only claims, missing applicability context, citation integrity. Returns structured issues list. Use subagent_type: "synthesis-reviewer".claim-extractor (Sonnet) — reads the report, identifies load-bearing claims, classifies source types. Returns structured claim list for verification. Use subagent_type: "claim-extractor".claim-verifier (Sonnet) — verifies a pre-extracted claim against local reader notes. One claim per verifier, no web search, no report reading. Returns verification report with verdict. Launch one per claim. Use subagent_type: "claim-verifier".style-reviewer (Sonnet) — audits for plain-language clarity. Returns structured issues list. Use subagent_type: "style-reviewer".report-reviser (Opus) — makes surgical edits based on a structured issues list. Uses Edit tool only. Returns edit manifest. Launch via Agent tool with the agents/report-reviser.md prompt.All agents must be foreground (rule 1). To parallelize the synthesis-reviewer and claim-verifier shards in Phase B, put all Agent calls in one response message. With 1 claim per verifier and notes-only verification, each verifier is lightweight.
All revision artifacts go in {session}/revision/, not notes/ or the session root. Why a separate directory: notes/ contains reader summaries from the original research pipeline — mixing in reviewer outputs makes it ambiguous whether a file came from research or revision. The revision/ subdirectory keeps provenance clear.
Why these paths are explicit here: The orchestrator doesn't read agent prompt files, so agent-defined output conventions are invisible unless mirrored in the skill prompt. These canonical paths ensure the orchestrator knows where to find results without overriding agent defaults.
| Agent | Output path |
|---|---|
| synthesis-reviewer | {session}/revision/review-report.md |
| claim-extractor | {session}/revision/claims-manifest.json |
| claim-verifier | {session}/revision/verification-report-{shard_index}.md |
| style-reviewer | {session}/revision/style-review.md |
Do not override these paths when launching agents. Let each agent write to its default location — the paths above match what the agent prompts specify. Why no overrides: Ad-hoc path overrides in agent launch prompts diverge from the agent's own conventions, causing outputs to land in unexpected locations. When the orchestrator and agent disagree on where files go, downstream steps that read those files break silently.
/deep-research again or do targeted searches manually.report.md doesn't exist, this skill can't help.