/ds-finalize

name: ds-finalize
description: Use when the quest is ready to consolidate final claims, limitations, recommendations, summary state, and graph exports before stopping or archiving.
skill_role: stage
license: MIT
metadata:
  author: ResearAI/DeepScientist
  version: "1.0.0"

Finalize

Use this skill to close or pause a quest responsibly.

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.
• Do not emit another finalize progress update when the user-visible state is unchanged.
• If the runtime starts an auto-continue turn with no new user message, keep finalizing from the durable quest state and active requirements instead of replaying the previous user turn.
• If a threaded user reply arrives, interpret it relative to the latest finalize progress update before assuming the task changed completely.
• When finalize reaches a real closure state, pause-ready packet, or route-back decision, send one threaded `artifact.interact(kind='milestone', ...)` update that names the recommendation, why it is the right call, and any reopen condition that still matters.
• True quest completion still requires explicit user approval through the runtime completion flow before calling `artifact.complete_quest(...)`.
• Rechecking that the same bundle files still exist, or re-aligning status surfaces without changing the closure judgment, does not by itself count as a fresh milestone.
• Hard execution rule: if this stage needs terminal work such as Git inspection, packaging checks, document builds, or file inspection, every such command must go through `bash_exec`.

Stage purpose

The finalize stage should not pretend every line succeeded. It should produce the most accurate final state of the quest:

• what is supported
• what is only partially supported
• what failed
• what remains open
• whether the right move is stop, archive, publish, or continue later

Finalize is not just a short summary. It is the durable closure protocol that turns a long-running research graph into a recoverable stopping point, a publishable handoff, or an honest continue-later checkpoint.

Use when

• the evidence base is stable enough for a final recommendation
• the writing line is sufficiently complete
• the user asked for a final summary or closure
• the quest should be paused or archived with a clean state

Do not use when

• major evidence gaps are still unresolved
• the current line obviously needs another experiment or analysis pass
• the quest is still in exploratory ideation

Preconditions and gate

Before finalizing, gather:

• latest baseline state
• latest accepted run and analysis state
• latest writing state
• latest decisions and open blockers
• latest quest documents
• latest review / proofing / submission state when a paper bundle exists
• the paper bundle manifest and its referenced paths when the quest has a paper-like deliverable
• the paper evidence ledger and selected-outline section statuses when the quest has a paper-like deliverable

If finalization reveals that the quest is still too uncertain, route back through `decision` rather than forcing closure. For paper-like deliverables, do not finalize while any of these remain true:

• required main-text outline items are still unresolved
• completed analysis remains unmapped into the paper contract
• the active paper line still reports open supplementary work that is expected to block the manuscript

If the current paper-state blocker is not obvious from the existing files, call `artifact.get_paper_contract_health(detail='full')` before deciding whether finalize is legitimate. If the active quest/runtime state is unclear after restart or long pause, call `artifact.get_quest_state(detail='summary')` first. If the exact latest `SUMMARY.md`, `status.md`, or active user requirement wording matters for closure, call `artifact.read_quest_documents(...)`. If earlier user/assistant continuity matters for whether the quest should really stop, call `artifact.get_conversation_context(...)` instead of guessing from prompt context alone.

Truth sources

Use:

• `SUMMARY.md`
• latest decisions
• baseline artifacts
• run artifacts
• analysis reports
• writing outputs
• review, proofing, and submission outputs when they exist
• Git history and graph
• durable literature notes already produced during the quest
• outputs or notes gathered through `artifact.arxiv(...)` when final claim checks require rereading an arXiv paper

Do not finalize from chat memory alone.

Required durable outputs

The finalize stage should usually leave behind:

• refreshed `SUMMARY.md`
• refreshed `status.md`
• final report artifact
• final decision artifact
• refreshed Git graph
• explicit limitations and next-step recommendation
• a final claim ledger or equivalent claim-status summary
• a compact resume packet or handoff packet when later continuation is plausible

If the quest produced a paper-style bundle, finalization should also check that the writing stage left behind enough closure evidence, such as:

• selected outline and outline selection records
• evidence ledger records and section-level result tables
• review output
• proofing output
• submission or packaging checklist
• final draft or bundle manifest

Workflow

1. Consolidate the accepted evidence and package inventory

State clearly:

• accepted baseline
• strongest supported claims
• weaker or partial claims
• important negative results
• unresolved risks
• key deliverables that exist and where they live

Do not only say that evidence exists. Say clearly what exists and why it matters. Name concrete paths or artifact ids only when the user asks for them or needs them to act. When a paper bundle exists, verify the manifest inve