構造化計画

検証駆動型タスク分解と Sibyl ネイティブな追跡。200 件以上の実際の計画セッションから抽出：実際にコード接触戦で生き残った計画。

コアの洞察： ステップが検証できない場合、計画は失敗します。具体的なチェックに落とし込める分解は現実との接触を生き残ります。抽象的な箇条書きはそうではありません。Sibyl での追跡により、計画は生成した context ウィンドウより長く生きるようになります。

このスキルの読み方： 以下のフェーズは、有用な計画パスのリズムを説明しており、実行すべき手順ではありません。小さく明確な作業は計画をスキップし、答えが明白な場合はフェーズを圧縮し、最初の計画を仮説として扱いましょう。再計画は例外ではなく原則です。

全体像

digraph planning {
    rankdir=TB;
    node [shape=box];

    "1. SCOPE" [style=filled, fillcolor="#e8e8ff"];
    "2. EXPLORE" [style=filled, fillcolor="#ffe8e8"];
    "3. DECOMPOSE" [style=filled, fillcolor="#e8ffe8"];
    "4. VERIFY & APPROVE" [style=filled, fillcolor="#fff8e0"];
    "5. TRACK" [style=filled, fillcolor="#e8e8ff"];

    "1. SCOPE" -> "2. EXPLORE";
    "2. EXPLORE" -> "3. DECOMPOSE";
    "3. DECOMPOSE" -> "4. VERIFY & APPROVE";
    "4. VERIFY & APPROVE" -> "5. TRACK";
    "4. VERIFY & APPROVE" -> "3. DECOMPOSE" [label="gaps found", style=dashed];
}

---

フェーズ 1: SCOPE

分解する前に作業の範囲を確定します。目標は計画の深さを実際のスコープに調整することであり、成果物を生成することではありません。

よくある動き

• Sibyl で検索して関連タスク、決定事項、以前の計画を見つける：sibyl search "<feature keywords>"、sibyl task list -s todo。安価であり、既に分解された先行例が浮かび上がることが多い。

• 成功基準を測定可能な用語で定義する（「テストが成功」、「エンドポイントが X を返す」、「p95 レイテンシ < 200ms」）。「パフォーマンスを改善」のような曖昧な目標の代わりに。

• 制約を特定する：変更してはいけないファイル、尊重すべき依存関係、時間またはバジェットの圧力。

• 計画の深さをスコープに調整する：

  スケール	説明	計画の深さ
  クイックフィックス	3 ファイル未満、明確な解決策	計画をスキップして構築を開始
  フィーチャー	3～10 ファイル、既知のパターン	ライトプラン（このスキル）
  エピック	10 ファイル以上、新しいパターン	完全な計画 + オーケストレーション
  リデザイン	アーキテクチャの変更	完全な計画 + 事前研究

作業がクイックフィックスの場合、計画をやめて構築を開始します。5 分で完了する変更を計画することは純粋なオーバーヘッドです。

---

フェーズ 2: EXPLORE

分解する前にコードベースの表面を理解します。ファイル名だけから構築された計画は、実際のコードとの接触で崩壊します。

よくある動き

• 影響範囲をマップする：どのファイルとモジュールがこれに影響するか？名前から推測するのではなく、実際のコードを読みます。スコープが本当に不確定な場合は Explore エージェントを起動します。
• 既存のパターンを特定する：類似の機能はどのように既に機能しているか？どの規約が適用されるか（命名、ファイル構造、テストパターン）？
• 依存関係をたどる：これが機能する前に何が存在する必要があるか、X を変更したら何が壊れるか？

あなたの目標は、表現できるメンタルモデルです：「これはモジュール A（新しいエンドポイント）、モジュール B（型の変更）、モジュール C（テスト）に触れます。パターンは既存フィーチャー X に従います。インフラストラクチャ Y の可用性に依存します。」 その文が書けない場合、分解は推測に基づきます。

---

フェーズ 3: DECOMPOSE

実際に検証できるステップに作業を分割します。計画が生き残る計画と失敗する計画を分ける規律は、各ステップを具体的なチェックに接続することです。

検証ヒューリスティック

検証メソッドのないステップは希望であり、ステップではありません。分解されたと見なす前に、すべてのタスクを具体的なチェックに向けて押し出します。各タスクに対して、有用なフィールドは以下です：

フィールド	説明
What	具体的な実装アクション
Files	作成/変更する正確なファイル
Verify	それが機能することを確認する方法
Depends on	最初に完了する必要があるタスク

検証メソッド

メソッド	使用するタイミング
typecheck	型の変更、インターフェースの追加
test	ロジック、エッジケース、統合
lint	スタイル、フォーマット、インポート順序
build	ビルドシステム変更
visual	UI 変更（スクリーンショットまたはブラウザチェック）
curl/httpie	API エンドポイント変更
manual	自動化が存在しない場合のみ

分解ヒューリスティック

• 2～5 分のタスクがスイートスポットになる傾向があります。15 分以上実行するタスクは通常、分割する価値があります。
• 1 つの関心事ごとに 1 タスク。 「エンドポイントを追加してテストも書く」は 2 つのタスクです。タスクタイトルの接続詞を分割ヒントとして扱います。
• 難度ではなく依存関係順に並べます。 基盤が最初で、後のタスクはそれ以前のものに基づきます。
• 並列実行可能なタスクをマークします。 共有ファイルのないタスクは同時に実行できます。これはオーケストレーションに引き継ぐ際に重要です。

タスク形式

## Task [N]: [命令形のタイトル]

**Files:** `src/path/file.ts`, `tests/path/file.test.ts`
**Depends on:** Task [M]
**Parallel:** Yes/No (Task [X] と同時に実行可能)

### Implementation

[実装内容の 2～4 個の箇条書き]

### Verify

- [ ] `pnpm typecheck` が通る
- [ ] `pnpm test -- file.test.ts` が通る
- [ ] [動作に関する具体的なアサーション]

並列実行可能性マーカー

オーケストレーション用に同時に実行できるタスクをマークします：

Wave 1 (基盤):      Task 1, Task 2  [並列]
Wave 2 (コア):      Task 3, Task 4  [並列、Wave 1 に依存]
Wave 3 (統合):      Task 5          [順序、Wave 2 に依存]
Wave 4 (ポーランド): Task 6, Task 7  [並列、Wave 3 に依存]

---

フェーズ 4: VERIFY & APPROVE

計画を提示する前にサニティチェックを実行します。目標は儀式ではなく、計画をチャーンに変える明白な失敗モードをキャッチすることです。

提示前に確認する価値のあることは

• すべてのタスクが検証メソッドを持つ（最も一般的なギャップ）
• 依存関係が DAG を形成し、サイクルがない
• 並列実行するタスク 2 つが同じファイルに触れていない
• 全体的なスコープが依然として フェーズ 1 の成功基準に一致する
• 実際にはまだ必要ではないものが忍び込んでいない（YAGNI）

承認のために提示

構造化リストとウェーブとして計画を表示します：

## Plan: [フィーチャー名]

**Success criteria:** [測定可能な成果]
**推定タスク:** [N] 個、[M] ウェーブ
**Parallelizable:** [X]% のタスクが並列実行可能

### Wave 1: Foundation

- [ ] Task 1: [タイトル] → verify: [メソッド]
- [ ] Task 2: [タイトル] → verify: [メソッド]

### Wave 2: Core Implementation

- [ ] Task 3: [タイトル] → verify: [メソッド] (depends: 1)
- [ ] Task 4: [タイトル] → verify: [メソッド] (depends: 2)

### Wave 3: Integration

- [ ] Task 5: [タイトル] → verify: [メソッド] (depends: 3, 4)

ギャップ分析

計画がページに出たら、何か不足しているか、タスクをさらに結合または分割すべきか、成功基準が依然として正しく感じるかを問い、ます。ユーザーはあなたが持っていない文脈を保有しているので、あなたが見つけられないギャップをしばしば見つけます。

---

フェーズ 5: TRACK

計画を Sibyl に登録して、それを生成した context ウィンドウより長く生き残らせます。非常に小さな計画でシングルセッション内で完了する場合はスキップしても構いませんが、数日またはセッションにわたるすべてのものは耐久的な追跡から利益を得ます。

sibyl task create --title "[フィーチャー]" -d "[成功基準]" --complexity epic
sibyl task create --title "Task 1: [タイトル]" -e [epic-id] -d "[実装 + 検証]"
sibyl add "Plan: [フィーチャー]" "[N] タスク、[M] ウェーブ。主要な決定：[アーキテクチャの選択]。依存関係：[クリティカルパス]。"

適応的な再計画

計画は現実に出会い、現実は通常勝ちます。タスクが予期しない複雑さを浮かび上がらせたら、一時停止して再評価します。強制的に進まないようにします。タスクリストを調整し、Sibyl を更新し、変更を表面化します：「タスク 3 が X を明らかにし、計画を調整します：[変更]。」 再計画はワークフロー内の機能であり、元の計画が悪かったことの証拠ではありません。

---

実行ハンドオフ

計画が承認されたら、適切なツールに引き継ぎます：

状況	ハンドオフ
3～5 個の単純なタスク、ユーザーが存在	検証ゲートで直接実行
5～15 個のタスク、混合並列	/hyperskills:orchestrate とウェーブ戦略
大規模エピック、15 個以上のタスク	エピック並列ビルド戦略でオーケストレート
さらに研究が必要	実行前に /hyperskills:research

実行のための信頼勾配

すべてのタスクで大量のレビューはノイズを蓄積します。ゼロレビューはリスクを蓄積します。早期に大量のレビューに傾き、パターンが安定したら軽いレビューに傾きます：

フェーズ	レビュー レベル	通常
Full ceremony	Implement + spec review + cross-model-review	最初の 3～4 タスク
Standard	Implement + spec review	タスク 5～8、パターン安定化
Light	Implement + quick verify	後期タスク、確立されたパターン

これは獲得した信頼であり、コーナーを切ることではありません。タスクが確立されたパターンから逸脱した場合、勾配はリセットされます。パターンの確立に関係なく、auth、payments、migrations、またはデータ整合性に触れるすべてのものに対して大量のままにしてください。

---

アンチパターン

アンチパターン	修正
5 分で完了するフィックスを計画する	直接構築して検証する
検証なしのタスク	具体的なチェックを追加またはタスクを分割する
同じファイルに触れる並列タスク	それらを順序立てるか、所有権を再分割する
ファイル名だけから計画する	分解する前に実際のコードパスを読む
最初の計画を永続的に扱う	現実が新しい制約を明らかにしたら再計画する

---

このスキルは何ではないか

• 単純なタスクには必要ない。 解決策が明白な場合は、構築するだけです。
• デザインドック生成機ではない。 計画はアクションリストであり、アーキテクチャドキュメントではありません。
• ブロッカーではない。 ユーザーが「構築を開始するだけ」と言う場合は、構築を開始します。並列で計画を立てることができます。
• 厳密ではない。 計画は適応します。最初の計画は仮説です。