メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use DeepScientist from Codex CLI through the native dsctl adapter for research semantics/provenance: quests, memory, artifacts, experiments, strict literature workflow, paper/resource operations, and formal ds_bash_exec evidence. Routine file/search/edit, shell, Git, tests/builds, and process work remains Codex-native. This adapter is not MCP and does not call external ds.
Use when a quest needs one or more follow-up runs such as ablations, robustness checks, error analysis, or failure analysis after a main experiment.
Use when a quest needs to attach, import, reproduce, repair, verify, compare, or publish a baseline and its metrics.
Use when the quest needs an explicit go, stop, branch, reuse-baseline, write, finalize, reset, or user-decision transition with reasons and evidence.
Use when a quest is ready for a concrete implementation pass or a main experiment run tied to a selected idea and an accepted baseline.
Use when the quest is ready to consolidate final claims, limitations, recommendations, summary state, and graph exports before stopping or archiving.
| name | deepscientist-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 |
Codex adapter note: this stage skill is bundled for the DeepScientist Codex native plugin. Use
scripts/dsctl.py call <ds_tool_name> --json ... --format jsonfor DeepScientist state instead of unavailable Hermes/MCP tool calls. Do not use MCP transport or the externaldscommand. Runtime state lives under<project>/DeepScientist/.
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, ds_bash_exec, Git, and worktree mechanisms as an optimization system.
ds_bash_exec for optimization runs whose logs must become DeepScientist quest evidence, especially formal evaluations, long runs, or frontier-shifting candidate evidence.The optimize stage should do four things:
This skill is especially appropriate when startup_contract.need_research_paper = false.
Treat optimize as one stable stage skill with six internal submodes:
briefrankseedloopfusiondebugDo 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.
Before broad optimization search or candidate management becomes substantial, maintain these quest-visible control files:
OPTIMIZE_CHECKLIST.mdCANDIDATE_BOARD.mdUse:
optimize checklist template appendix sectioncandidate board template appendix sectionOPTIMIZE_CHECKLIST.md is the execution control surface.
It should track:
CANDIDATE_BOARD.md is the compact candidate ledger.
It should track:
Treat this as the concrete optimize workflow. Do not skip these steps just because the quest is algorithm-first.
At the start of each meaningful optimize pass, use this order unless a stronger local reason exists:
ds_artifact_record / analysis artifact lookup(...)ds_memory_search(scope='quest', limit=5)ds_memory_search(...)artifact.get_quest_state(detail='summary')artifact.read_quest_documents(...) when exact durable wording mattersDo 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.
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:
2-3 serious approachesEvery serious brief should answer:
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.
Before promoting a line, compare the serious briefs on one shared ranking surface. At minimum evaluate:
Then state:
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', source_candidate_id=..., ...)ds_artifact_record payload={'kind': 'decision', 'action': 'branch'|'continue'|'stop', ...})Once a brief is promoted, the next main work belongs to experiment, not to vague optimize chatter.
Before substantial implementation or compute:
OPTIMIZE_CHECKLIST.mdCANDIDATE_BOARD.mdPLAN.mdCHECKLIST.mdThen hand off into experiment for:
Do not keep reshaping the method after the run contract is already concrete.
Use these artifact forms consistently:
artifact.submit_idea(..., submission_mode='candidate')artifact.submit_idea(..., submission_mode='line')ds_artifact_record payload={'kind': 'report', 'report_type': 'optimization_candidate', ...})ds_artifact_record_main_experiment(...)ds_artifact_record payload={'kind': 'decision', 'action': 'iterate'|'branch'|'continue'|'stop', ...})Do not treat chat summaries as substitutes for these durable records.
Optimize uses the same long-run process discipline as experiment.
ds_bash_exec for long or formal optimization runs that need durable quest-local provenance.ds_bash_exec mode='detach', ...) for long runs and monitor with list/read/await.After every real measured result:
Do not treat one candidate creation, one smoke pass, or one detached launch as stage completion.
Use the following integrated structures directly inside this skill. They replace the old optimize reference files conceptually, even if those files still exist on disk.
Every serious candidate brief should include:
Tier1 / Tier2 / Tier3Use this when a candidate direction is still fuzzy and needs to become a ranking-ready brief.
When several briefs compete, produce:
CANDIDATE_BOARD.md should expose at least these columns:
brief or implementationOPTIMIZE_CHECKLIST.md should track at least:
Whenever route choice is unclear, write down:
Choose one route deliberately:
Do not jump to a rewrite merely because one local patch failed.
When a candidate fails but still looks strategically valuable, record:
Before opening a fusion candidate, answer:
Do not fuse two weak lines or two same-mechanism lines under different names.
When writing reusable optimization lessons, capture:
If one line keeps producing non-improving results:
Do not hide plateau under a sequence of tiny "one more tweak" loops.
For candidate-brief, improve, fusion, and debug prompts, preserve:
Preserve these reasoning contracts whenever possible:
artifact.submit_idea(..., submission_mode='candidate') for candidate briefs that should be ranked before promotion.artifact.submit_idea(..., submission_mode='line') only for directions that deserve a durable optimization line and branch/worktree.ds_artifact_record payload={'kind': 'report', 'report_type': 'optimization_candidate', ...}) for implementation-level candidate attempts inside one durable line.ds_artifact_record / analysis artifact lookup(...) when available and use it as the primary optimization-state summary.Use these three object levels consistently:
candidate brief
artifact.submit_idea(mode='create', submission_mode='candidate', ...)
This records a possible direction or method brief without opening a branch yet.
durable optimization line
artifact.submit_idea(mode='create', submission_mode='line', ...)
This opens a real branch/worktree and becomes a formal optimization path.
implementation-level candidate attempt
ds_artifact_record payload={'kind': 'report', 'report_type': 'optimization_candidate', ...})
This is a within-line attempt such as one patch, one smoke candidate, one debug candidate, or one fusion candidate.
1-3 into durable lines.At the start of each meaningful optimize pass, update OPTIMIZE_CHECKLIST.md before spending significant code or compute.
At the start of a meaningful optimize pass, use this order unless a stronger local reason exists:
ds_artifact_record / analysis artifact lookup(...)ds_memory_search(...)artifact.get_quest_state(detail='summary')artifact.read_quest_documents(...) when exact durable wording mattersDo not start generating new candidates before the frontier and recent optimization lessons are checked.
Stage-start requirement:
ds_memory_search(scope='quest', limit=5)ds_memory_search(...)ds_artifact_record / analysis artifact lookup(...)OPTIMIZE_CHECKLIST.mdIf the frontier is missing or obviously stale, recover that state before proposing more work.
Choose exactly one primary optimize submode for the current meaningful pass.
Default selection order:
fusion
fusiondebug
rank
brief
seed
loop
Do not bounce among submodes repeatedly in one pass. If the best submode changes after new evidence appears, record that route shift explicitly.
When a direction is interesting but not yet worthy of a new branch:
submission_mode='candidate'Good candidate-brief fields include:
Do not promote every candidate automatically.
Use the integrated method brief template section for the minimum acceptable candidate-brief structure.
Use the integrated brief shaping playbook section when the brief is still too vague, too implementation-first, or too collapsed onto one familiar mechanism.
Candidate briefs should explicitly answer:
If the brief cannot answer those four questions clearly, it is not ready for promotion or implementation.
Treat a candidate brief as the DeepScientist form of a method brief. It should sit between "idea intuition" and "code implementation".
Preserve this brief-shaping discipline:
2-3 serious approachesDo not jump from "interesting intuition" to branch creation. Do not jump from "I know how to code this" to "this deserves promotion."
When running the brief submode:
2-4 serious candidate briefs by defaultUse a coverage contract for every serious brief slate:
incumbent-deepening direction when justifiedorthogonal-mechanism direction when justifiedparadigm/objective/data-view shift direction when justifiedIf all serious briefs belong to the same mechanism family, do one widening pass before ranking. Do not treat a same-family slate as sufficient merely because the local scores look good.
For each serious brief, record at least:
Tier1 / Tier2 / Tier3InternAgent-style behavior to preserve here:
Do not require a paper-style literature hard gate inside this submode unless the quest explicitly moved back toward paper work.
Only promote a candidate brief into a durable line when at least one of the following is true:
Promotion should use:
artifact.submit_idea(mode='create', submission_mode='line', source_candidate_id=..., ...)
When several candidate briefs are plausible, rank them explicitly before promotion.
Use the integrated candidate ranking template section for the minimum acceptable ranking record.
Default promotion rule:
1-3 candidate briefs into durable linesWhen running the rank submode:
Use a distinct promotion policy:
When ranking, explicitly check:
If the top briefs are all same-family, either:
brief for a widening passThe output of rank should be promotion-ready.
The output of brief should be candidate-ready.
At meaningful route boundaries, inspect:
Prefer these route meanings:
explore: widen search with fresh candidate directionsexploit: focus on the strongest current linefusion: merge insights from multiple successful or complementary linesdebug: rescue a candidate or line blocked by a concrete failure modestop: the current frontier is saturated or the remaining routes are not justifiedUse the integrated frontier review template section when the next route is unclear.
Interpret frontier state with these default heuristics:
explore
exploit
fusion
debug
stop
When the frontier says explore, the default optimize submode is brief.
When the frontier says exploit, the default optimize submode is seed or loop.
When the frontier says fusion, the default optimize submode is fusion.
When a candidate failure dominates the next move, the default optimize submode is debug even if the frontier does not yet say so explicitly.
Use seed after a durable line exists and before a broad execution loop begins.
The goal is not to launch a full run immediately. The goal is to generate a small within-line candidate pool that can be smoke-tested and triaged.
When running seed:
2-3 implementation-level candidates by defaultreport_type='optimization_candidate'simple-first candidate in the initial seed batchFor each seed candidate, record at least:
MLEvolve-style behavior to preserve here:
fast-check and direct quick validation is cheaper and equally informativeUse a validation-cost-aware seed policy:
fast-check: the first objective smoke signal is likely under about 20 minutesslow-check: the first objective smoke signal is likely over about 20 minutes or expensive enough that broad probing is wastefulFor fast-check seed work:
3-5 candidates can be justified when they are genuinely differentiatedFor slow-check seed work:
1-2 candidates and rarely 3Do not keep a live implementation pool dominated by the same mechanism family. Default active-pool rule:
1-2 live candidates from the same familyUse loop when a durable line and implementation-candidate pool already exist and the main need is bounded forward motion.
Before changing code in loop, inspect the same-line local attempt memory for the current line.
Treat recent sibling attempts on the same line as the first memory surface, ahead of broader quest memory.
When running loop, choose one primary action:
smokepromote_to_full_evalarchiverecord_main_resultswitch_to_fusionswitch_to_debugstopEvery loop pass should end with:
Do not leave the line with several half-started directions and no dominant next move.
Default exploit rule: one atomic improvement per pass. Do not bundle several unrelated changes into one exploit candidate unless:
MLEvolve-style behavior to preserve here:
Use a validation-cost-aware loop policy:
fast-check tasks, it is acceptable to run more quick, different tests before convergingfast-check tasks, direct quick validation may replace a separate smoke stage if that saves time without losing decision qualityslow-check tasks, use fewer but sharper passes, and require objective gain before widening or evolving furtherbriefUse a branch/family diversity cap during exploitation:
Before broad new search, run at least one ds_memory_search(...) using:
When the search appears too narrow, also retrieve one of:
For seed, loop, and debug, also inspect the same-line local attempt memory from the current leading line before widening to broader quest memory.
Write at least one quest memory card when you learn something reusable, such as:
Use the integrated optimization memory template section for the minimum acceptable memory-card shape.
Do not write generic "we tried some optimization" memory cards. Each card should be retrieval-friendly and decision-relevant.
Use:
artifact.submit_idea(..., submission_mode='candidate') for candidate briefsartifact.submit_idea(..., submission_mode='line') for durable promoted linesds_artifact_record payload={'kind': 'report', 'report_type': 'optimization_candidate', ...}) for within-line attemptsds_artifact_record payload={'kind': 'decision', 'action': 'iterate'|'branch'|'continue'|'stop', ...}) for route changesds_artifact_record_main_experiment(...) for real measured line resultsWhen the optimize pass is about ranking or promotion, also record one durable decision explaining:
When recording implementation-level candidates, prefer these status values:
proposedsmoke_runningsmoke_passedsmoke_failedpromotedfull_eval_runningsucceededfailedarchivedUse report_type='optimization_candidate' consistently for implementation-level attempts so they can later be summarized into the frontier.
ds_bash_exec for full runs or formal optimization evidence that must be auditable in the quest.fast-check direct validation is cheaper and equally informative.Use this execution order by default:
Prefer only a small active pool at once:
2-4 candidate briefs before promotion2-3 live implementation candidates in smoke1-2 full evaluations running at once unless the environment clearly supports moreValidation-cost-aware override:
20 minutes, it is reasonable to increase smoke breadth modestly and compare more alternatives early20 minutes, you may skip a separate smoke stage and submit several quick validations in parallelDo not use the same code-generation route for every optimization step.
Prefer:
brief-first, no code yet
stepwise generation
diff / patch generation
full rewrite
Use the integrated codegen route playbook section before committing to a larger rewrite.
Use debug when a candidate failed but still looks strategically valuable.
debug is bugfix-only.
Do not use a debug pass to sneak in a new performance-improvement idea.
If the proposed change goes beyond the minimal fix and becomes a new mechanism, stop and route back to brief or loop instead.
When a candidate fails:
Good debug prompts should make these explicit:
Use the integrated debug response template section for the minimum acceptable debug response shape.
Archive rather than debug when:
Use fusion only when the frontier justifies cross-line combination.
Before opening a fusion candidate:
Use the integrated fusion playbook section before launching cross-line fusion.
Do not fuse:
If the fusion hypothesis is still underspecified, return to brief instead of pretending fusion is ready.
For candidate-brief, improve, fusion, and debug prompts, preserve these recurring structures:
And preserve these recurring reasoning contracts:
Use the integrated prompt patterns section as the canonical optimization prompt crib sheet.
Treat repeated local edits without evidence gain as a search failure mode.
If one line shows repeated non-improving results:
Use the integrated fusion playbook section before launching cross-line fusion.
Use the integrated plateau response playbook section when deciding how to respond to repeated non-improving results.
Good fusion candidates usually satisfy both:
Do not fuse merely because two lines both exist.
When a line plateaus:
Do not hide plateau under a sequence of tiny "one more tweak" loops.
Family-shift trigger:
success_patience >= 2total_patience >= 5This is the default anti-collapse rule for optimize.
Before widening a stale frontier, classify the task briefly into one or more dominant structures:
Then ask whether the current brief slate overfits one familiar method family for that task. If it does, require at least one serious candidate from a different plausible family or lens before promotion.
If the optimize stage appears to stall, diagnose the stall explicitly instead of idling.
Common stall classes:
Preferred recovery order:
Do not leave the stage parked without a recorded reason and a concrete reopen condition.
Stage-end requirement:
ds_memory_write(...) when the pass produced a reusable success pattern, repeated failure pattern, fusion lesson, or explicit non-retry ruleOPTIMIZE_CHECKLIST.mdCANDIDATE_BOARD.md when the candidate pool changedIf nothing reusable was learned, record why this pass was still necessary instead of writing a fake memory card.
This stage is complete only when one of these is durably true:
Do not treat one candidate creation or one smoke pass as stage completion.
This appendix inlines the former optimize/references/*.md material so the skill remains self-contained.
Use this reference when a candidate direction is still fuzzy and needs to become a structured, ranking-ready brief.
This playbook borrows the useful part of product-style brainstorming without importing a full software-spec workflow.
The goal is not a long design document.
The goal is a compact candidate brief that is clear enough to compare, rank, and either submit as submission_mode='candidate' or reject.
Before generating more variants, resolve the minimum ambiguity around:
If one unknown would materially change every candidate, clarify it first instead of generating a noisy slate. Prefer one question at a time when clarification is genuinely needed. If the answer is already available from durable state, use that instead of asking.
Default target: 2-3 serious approaches.
The slate should usually include:
Do not produce several renamed variants of the same mechanism family. If two variants differ only by parameter choice or patch detail, keep only the sharper one.
For each candidate, write:
Before recommending a winner, compare the serious candidates on the same dimensions:
Do not let each candidate justify itself with a different scoring story. Use one comparison surface so ranking is auditable.
After comparison, recommend one lead brief and explain:
Do not say "all are promising" and promote everything. If the slate is still too close to call, return to widening once or narrow the slate further.
Before calling artifact.submit_idea(..., submission_mode='candidate', ...), check:
why_current_line_is_limited explain a real gap instead of restating the mechanism?why_now explain what changed in evidence, failure pattern, or frontier state?If any answer is no, refine the brief before submission.
A good final brief package is short and structured:
2-3 candidate comparison table or bullet slatemethod-brief-template.md sectionKeep it compact. This is a shaping pass for optimization candidates, not a paper draft or engineering spec.
| Candidate ID | Level | Parent | Strategy | Status | Expected Gain | Observed Result | Promote / Archive |
|---|---|---|---|---|---|---|---|
| cand-001 | brief | current-head | explore | proposed | Better tail accuracy | n/a | pending |
| cand-002 | impl | cand-001 | exploit | smoke_passed | Faster convergence | smoke ok | consider promote |
Notes:
Level should be brief or implementationParent may be a branch, idea id, run id, or candidate idStrategy should usually be one of explore, exploit, fusion, debugPromote / Archive should be a clear recommendation, not an empty placeholdercandidate_id
Score summary:
Why it ranks here:
Promote / hold / reject:
candidate_id
Score summary:
Why it ranks here:
Promote / hold / reject:
candidate_id
Score summary:
Why it ranks here:
Promote / hold / reject:
Why the selected candidate should become a durable line now.
Why the other candidates were deferred, fused, or rejected.
Choose the code-generation route deliberately.
Use no-code candidate briefs when:
Prefer stepwise generation when:
Prefer diff / patch generation when:
Use a full rewrite only when:
Do not jump to a rewrite merely because one local patch failed.
For non-trivial codegen work, prefer this shape:
Do not go from a vague idea directly into a large patch with no intermediate plan.
What concrete error or failure occurred?
What similar failure pattern or repair lesson should be reused before changing code?
What is the most likely underlying cause?
What is the smallest plausible fix?
What parts of the line must remain unchanged for comparability and stability?
What bounded smoke or validation check should confirm the fix?
What outcome would prove this candidate should be archived instead of debugged again?
Use fusion only when:
Before fusion, write down:
source line A: strongest mechanism: strongest evidence: main weakness: what must survive the fusion:
source line B: strongest mechanism: strongest evidence: main weakness: what must survive the fusion:
Then answer:
Do not fuse:
One short line naming the candidate direction.
What concrete bottleneck or limitation does this target?
Why is the current best line or baseline not already solving this?
What specific intervention or design change is proposed?
Name the family explicitly, for example adapter, loss, architecture, augmentation, ensemble, retrieval, objective-shift.
One of:
Tier1: local optimization / training detailTier2: representation or component changeTier3: paradigm or system-level shiftWhere did this candidate come from?
What must remain stable for comparability?
What evidence should improve if this works?
Usually optimize or experiment.
What actually happened?
Why should a later optimization pass retrieve this?
When should this lesson be reused, and when should it be avoided?
ds_artifact_record / analysis artifact lookup(...) or equivalent durable frontier summarybrief, rank, seed, loop, fusion, or debugexplore, exploit, fusion, debug, or stopUse this when one line keeps producing non-improving results.
These prompt structures are worth preserving across optimize subroutines.
When the line is stagnating:
When combining lines:
For debugging: