deepscientist-intake-audit

> 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