計画とタスク分割

概要

仕事を小さく、検証可能なタスクに分解し、明示的なアクセプタンス基準を付与します。良好なタスク分割は、エージェントが確実に仕事を完了できるか、ぐちゃぐちゃな結果を生成するかの違いを生みます。すべてのタスクは、単一の集中したセッション内で実装、テスト、検証できるほど小さくする必要があります。

使用する場合

• 仕様があり、実装可能な単位に分割する必要がある場合
• タスクが大きすぎるまたは曖昧で始められない場合
• 複数のエージェントまたはセッション全体で仕事を並列化する必要がある場合
• スコープを人間に伝える必要がある場合
• 実装の順序が明確でない場合

使用しない場合: 単一ファイルの明確なスコープの変更、または仕様に既に明確に定義されたタスクが含まれている場合。

計画プロセス

ステップ 1: 計画モードに入る

コードを書く前に、読み取り専用モードで操作します：

• 仕様と関連するコードベース部分を読む
• 既存のパターンと慣例を特定する
• コンポーネント間の依存関係をマッピングする
• リスクと未知の項目を記録する

計画中はコードを書かないでください。 出力は計画ドキュメントであり、実装ではありません。

ステップ 2: 依存関係グラフを特定する

何が何に依存しているかをマッピングします：

データベーススキーマ
    │
    ├── API モデル/型
    │       │
    │       ├── API エンドポイント
    │       │       │
    │       │       └── フロントエンド API クライアント
    │       │               │
    │       │               └── UI コンポーネント
    │       │
    │       └── バリデーションロジック
    │
    └── シードデータ / マイグレーション

実装順序は依存関係グラフに従い、ボトムアップに実行します：最初に基盤を構築します。

ステップ 3: 垂直にスライスする

すべてのデータベース、次にすべての API、次にすべての UI を構築するのではなく、一度に 1 つの完全な機能パスを構築します：

悪い例（水平スライシング）：

タスク 1: データベーススキーマ全体を構築
タスク 2: すべての API エンドポイントを構築
タスク 3: すべての UI コンポーネントを構築
タスク 4: すべてを接続

良い例（垂直スライシング）：

タスク 1: ユーザーがアカウントを作成できる（登録のスキーマ + API + UI）
タスク 2: ユーザーがログインできる（認証スキーマ + API + UI）
タスク 3: ユーザーがタスクを作成できる（タスクスキーマ + API + UI）
タスク 4: ユーザーがタスクリストを表示できる（クエリ + API + UI）

各垂直スライスは、動作可能でテスト可能な機能を提供します。

ステップ 4: タスクを記述する

各タスクは以下の構造に従います：

## タスク [N]: [簡潔な説明的タイトル]

**説明:** このタスクが何を達成するかを説明する 1 段落。

**アクセプタンス基準:**
- [ ] [具体的でテスト可能な条件]
- [ ] [具体的でテスト可能な条件]

**検証:**
- [ ] テストが合格する: `npm test -- --grep "feature-name"`
- [ ] ビルドが成功する: `npm run build`
- [ ] 手動チェック: [検証対象の説明]

**依存関係:** [このタスクが依存するタスク番号、または「なし」]

**編集対象のファイル（予想）:**
- `src/path/to/file.ts`
- `tests/path/to/test.ts`

**推定スコープ:** [小：1-2 ファイル | 中：3-5 ファイル | 大：5+ ファイル]

ステップ 5: 順序付けとチェックポイント

タスクを以下のように配置します：

1. 依存関係が満たされている（最初に基盤を構築）
2. 各タスクはシステムを動作状態のままにする
3. すべての 2～3 タスク後に検証チェックポイントが発生する
4. 高リスクのタスクが早い（早期に失敗）

明示的なチェックポイントを追加します：

## チェックポイント: タスク 1-3 後
- [ ] すべてのテストが合格
- [ ] アプリケーションがエラーなくビルドできる
- [ ] コアのユーザーフローがエンドツーエンドで動作する
- [ ] 続行する前に人間とレビューする

タスクサイズのガイドライン

サイズ	ファイル	スコープ	例
XS	1	単一の関数または構成変更	バリデーションルールを追加
S	1-2	1 つのコンポーネントまたはエンドポイント	新しい API エンドポイントを追加
M	3-5	1 つの機能スライス	ユーザー登録フロー
L	5-8	マルチコンポーネント機能	フィルタリングとページネーション付き検索
XL	8+	大きすぎます — さらに分割する必要があります	—

タスクが L 以上の場合は、より小さいタスクに分割する必要があります。エージェントは S および M タスクで最高のパフォーマンスを発揮します。

タスクをさらに分割する場合：

• 1 つの集中したセッション以上かかる場合（エージェント作業のおよそ 2+ 時間）
• アクセプタンス基準を 3 個以下の箇条書きで説明できない場合
• 2 つ以上の独立したサブシステムに影響を与える場合（例：認証と請求）
• タスクタイトルに「および」を書いている場合（2 つのタスクの兆候）

計画ドキュメントテンプレート

# 実装計画: [機能/プロジェクト名]

## 概要
[構築対象の 1 段落の概要]

## アーキテクチャの決定
- [重要な決定 1 と根拠]
- [重要な決定 2 と根拠]

## タスクリスト

### フェーズ 1: 基盤
- [ ] タスク 1: ...
- [ ] タスク 2: ...

### チェックポイント: 基盤
- [ ] テストが合格し、クリーンにビルドする

### フェーズ 2: コア機能
- [ ] タスク 3: ...
- [ ] タスク 4: ...

### チェックポイント: コア機能
- [ ] エンドツーエンドフローが動作する

### フェーズ 3: ポーランド
- [ ] タスク 5: ...
- [ ] タスク 6: ...

### チェックポイント: 完了
- [ ] すべてのアクセプタンス基準を満たす
- [ ] レビューの準備ができている

## リスクと緩和策
| リスク | 影響 | 緩和策 |
|---|---|---|
| [リスク] | [高/中/低] | [戦略] |

## 未解決の質問
- [人間の入力が必要な質問]

並列化の機会

複数のエージェントまたはセッションが利用可能な場合：

• 並列化して安全: 独立した機能スライス、既に実装された機能のテスト、ドキュメント
• 順序が必須: データベースマイグレーション、共有状態の変更、依存チェーン
• 調整が必要: API コントラクトを共有する機能（最初にコントラクトを定義し、次に並列化）

一般的な言い訳

言い訳	現実
「進みながら理解する」	それがぐちゃぐちゃな結果とやり直しになります。10 分の計画で数時間節約できます。
「タスクは明白だ」	とにかく書き出してください。明示的なタスクは、隠れた依存関係と忘れたエッジケースを明らかにします。
「計画はオーバーヘッド」	計画はタスクです。計画なしの実装は単なるタイピングです。
「すべて頭に入っている」	コンテキストウィンドウは有限です。書かれた計画はセッション境界と圧縮を超えて生存します。

危険信号

• 書かれたタスクリストなしで実装を開始する
• アクセプタンス基準なしに「機能を実装する」と書かれたタスク
• 計画に検証ステップがない
• すべてのタスクが XL サイズ
• タスク間にチェックポイントがない
• 依存関係の順序が考慮されていない

検証

実装を開始する前に、確認してください：

• すべてのタスクにアクセプタンス基準がある
• すべてのタスクに検証ステップがある
• タスク依存関係が特定され、正しく順序付けられている
• タスクが約 5 ファイル以下に接触する
• チェックポイントが主要フェーズ間に存在する
• 人間が計画をレビューして承認している