Ds Intake Audit

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 artifact.interact(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 use native shell_command / command_execution in this skill.
• Any shell, CLI, Python, bash, node, git, npm, uv, or repo-audit execution must go through bash_exec(...).
• For git inspection or maintenance inside the current quest repository or worktree, prefer artifact.git(...) 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 memory.list_recent(scope='quest', limit=5)
• run at least one 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.