/ds-scout

name: ds-scout
description: Use when a quest needs problem framing, literature scouting, dataset or metric clarification, or baseline discovery before deeper work.
skill_role: stage
license: MIT
metadata:
  author: ResearAI/DeepScientist
  version: "1.0.0"

Scout

Use this skill when the quest does not yet have a stable research frame.

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 scout progress update before assuming the task changed completely.
• When scouting actually resolves the framing ambiguity, locks the evaluation contract, or makes the next anchor obvious, send one richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` update that says what is now clear, why it matters, and which stage should come 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-inspection execution must go through `bash_exec(...)`.**
• **For git inspection inside the current quest repository or worktree, prefer `artifact.git(...)` before raw shell git commands.**
• **If scouting only needs durable quest context, prefer `artifact.read_quest_documents(...)`, `artifact.get_quest_state(...)`, and `memory.*` instead of shelling out.**

Stage purpose

The scout stage exists to answer the smallest set of framing questions required to make the rest of the quest efficient:

• what exact task is being solved?
• which dataset, split, and metric contract matter?
• which papers, repos, and baselines define the local neighborhood?
• which unknowns still block baseline or ideation?

This stage is not generic browsing. It is a bounded framing and discovery stage that should quickly make the next anchor obvious.

The scout stage should usually establish four layers:

• task-definition layer
• evaluation-contract layer
• literature and repo neighborhood layer
• baseline-direction layer

If one of these layers is still missing, say so explicitly.

Non-negotiable rules

• Do not let `scout` become endless exploration.
• Do not keep searching once the next anchor is already clear.
• Do not guess the metric, split, or baseline identity when local evidence is still ambiguous.
• Do not ask the user ordinary technical questions before checking local evidence first.
• Do not force a baseline route without comparing attach, import, and reproduce options.
• Do not rely on memory alone when primary sources or durable quest files exist.
• Before broad external search, check quest/global memory first with `memory.list_recent(...)` and `memory.search(...)`.
• When search tools are available, actively use them.

Prefer web search for paper discovery, usually targeting arXiv first, then expand with benchmark docs, official repos, and broader web search for provenance.

• When a specific arXiv paper must be read or summarized, use `artifact.arxiv(paper_id=..., full_text=False)` instead of defaulting to a raw PDF.

Keep discovery in web search; use `artifact.arxiv(...)` only for actual paper reading, and set `full_text=True` only when needed.

• Avoid repeating the same wide search from scratch.

Reuse prior survey notes and search only for genuinely missing, newer, or unresolved references.

• Do not write long paper summaries that do not change the next stage.
• Search for disconfirming evidence, not only supportive evidence.
• If the apparent gap is already closed by straightforward scaling, standard engineering, or a strong recent paper, say so directly instead of inflating novelty.

Use when

• the user goal is still ambiguous
• the dataset or split contract is unclear
• the primary metric is unclear
• no trustworthy baseline has been identified
• the paper or repo neighborhood is still thin
• the quest was resumed after a long pause and framing needs reconstruction
• the next stage is blocked by ambiguity rather than by implementation

Do not use when

• the user already fixed the paper, baseline, dataset, metric contract, and scope
• the quest already has a validated baseline and is ready for ideation or execution
• the real blocker is execution or verification rather than framing

Preconditions and gate

Before spending time scouting, first verify whether the current quest already contains enough framing in:

• `brief.md`
• `plan.md`
• `status.md`
• `SUMMARY.md`
• baseline artifacts
• recent paper or knowledge memory cards

If the answer is already clear, exit quickly and move to the correct next anchor.

Companion skill rule

`scout` is the framing anchor. It often prepares for `baseline`.

In practice:

• use `scout` to determine the task frame, evaluation contract, paper neighborhood, and candidate baselines
• use `baseline` once a concrete baseline route is justified

Do not stay in `scout` once the next `baseline` route is obvious enough to record durably.

Truth sources

Prefer the following sources in order:

1. user-provided task description and explicit constraints 2. durable quest files and artifacts 3. codebase and repository docs 4. primary papers, official repos, and benchmark docs 5. existing reusable baselines and quest/global memory 6. web-search results, often including arXiv and adjacent sources, used to fill gaps, verify provenance, or update recency

Do not let the scout stage rest on vague recollection alone.

Required durable outputs

The scout stage should usually leave behind:

• an updated `brief.md`
• an updated `plan.md`
• optional `status.md` refresh if the quest state