/ds-optimize

name: ds-optimize
description: Use when an algorithm-first quest should manage candidate briefs, optimization frontier, branch promotion, or fusion-aware search instead of the paper-oriented default loop.
skill_role: stage
license: MIT
metadata:
  author: ResearAI/DeepScientist
  version: "1.0.0"

Optimize

Use this skill for algorithm-first quests where the goal is the strongest justified optimization result rather than paper packaging.

This skill is the lightweight optimization control layer for DeepScientist. It does not replace the normal quest runtime. It tells you how to use the existing DeepScientist artifact, memory, bash_exec, Git, and worktree mechanisms as an optimization system.

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.
• Ordinary candidate creation, smoke checks, and route updates should stay concise.
• Use richer milestone updates only when a candidate is promoted, a strong run finishes, the frontier shifts materially, or a fusion/debug route becomes the new main path.
• When the user asks for the current optimization state, answer from the frontier and durable artifacts rather than from chat memory.
• Hard execution rule: every terminal command in this stage must go through `bash_exec`; do not use any other terminal path for smoke checks, quick validations, long runs, Git, Python, package-manager, or file-inspection commands.

Stage purpose

The optimize stage should do four things:

1. turn loose ideas into candidate briefs 2. rank and promote only the strongest briefs into durable lines 3. manage candidate attempts within a durable line 4. choose when to explore, exploit, fuse, debug, or stop

This skill is especially appropriate when `startup_contract.need_research_paper = false`.

Treat `optimize` as one stable stage skill with six internal submodes:

• `brief`
• `rank`
• `seed`
• `loop`
• `fusion`
• `debug`

Do not treat these as separate public skills. Treat them as internal execution modes inside one optimize workflow.

InternAgent maps most naturally onto the `brief` and `rank` side of this stage. MLEvolve maps most naturally onto the `seed`, `loop`, `fusion`, and `debug` side of this stage. Do not collapse those two layers into one vague "optimize more" loop.

Required working files

Before broad optimization search or candidate management becomes substantial, maintain these quest-visible control files:

• `OPTIMIZE_CHECKLIST.md`
• `CANDIDATE_BOARD.md`

Use:

• the integrated `optimize checklist template` appendix section
• the integrated `candidate board template` appendix section

`OPTIMIZE_CHECKLIST.md` is the execution control surface. It should track:

• current frontier mode
• current optimize submode
• candidate brief count
• promoted line count
• current smoke queue
• current full-eval queue
• stagnation / fusion checks
• next concrete action

`CANDIDATE_BOARD.md` is the compact candidate ledger. It should track:

• candidate id
• candidate type: brief or implementation attempt
• parent line or parent candidate
• strategy: explore / exploit / fusion / debug
• status
• expected gain
• observed result
• promote / archive recommendation

Required MCP-driven workflow

Treat this as the concrete optimize workflow. Do not skip these steps just because the quest is algorithm-first.

1. Recover the optimization state first

At the start of each meaningful optimize pass, use this order unless a stronger local reason exists:

1. `artifact.get_optimization_frontier(...)` 2. `memory.list_recent(scope='quest', limit=5)` 3. `memory.search(...)` 4. `artifact.get_quest_state(detail='summary')` 5. `artifact.read_quest_documents(...)` when exact durable wording matters

Do not create new candidates before the frontier, recent optimization lessons, and current runtime refs are checked. If the frontier is missing or obviously stale, recover that state before proposing more work.

2. Shape candidate briefs before branch promotion

When the next direction is still fuzzy, do not jump straight into code or branch creation. First turn the direction into a compact candidate brief.

The brief-shaping sequence is:

1. clarify the bottleneck, constraints, and comparability boundary 2. identify the incumbent or baseline that this brief must beat or complement 3. generate a small differentiated slate, usually `2-3` serious approaches 4. compare them on one shared surface 5. recommend exactly one lead brief 6. self-check the recommended brief before submission

Every serious brief should answer:

• bottleneck
• why_current_line_is_limited
• mechanism
• why_now
• keep_unchanged
• expected_gain
• implementation_surface
• main_risks

The durable call for this step is usually:

• `artifact.submit_idea(mode='create', submission_mode='candidate', ...)`

Use `idea` when the mechanism family itself is still unresolved. Use `optimize` when the family is already chosen and the work is now branchless brief shaping, ranking, or within-line search.

3. Rank candidate briefs on one explicit surface

Before promoting a line, compare the serious briefs on one shared ranking surface. At minimum evaluate:

• expected information gain
• feasibility in current repo
• comparability against baseline
• implementation surface
• novelty or distinctiveness
• family diversity
• change-layer diversity
• incumbent-improvement potential
• failure risk

Then state:

• winner justification
• non-winner defer / reject reasons
• promotion cap: how many lines should actually be promoted now

Do not promote every plausible brief. Default rule: promote only `1-3` candidate briefs, and usually fewer.

The durable call for this step is one of:

• `artifact.submit_idea(mode='create', submission_mode='line', sour