/ds-idea

name: ds-idea
description: Use when a quest needs concrete hypotheses, limitation analysis, candidate directions, or a selected idea relative to the active baseline.
skill_role: stage
license: MIT
metadata:
  author: ResearAI/DeepScientist
  version: "1.0.0"

Idea

Use this skill to turn the current baseline and problem frame into concrete, literature-grounded, testable directions.

When `startup_contract.need_research_paper = false` and the quest already has a concrete optimization handle, `idea` may stop after selecting or seeding a direction and then hand off into `optimize` instead of insisting on the full paper-oriented ideation loop. In that algorithm-first case, `idea` should usually produce a small method-brief frontier and then defer candidate ranking, promotion, and bounded search to `optimize`. When doing that handoff, prefer the brief-shaping discipline later used by `optimize`: clarify the bottleneck and constraints, keep only a small differentiated `2-3` option slate, and hand off a recommended brief rather than a pile of loose intuitions.

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.
• Keep ordinary subtask completions concise. When the idea stage actually finishes a meaningful deliverable such as a selected idea package, a rejected-ideas summary, or a route-shaping ideation checkpoint, upgrade to a richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` report.
• That richer idea-stage milestone report should normally cover: the final selected or rejected direction, why it won or lost, the main remaining risk, and the exact recommended next stage or experiment.
• That richer milestone report is still normally non-blocking. If the next experiment or route is already clear from durable evidence, continue automatically after reporting instead of waiting.
• If the runtime starts an auto-continue turn with no new user message, keep advancing from the active requirements and current durable state instead of re-answering the previous user turn.
• 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 idea progress update before assuming the task changed completely.

Stage purpose

The idea stage should not generate vague inspiration. It should produce executable hypotheses tied to:

• the active baseline
• the current codebase
• the accepted evaluation contract
• the strongest relevant prior work

This stage is not just "brainstorming". It is the research-direction selection stage. It still needs a bounded creative-divergence phase before convergence. Do not collapse onto the first plausible route just because it sounds implementable. It should normally create a new candidate direction branch and node; it does not by itself decide the next optimization round. The output must survive three checks at once:

• novelty or at least clear research value
• feasibility in the current repo and resource budget
• manuscript defensibility if the line later becomes a paper claim

When the route already looks likely to become a paper-facing line, seed one lightweight structured outline candidate during idea work. Use `artifact.submit_paper_outline(mode='candidate', ...)` for that seed instead of leaving the future paper structure only in prose. Use `references/outline-seeding-example.md` for the minimum acceptable shape. The idea-stage outline candidate is not the full paper line yet, but it should already name the likely `research_questions`, `experimental_designs`, and the first section-level evidence needs that later supplementary slices must satisfy. Keep that seed minimal and executable: a small section skeleton plus expected evidence items is better than a long narrative outline with no concrete evidence hooks. If the current research head, strongest measured branch, or active runtime refs are unclear after resume, call `artifact.get_quest_state(detail='summary')` and `artifact.list_research_branches(...)` before choosing a foundation. If the current brief / plan / status wording matters for direction choice, call `artifact.read_quest_documents(...)`. If earlier user conversation materially changes the direction-selection target, call `artifact.get_conversation_context(...)` before locking the next idea.

Finishing one idea deliverable is not quest completion. After reporting a completed idea package, continue into the next justified stage unless a real blocking decision is still unresolved.

When the quest disables research-paper delivery, keep manuscript defensibility secondary to:

• algorithmic value
• feasibility
• clean experimental follow-through
• durable recording of why this direction should be the next measured attempt

Before starting a genuinely new round, default to the current research head as the foundation. However, you may deliberately choose a different foundation when the durable evidence says it is better. When the best starting point is not obvious, inspect `artifact.list_research_branches(...)` first and compare:

• current head
• baseline foundation
• strongest recent measured branch
• older but cleaner branch

If you do not use the default current head, record the reason explicitly in the new idea submission. Treat a newly accepted branch as one durable research round. If the active branch already has a durable main-experiment result and you are starting a genuinely new optimization round, prefer creating a child branch from the chosen foundation rather than revising the old branch in place.

At the direction level, prefer elegant algorithmic or theoretical improvements over brute-force cost-for-performance tradeo