deepscientist-intake-audit

name	deepscientist-intake-audit
description	Use when a quest does not start from a blank state and the agent must first audit, trust-rank, and reconcile existing baselines, results, drafts, or review materials before choosing the next anchor.
skill_role	companion

Codex adapter note: this stage skill is bundled for the DeepScientist Codex native plugin. Use scripts/dsctl.py call <ds_tool_name> --json ... --format json for DeepScientist state instead of unavailable Hermes/MCP tool calls. Do not use MCP transport or the external ds command. Runtime state lives under <project>/DeepScientist/.

Intake Audit

Use this skill when the quest already has meaningful state and the first job is to normalize that state instead of restarting the canonical research loop from zero.

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.
• Message templates are references only. Adapt to the actual context and vary wording so updates feel natural and non-robotic.
• If a threaded user reply arrives, interpret it relative to the latest intake-audit progress update before assuming the task changed completely.
• When the audit reaches a durable route recommendation, send one richer ds_artifact_record payload={'kind': 'milestone'}, reply_mode='threaded', ...) update that says what state is trusted, what still needs work, and which anchor should run next.

Tool discipline

• Do not bypass DeepScientist semantic tools for durable research state; Codex-native file/shell/process tools remain appropriate for routine operation-layer work.
• Use Codex-native execution for routine shell/CLI/Python/node/git/npm/uv/repo-audit checks. Use ds_bash_exec only when the audit command itself must become DeepScientist quest evidence.
• For git inspection or maintenance inside the current quest repository or worktree, prefer quest-local git state via backend service or Codex-controlled git action(...) before raw shell git commands.
• Use shell execution only when durable quest files, artifacts, and memory are insufficient; do not bypass durable state just because shell feels faster.

Purpose

intake-audit is an auxiliary entry skill, not a normal long-running anchor.

Its purpose is to answer four questions before deeper work begins:

1. what already exists?
2. what is trustworthy?
3. what can be reused directly?
4. which skill should take over next?

This skill exists because many quests do not start from a clean slate. Common non-blank starts include:

• a baseline already exists and may already be confirmed
• a main experiment has already finished and only needs durable recording or interpretation
• analysis results already exist across child branches or worktrees
• a draft or paper bundle already exists
• reviewer comments already exist and the quest is really a revision/rebuttal task
• the user explicitly says not to rerun from scratch

Do not treat these as edge cases. They are common research entry states.

Use when

• startup_contract.launch_mode = custom and the profile implies existing work
• the quest root already contains meaningful baseline, experiment, analysis, or paper assets
• the user says:
  • “baseline 已经有了”
  • “不要重新复现”
  • “先整理现有结果”
  • “已有论文/草稿，先基于现有状态继续”
• review materials exist but the current paper/result state is still unclear

Do not use when

• the quest is genuinely blank and should start with ordinary scout or baseline
• the active state is already well-normalized and the next anchor is obvious
• the task is a pure non-research request

Non-negotiable rules

• Do not rerun expensive work just because files exist. First decide whether a trust gap actually requires rerunning.
• Do not fabricate missing durable records in order to make the quest look cleaner.
• Do not mark an existing baseline as trusted unless the metric contract, source, and comparability are clear enough.
• Do not mark an existing experiment as a durable main result unless it is genuinely the main run for an accepted idea line.
• Do not silently import old drafts, plots, or notes as the active contract if they belong to a different idea line or branch line.
• Do not lose provenance. If an artifact is reused, record where it came from and why it is trusted enough.
• If the quest is really a review/revision task, route to rebuttal instead of pretending this is a normal fresh paper-writing pass.

Typical intake states

Classify the current quest into one or more of these buckets:

• baseline_ready
• baseline_partial
• main_result_ready
• analysis_ready
• draft_ready
• paper_bundle_ready
• review_package_ready
• unclear_state

Also classify every important asset by trust:

• trusted
• usable_with_verification
• reference_only
• stale_or_conflicting
• missing_context

Primary truth sources

Use, in roughly this order:

• startup_contract
  • especially launch_mode, custom_profile, entry_state_summary, review_summary, and custom_brief when present
• quest continuity files:
  • brief.md
  • plan.md
  • status.md
  • SUMMARY.md
• recent durable artifact state and quest snapshot
• current workspace tree and visible quest files
• prior memory cards and decisions
• git history and current branch topology when needed
• user messages

Do not trust chat recollection over durable state.

Workflow

1. Read startup intent first

Before touching the workspace, inspect:

• startup_contract
• the latest user message
• recent quest status

Interpret these fields specially when present:

• launch_mode = custom
  • do not force the standard full-research route
• custom_profile = continue_existing_state
  • expect reusable assets and state normalization
• custom_profile = revision_rebuttal
  • expect a paper/review package and likely handoff to rebuttal
• custom_profile = freeform
  • prefer the custom brief over the default stage ordering

2. Retrieve memory before filesystem triage

Stage-start requirement:

• run ds_memory_search(scope='quest', limit=5)
• run at least one ds_memory_search(...) using:
  • the quest title or central topic
  • any known baseline id or method name
  • any known paper title or venue short name
  • any known review keyword such as rebuttal, review, or revision

The point is to reuse prior route knowledge before re-auditing the same state from scratch.

3. Inventory the quest state

Create or refresh a durable audit note using references/state-audit-template.md.

The inventory should cover:

• baseline assets
• main experiment assets
• analysis assets
• writing assets
• review assets
• git / branch / worktree state
• missing or conflicting state

Useful places to inspect include:

• artifacts/
• baselines/
• experiments/main/
• experiments/analysis/
• paper/
• reviews/ or equivalent user-provided review folders

Do not over-read the entire tree. Read enough to classify the state and locate the likely trust anchors.

4. Trust-rank and reconcile

For each major asset, decide:

• can it be trusted as-is?
• does it need a light verification pass?
• is it only reference material?
• is it stale or conflicting?

Then reconcile it with the durable artifact layer:

• existing reusable baseline:
  • artifact.attach_baseline(...)
  • then artifact.confirm_baseline(...) when trust is justified
• existing main result:
  • ds_artifact_record_main_experiment(...) only if the run is genuinely the accepted main run and the required fields can be filled honestly
• existing analysis results:
  • if the campaign already exists, use ds_artifact_record_analysis_slice(...) for each real finished slice that needs durable registration
• existing outline:
  • artifact.submit_paper_outline(mode='select'|'revise', ...) when there is a real durable outline contract
• existing paper bundle:
  • artifact.submit_paper_bundle(...) when the draft/package state is genuinely ready

If the evidence is insufficient for a durable backfill, record that insufficiency explicitly instead of inventing a cleaned-up history.

5. Choose the next anchor

After reconciliation, write one durable route decision with ds_artifact_record payload={'kind': 'decision', ...}).

Typical next anchors:

• baseline exists but trust is incomplete -> baseline
• baseline and route are ready, but no durable main result exists -> experiment
• main result exists, but follow-up evidence is missing -> analysis-campaign
• evidence is strong and writing should begin -> write
• review package is active -> rebuttal
• the quest is effectively complete or should pause -> finalize

6. Report and hand off

At the end of the intake pass, send one threaded ds_artifact_record payload={'kind': 'milestone'}, ...) update that says:

• what already exists and is trusted
• what remains untrusted or incomplete
• which next skill should take over
• whether the user needs to provide anything else

Recommended durable outputs

• artifacts/intake/state_audit.md
• artifacts/intake/recommended_next_step.md
• one decision artifact for the post-audit route
• one or more repair/backfill artifact calls when justified

Companion skill routing

Open additional skills only when the audit indicates they are necessary:

• baseline
  • when an existing baseline must be validated, repaired, confirmed, or waived
• experiment
  • when the accepted route lacks a durably recorded main result
• analysis-campaign
  • when the main result exists but the evidence boundary is still weak
• write
  • when a trustworthy draft or outline should become the active writing line
• rebuttal
  • when reviewer comments, revision requests, or meta-review materials define the real task
• decision
  • when more than one next anchor remains plausible

Memory discipline

Stage-end requirement:

• if the intake pass produced a durable route choice, trust judgment, or asset-reuse rule, write at least one ds_memory_write(...)

Useful tags include:

• stage:intake-audit
• type:state-audit
• type:route-handoff
• type:reuse-rule
• state:trusted
• state:needs-verification

When the audit concerns a specific existing line, include identifiers when known:

• baseline_id
• idea_id
• run_id
• branch
• paper_state

Success condition

intake-audit is successful when:

• the quest's current state is understandable
• the trustworthy reusable assets are explicit
• the untrusted gaps are explicit
• the next anchor is explicit
• the system can continue without pretending the quest started from zero