algorithm-design-planner

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Algorithm Design Planner

Algorithm设计规划器

Convert a validated research idea into a concrete method design that can be implemented, ablated, evaluated, and explained in a paper.

Use this skill when:

an idea has passed early validation and needs an actual algorithm
a method, loss, architecture, inference procedure, or training recipe is underspecified
the user needs a method design document before coding
a project needs assumptions, failure modes, ablations, and implementation boundaries
early results suggest revising the algorithm rather than only rerunning experiments
a paper's method section is hard to write because the method itself is not precise

Do not use this skill to launch experiments. Pair it with

experiment-design-planner

after the design is specific enough to test.

Pair this skill with:

```
research-project-memory
```
when the design changes claims, assumptions, risks, actions, or worktree purpose
```
research-idea-validator
```
before this skill if the idea itself may not be worth pursuing
```
literature-review-sprint
```
when the closest prior method is unclear
```
experiment-design-planner
```
after the method produces testable hypotheses and ablations
```
run-experiment
```
only after implementation and experiment design are ready
```
conference-writing-adapter
```
when translating the final design into paper prose

将经过验证的研究想法转化为可实现、可进行ablation、可评估且能在论文中阐述的具体method设计。

在以下场景使用本技能：

某个想法已通过早期验证，需要一个实际的algorithm
method、loss、architecture、inference procedure或training recipe的定义不够明确
用户需要在编码前完成一份method设计文档
项目需要明确假设、失效模式、ablation以及实现边界
早期结果表明需要修改algorithm，而非仅重新运行实验
论文的method部分难以撰写，因为method本身不够精准

请勿使用本技能启动实验。当设计足够具体可测试后，可搭配

experiment-design-planner

使用。

可搭配以下技能使用：

当设计变更了主张、假设、风险、行动或工作树目标时，搭配
```
research-project-memory
```
如果想法本身可能不值得深入研究，在使用本技能前先搭配
```
research-idea-validator
```
当最接近的prior method不明确时，搭配
```
literature-review-sprint
```
当method产生可测试的假设和ablation后，搭配
```
experiment-design-planner
```
仅在implementation和实验设计准备就绪后，搭配
```
run-experiment
```
当将最终设计转化为论文文本时，搭配
```
conference-writing-adapter
```

Skill Directory Layout

技能目录结构

text

<installed-skill-dir>/
├── SKILL.md
└── references/
    ├── ablation-implications.md
    ├── design-rubric.md
    ├── failure-mode-map.md
    ├── implementation-handoff.md
    ├── method-spec-template.md
    └── paper-method-bridge.md

text

<installed-skill-dir>/
├── SKILL.md
└── references/
    ├── ablation-implications.md
    ├── design-rubric.md
    ├── failure-mode-map.md
    ├── implementation-handoff.md
    ├── method-spec-template.md
    └── paper-method-bridge.md

Progressive Loading

渐进式加载

Always read

references/design-rubric.md

and

references/method-spec-template.md

Read
```
references/failure-mode-map.md
```
when assumptions, edge cases, or negative results matter.
Read
```
references/ablation-implications.md
```
when the method has components, losses, objectives, schedules, architectures, or inference changes.
Read
```
references/implementation-handoff.md
```
before producing coding tasks or worktree plans.
Read
```
references/paper-method-bridge.md
```
when the design must become a method section.
If novelty depends on current methods or baselines, verify with web search or user-provided papers.

务必阅读

references/design-rubric.md

和

references/method-spec-template.md

。

当假设、边缘情况或负面结果重要时，阅读
```
references/failure-mode-map.md
```
。
当method包含组件、loss、目标、调度、architecture或inference变更时，阅读
```
references/ablation-implications.md
```
。
在生成编码任务或工作树计划前，阅读
```
references/implementation-handoff.md
```
。
当设计需要转化为论文method部分时，阅读
```
references/paper-method-bridge.md
```
。
如果创新性依赖于当前method或baseline，通过网络搜索或用户提供的论文进行验证。

Core Principles

核心原则

Design the mechanism before designing the experiment.
Separate the problem, method, claim, and evidence plan.
Make the smallest method that could test the core idea.
State assumptions and invariants explicitly.
Identify what is genuinely new relative to the closest baseline.
Every method component should have a reason, an ablation, and a failure mode.
Avoid adding knobs that cannot be justified, tuned fairly, or explained to reviewers.
Produce an implementation handoff that prevents hidden design decisions from being made during coding.

在设计实验前先设计机制。
分离问题、method、主张和证据计划。
设计能够测试核心想法的最小化method。
明确陈述假设和不变量。
识别与最接近的baseline相比真正具有创新性的部分。
每个method组件都应有其存在的理由、对应的ablation和失效模式。
避免添加无法证明合理性、无法公平调优或无法向审稿人解释的控制项。
生成一份实现交接文档，防止在编码过程中做出隐藏的设计决策。

Step 1 - Recover Context

步骤1 - 恢复上下文

Collect:

validated idea or project direction
current decision from
```
research-idea-validator
```
, if available
target paper claim
target model/task/domain
closest baseline or prior method
available codebase and implementation constraints
known experiments or negative results
project memory IDs such as
```
CLM-###
```
,
```
RSK-###
```
, or
```
ACT-###
```
, if present

If the idea is still vague, rewrite it into:

text

For [problem/setting], modify [baseline] by [mechanism] so that [expected property] improves because [assumption].

If this sentence cannot be written, route back to

research-idea-validator

literature-review-sprint

收集以下信息：

经过验证的想法或项目方向
若有，来自
```
research-idea-validator
```
的当前决策
目标论文主张
目标model/task/domain
最接近的baseline或prior method
可用的代码库和implementation约束
已知的实验或负面结果
项目记忆ID（如
```
CLM-###
```
、
```
RSK-###
```
或
```
ACT-###
```
）（若存在）

如果想法仍模糊不清，将其重写为：

text

For [problem/setting], modify [baseline] by [mechanism] so that [expected property] improves because [assumption].

如果无法写出这句话，转至

research-idea-validator

或

literature-review-sprint

。

Step 2 - Choose Design Mode

步骤2 - 选择设计模式

Classify the design:

```
method
```
: new algorithm, training recipe, or inference procedure
```
objective
```
: new loss, regularizer, constraint, reward, or optimization criterion
```
architecture
```
: new module, representation, layer, routing, memory, or parameterization
```
theory
```
: formal method derived from assumptions, theorem, bound, or principle
```
system
```
: pipeline, infrastructure, scheduling, retrieval, data, or tooling design
```
revision
```
: method update after negative or ambiguous results

Use one primary mode and optional secondary modes.

对设计进行分类：

```
method
```
：新algorithm、training recipe或inference procedure
```
objective
```
：新loss、正则化器、约束、奖励或优化准则
```
architecture
```
：新模块、表示、层、路由、内存或参数化方式
```
theory
```
：基于假设、定理、边界或原则推导的formal method
```
system
```
：流水线、基础设施、调度、检索、数据或工具设计
```
revision
```
：在负面或模糊结果后对method进行的更新

使用一种主要模式和可选的次要模式。

Step 3 - Build the Method Spec

步骤3 - 构建Method规范

Read

references/design-rubric.md

and

references/method-spec-template.md

Define:

problem formulation
inputs and outputs
baseline being modified
core mechanism
training objective or loss, if any
inference or sampling procedure, if any
architecture or module changes, if any
assumptions and invariants
hyperparameters and schedules
computational cost
expected behavior
what stays unchanged from the baseline

Use math, pseudocode, or structured bullets as appropriate. Do not hide important design decisions in prose.

阅读

references/design-rubric.md

和

references/method-spec-template.md

。

定义以下内容：

问题公式化描述
输入和输出
待修改的baseline
核心机制
训练目标或loss（若有）
推理或采样流程（若有）
architecture或模块变更（若有）
假设和不变量
超参数和调度
计算成本
预期行为
与baseline相比保持不变的部分

根据情况使用数学公式、伪代码或结构化项目符号。请勿将重要的设计决策隐藏在文本描述中。

Step 4 - Check Novelty and Minimality

步骤4 - 检查创新性与最小化

Ask:

What is the irreducible difference from the closest baseline?
Which part is necessary for the claim?
Which part is convenience, engineering, or tuning?
Can the first implementation test a smaller version?
Could a reviewer call this a minor tweak?

If the new idea depends on multiple changes, separate core design from optional extensions.

思考以下问题：

与最接近的baseline相比，不可简化的差异是什么？
哪一部分是主张所必需的？
哪一部分是便利性、工程实现或调优？
首次implementation能否测试一个更小的版本？
审稿人是否会认为这只是一个微小的调整？

如果新想法依赖于多项变更，将核心设计与可选扩展分离。

Step 5 - Map Failure Modes

步骤5 - 映射失效模式

Read

references/failure-mode-map.md

List:

assumptions that may be false
data or task regimes where the method should fail
optimization or stability risks
metric mismatch risks
computational risks
confounds that could explain gains
signs that the design should be revised, parked, or killed

Negative outcomes should map to decisions, not vague concern.

阅读

references/failure-mode-map.md

。

列出以下内容：

可能不成立的假设
method应失效的数据或任务场景
优化或稳定性风险
指标不匹配风险
计算风险
可能解释性能提升的混淆因素
表明设计应被修改、搁置或终止的迹象

负面结果应对应具体决策，而非模糊的担忧。

Step 6 - Derive Ablations and Diagnostics

步骤6 - 推导Ablation与诊断方法

Read

references/ablation-implications.md

For each method component, define:

why it exists
what happens if removed
what diagnostic tests its mechanism
what hyperparameter or schedule must be swept
what baseline or control separates the mechanism from tuning or compute

This output should feed directly into

experiment-design-planner

阅读

references/ablation-implications.md

。

针对每个method组件，定义：

其存在的原因
移除后会发生什么
测试其机制的诊断方法
必须调整的超参数或调度
将机制与调优或计算资源区分开的baseline或控制组

此输出应直接供

experiment-design-planner

使用。

Step 7 - Prepare Implementation Handoff

步骤7 - 准备实现交接文档

Read

references/implementation-handoff.md

Produce:

files/modules likely to change
public interfaces or config names
minimal prototype plan
unit/smoke tests
logging requirements
worktree or branch purpose
exit condition: merge, continue, park, or kill
risks that coding should not decide silently

If no codebase exists, define a minimal scaffold or prototype boundary instead of a full engineering plan.

阅读

references/implementation-handoff.md

。

生成以下内容：

可能变更的文件/模块
公共接口或配置名称
最小化原型计划
单元/冒烟测试
日志要求
工作树或分支目标
退出条件：合并、继续、搁置或终止
编码过程中不应自行决定的风险

如果没有可用的代码库，定义最小化的框架或原型边界，而非完整的工程计划。

Step 8 - Bridge to Paper Method Section

步骤8 - 衔接至论文Method部分

Read

references/paper-method-bridge.md

when useful.

Produce:

method name, if needed
method-section outline
algorithm box contents
equations or definitions required
assumptions to state
reviewer-facing explanation of why the mechanism should work
claims to avoid until evidence exists

必要时阅读

references/paper-method-bridge.md

。

生成以下内容：

method名称（若需要）
method部分大纲
算法框内容
所需的公式或定义
需要陈述的假设
面向审稿人的机制合理性解释
在有证据前应避免提出的主张

Step 9 - Write the Design Document

步骤9 - 撰写设计文档

If saving to a project and no path is given, use:

text

docs/designs/algorithm_design_YYYY-MM-DD_<short-name>.md

Use this structure:

markdown

undefined

如果要保存到项目中且未指定路径，使用：

text

docs/designs/algorithm_design_YYYY-MM-DD_<short-name>.md

使用以下结构：

markdown

undefined

Algorithm Design: [Name]

Design Context

Target Claim

Design Decision

Problem Formulation

Method Specification

Assumptions and Invariants

Relation to Baseline and Prior Work

Failure Modes

Ablations and Diagnostics

Implementation Handoff

Experiment Handoff

Paper Method Bridge

Project Memory Writeback

undefined

undefined

Step 10 - Write Back to Project Memory

步骤10 - 写入项目记忆

If the project uses

research-project-memory

, update:

```
memory/decision-log.md
```
: durable design choices and why
```
memory/claim-board.md
```
: method claims that are planned, revised, weakened, or cut
```
memory/risk-board.md
```
: mechanism, implementation, baseline, tuning, compute, and evaluation risks
```
memory/action-board.md
```
: implementation, ablation, diagnostic, literature, or experiment-design actions
```
memory/evidence-board.md
```
: planned diagnostics or experiment families when concrete enough
worktree
```
.agent/worktree-status.md
```
: purpose, linked claims, linked experiments, and exit condition for implementation branches

Use

planned

for evidence and

inferred

for failure modes until observed.

如果项目使用

research-project-memory

，更新以下内容：

```
memory/decision-log.md
```
：持久化的设计选择及其原因
```
memory/claim-board.md
```
：已规划、修订、弱化或删除的method主张
```
memory/risk-board.md
```
：机制、implementation、baseline、调优、计算和评估风险
```
memory/action-board.md
```
：implementation、ablation、诊断、文献调研或实验设计行动
```
memory/evidence-board.md
```
：足够具体的已规划诊断或实验系列
工作树
```
.agent/worktree-status.md
```
：实现分支的目标、关联主张、关联实验和退出条件

对于证据使用

planned

状态，对于失效模式使用

inferred

状态，直到观察到实际结果。

Final Sanity Check

最终合理性检查

Before finalizing:

problem, baseline, and method are explicit
core mechanism is distinguishable from optional engineering
assumptions and invariants are stated
every new component has an ablation or diagnostic
implementation handoff is concrete enough for coding
experiment handoff is concrete enough for
```
experiment-design-planner
```
paper-method bridge does not overclaim beyond planned evidence
project memory is updated when present

在定稿前确认：

问题、baseline和method明确清晰
核心机制与可选工程实现可区分
假设和不变量已明确陈述
每个新组件都有对应的ablation或诊断方法
实现交接文档足够具体，可用于编码
实验交接文档足够具体，可供
```
experiment-design-planner
```
使用
论文-method衔接部分未超出已规划证据的范围提出主张
若存在项目记忆，已完成更新