algorithm-design-planner

アルゴリズム設計プランナー

検証済みの研究アイデアを、実装、アブレーション、評価、論文での説明が可能な具体的な手法設計に落とし込みます。

次の場合にこのスキルを使用します。

• アイデアが初期検証を通過し、実際のアルゴリズムが必要な場合
• 手法、損失、アーキテクチャ、推論手順、または学習レシピの詳細が不足している場合
• ユーザーがコーディングの前に手法設計ドキュメントを必要としている場合
• プロジェクトで、前提条件、失敗モード、アブレーション、実装範囲を定める必要がある場合
• 初期結果から、実験を再実行するだけでなく、アルゴリズムの改訂が必要だと示唆される場合
• 手法自体が明確でないため、論文の手法セクションを書くのが難しい場合

実験を開始するためにこのスキルを使用しないでください。設計が検証できるほど具体的になったら、experiment-design-planner と組み合わせてください。

このスキルは以下と組み合わせてください。

• 設計によって主張、前提条件、リスク、アクション、またはワークツリーの目的が変わる場合は、research-project-memory
• アイデア自体に取り組む価値があるか不明な場合は、このスキルの前に research-idea-validator
• 最も近い先行手法が不明な場合は、literature-review-sprint
• 手法から検証可能な仮説とアブレーションが得られた後は、experiment-design-planner
• 実装と実験設計の準備が整った後に限り、run-experiment
• 最終的な設計を論文の文章に落とし込む場合は、conference-writing-adapter

スキルディレクトリの構成

<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

段階的な読み込み

• 必ず references/design-rubric.md と references/method-spec-template.md を読みます。
• 前提条件、エッジケース、または否定的な結果が重要な場合は、references/failure-mode-map.md を読みます。
• 手法にコンポーネント、損失、目的関数、スケジュール、アーキテクチャ、または推論の変更が含まれる場合は、references/ablation-implications.md を読みます。
• コーディングタスクやワークツリー計画を作成する前に、references/implementation-handoff.md を読みます。
• 設計を手法セクションにする必要がある場合は、references/paper-method-bridge.md を読みます。
• 新規性が現在の手法やベースラインに左右される場合は、ウェブ検索またはユーザー提供の論文で検証します。

基本原則

• 実験を設計する前に、メカニズムを設計します。
• 問題、手法、主張、エビデンス計画を切り分けます。
• 中核となるアイデアを検証できる、最小限の手法を設計します。
• 前提条件と不変条件を明示します。
• 最も近いベースラインと比べて、真に新しい点を特定します。
• すべての手法コンポーネントに、その理由、アブレーション、失敗モードを定めます。
• 正当化、公平な調整、または査読者への説明ができない調整項目を追加しないようにします。
• コーディング中に設計上の判断が暗黙に行われないよう、実装への引き継ぎを作成します。

ステップ 1 - コンテキストの把握

以下を収集します。

• 検証済みのアイデアまたはプロジェクトの方向性
• 利用可能な場合は、research-idea-validator による現在の判断
• 論文で主張する内容
• 対象モデル、タスク、または領域
• 最も近いベースラインまたは先行手法
• 利用可能なコードベースと実装上の制約
• 既知の実験または否定的な結果
• 存在する場合は、CLM-###、RSK-###、ACT-### などのプロジェクトメモリー ID

アイデアがまだ曖昧な場合は、次の形式に書き換えます。

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

この文を書けない場合は、research-idea-validator または literature-review-sprint に戻します。

ステップ 2 - 設計モードの選択

設計を次のように分類します。

• method：新しいアルゴリズム、学習レシピ、または推論手順
• objective：新しい損失、正則化項、制約、報酬、または最適化基準
• architecture：新しいモジュール、表現、レイヤー、ルーティング、メモリー、またはパラメーター化
• theory：前提条件、定理、境界、または原理から導かれる形式的な手法
• system：パイプライン、インフラストラクチャ、スケジューリング、検索、データ、またはツール設計
• revision：否定的または曖昧な結果を受けた手法の更新

主モードを 1 つ選び、必要に応じて副モードを追加します。

Step 3 - メソッド仕様を作成する

references/design-rubric.md と references/method-spec-template.md を読みます。

以下を定義します。

• 問題の定式化
• 入力と出力
• 変更対象となるベースライン
• 中核となるメカニズム
• 該当する場合は、学習目的または損失関数
• 該当する場合は、推論またはサンプリングの手順
• 該当する場合は、アーキテクチャまたはモジュールの変更
• 前提と不変条件
• ハイパーパラメーターとスケジュール
• 計算コスト
• 期待される動作
• ベースラインから変更されない点

必要に応じて、数式、擬似コード、または構造化された箇条書きを使います。重要な設計上の決定を文章に埋もれさせないでください。

Step 4 - 新規性と最小性を確認する

以下を確認します。

• 最も近いベースラインとの本質的な違いは何か？
• 主張に必要な要素はどれか？
• 利便性、エンジニアリング、またはチューニングのための要素はどれか？
• 最初の実装で、より小規模なバージョンを検証できるか？
• 査読者に些細な変更と見なされる可能性はないか？

新しいアイデアが複数の変更に依存する場合は、中核となる設計と任意の拡張を分けます。

Step 5 - 失敗モードを整理する

references/failure-mode-map.md を読みます。

以下を列挙します。

• 誤っている可能性のある前提
• メソッドが失敗するはずのデータまたはタスクの条件
• 最適化または安定性に関するリスク
• メトリクスとの不一致に関するリスク
• 計算上のリスク
• 改善を説明しうる交絡要因
• 設計を修正、一時保留、または中止すべき兆候

望ましくない結果は、曖昧な懸念ではなく、具体的な判断に結び付けます。

Step 6 - アブレーションと診断を導き出す

references/ablation-implications.md を読みます。

各メソッド要素について、以下を定義します。

• その要素が存在する理由
• 取り除いた場合に起きること
• そのメカニズムを検証する診断テスト
• 探索が必要なハイパーパラメーターまたはスケジュール
• メカニズムをチューニングや計算量の影響から切り分けるベースラインまたは対照条件

この出力は experiment-design-planner に直接引き継げるものにします。

Step 7 - 実装への引き継ぎを準備する

references/implementation-handoff.md を読みます。

以下を作成します。

• 変更が見込まれるファイル／モジュール
• 公開インターフェースまたは設定名
• 最小限のプロトタイプ計画
• ユニットテスト／スモークテスト
• ログ要件
• ワークツリーまたはブランチの目的
• 終了条件：マージ、継続、一時保留、または中止
• コーディング時に暗黙のうちに判断してはならないリスク

コードベースが存在しない場合は、完全なエンジニアリング計画ではなく、最小限の足場またはプロトタイプの範囲を定義します。

Step 8 - 論文のメソッド節につなげる

必要に応じて references/paper-method-bridge.md を読みます。

以下を作成します。

• 必要であれば、メソッド名
• メソッド節の構成案
• アルゴリズムボックスに記載する内容
• 必要な方程式または定義
• 明記すべき前提
• メカニズムが機能する理由について、査読者向けの説明
• 根拠が得られるまでは避けるべき主張

Step 9 - 設計ドキュメントを作成する

プロジェクトに保存する際、パスが指定されていなければ、次を使用します。

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

次の構成を使用します。

# 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

Step 10 - プロジェクトメモリに書き戻す

プロジェクトで research-project-memory を使用している場合は、以下を更新します。

• memory/decision-log.md：長期的に保持する設計上の決定とその理由
• memory/claim-board.md：計画、改訂、弱化、または撤回の対象となるメソッドの主張
• memory/risk-board.md：メカニズム、実装、ベースライン、チューニング、計算、評価に関するリスク
• memory/action-board.md：実装、アブレーション、診断、文献、または実験設計に関するアクション
• memory/evidence-board.md：具体化した診断または実験群の計画
• ワークツリーの .agent/worktree-status.md：目的、関連する主張、関連する実験、実装ブランチの終了条件

観測されるまでは、証拠には planned、失敗モードには inferred を使います。

最終確認

仕上げる前に、以下を確認します。

• 問題、ベースライン、メソッドが明確である
• 中核となるメカニズムと任意のエンジニアリング要素を区別できる
• 前提と不変条件が明記されている
• 新しい各要素にアブレーションまたは診断がある
• 実装への引き継ぎが、コーディングに着手できるほど具体的である
• 実験への引き継ぎが、experiment-design-planner で使えるほど具体的である
• 論文のメソッド節への橋渡しが、計画された証拠を超える主張をしていない
• プロジェクトメモリが存在する場合は更新されている