task-planning

タスク計画

概要

コードベースにまったく詳しくなく、設計の判断に自信がないエンジニア向けに、綿密な実装計画を作成します。すべてを明確に記述してください。タスクごとに変更するファイル、正確なコード、テスト手順、関連ドキュメント、各手順の検証方法を示します。細かく、単独で内容が完結したタスクに分割して計画を提示します。DRY。YAGNI。TDD。こまめにコミットします。

エンジニアは技術的な能力がある一方で、プロジェクトのツールや問題領域についてほとんど知らないものとします。テスト設計のスキルも低いものと想定してください。

最初に宣言します：「タスク計画スキルを適用して、実装計画を作成します。」

コンテキスト： 専用のワークツリー（意図発見フェーズで作成）で作業します。

計画の保存先： docs/plans/YYYY-MM-DD-<feature-name>.md

最優先の原則

NO IMPLEMENTATION WITHOUT A PLAN FIRST

例外はありません。回避策も、近道もありません。

使用する場面

必須：

• 複数ステップにわたる機能（複数のファイルまたは動作に変更を加えるもの）
• 複数のコンポーネントにまたがるバグ修正
• モジュール境界をまたぐリファクタリング
• 複数ファイルにわたってテスト、コード、コミットを連携させる必要があるタスク
• 意図発見セッションで仕様または設計が作成された場合

不要：

• 範囲が明確な1行の修正（誤字、設定値）
• 既存コードに対する単一テストの追加
• ドキュメントのみの変更
• 1つのファイルにおける変数名の変更

「これは計画を立てるほど複雑ではない」と考えたくなりますか？複数のファイルに触れるなら、計画を作成してください。

開始時の手順

計画を書く前に、次のすべてを確認してください。

1. 設計が承認されている - 意図発見セッションまたは人間のパートナーがアプローチを確認している
2. 範囲が定義されている - 変更するすべてのコンポーネントを列挙できる
3. 要件が具体的である - 「完了」の条件（感覚ではなく、受け入れ基準）がわかっている
4. 技術スタックが特定されている - 使用する言語、フレームワーク、ライブラリがわかっている
5. テスト戦略が定義されている - 各要素の検証方法がわかっている
6. ワークツリーが有効になっている - main ではなく、独立したブランチで作業している

不明な項目がありますか？ 作業を中断してください。意図発見に戻るか、人間のパートナーに相談します。抜け漏れのある計画を書いてはいけません。抜け漏れは欠陥につながります。

認知上の落とし穴

合理化	実際のところ
「計画を立てるほど複雑ではない」	単純なタスクにも隠れた複雑さがあります。計画には5分かかります。デバッグには何時間もかかります。
「進めながら考えればいい」	それは場当たり的な実装です。エッジケースを見落とし、検証手順を飛ばすことになります。
「仕様書がそのまま計画になる」	仕様書が説明するのは「何をするか」です。計画が説明するのは、ファイルパスやコマンドを含めた「どのように進めるか」です。
「何をすべきかはもうわかっている」	それは素晴らしいことです。書き留めてください。明白なら、計画は2分で作成できます。
「計画を立てると遅くなる」	手戻りが遅れの原因になります。計画は手戻りを防ぎます。毎回、結果として時間を節約できます。
「実装後に計画を追加する」	実装後に書いた計画は、計画ではなくドキュメントです。すでに起きたミスは防げません。

ガードレール

決して行わないこと：

• 「機能を実装する」「バリデーションを追加する」のような曖昧な手順を書くこと。正確なコードを指定してください。
• 計画の手順からテストコマンドや期待される出力を省くこと
• ファイルパスを記載しないこと。すべての手順で正確なパスを示してください。
• 計画を保存してレビューする前に実装を始めること

常に行うこと：

• コードの説明ではなく、完全なコードスニペットを含めること
• 各検証手順について、正確なシェルコマンドと期待される出力を指定すること
• 作成、変更、削除するすべてのファイルを列挙すること
• 各タスクの最後に、正確なコミットメッセージを含むコミット手順を記載すること

タスクの粒度

各ステップは1つのアクション（2〜5分）とします。

• 「失敗するテストを書く」— ステップ
• 「実行して失敗を確認する」— ステップ
• 「最小限のコードを実装して合格させる」— ステップ
• 「テストを実行して合格を確認する」— ステップ
• 「コミットする」— ステップ

計画ドキュメントのヘッダー

すべての計画は、必ず次のヘッダーから始めます。

# [Feature Name] Implementation Plan

> **For Claude:** REQUIRED SUB-SKILL: Use godmode:task-runner to implement this plan task-by-task.

**Goal:** [One sentence describing what this builds]

**Architecture:** [2-3 sentences about the approach]

**Tech Stack:** [Key technologies/libraries]

---

タスクテンプレート

### Task N: [Component Name]

**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`

**Step 1: Write the failing test**

```python
def test_specific_behavior():
    result = function(input)
    assert result == expected
```

**Step 2: Run test to verify failure**

Run: `pytest tests/path/test.py::test_name -v`
Expected: FAIL with "function not defined"

**Step 3: Write minimal implementation**

```python
def function(input):
    return expected
```

**Step 4: Run test to verify it passes**

Run: `pytest tests/path/test.py::test_name -v`
Expected: PASS

**Step 5: Commit**

```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```

リマインダー

• すべての手順で正確なファイルパスを記載します
• 計画には完全なコードを記載します（「バリデーションを追加」などとはしません）
• 期待される出力を含む正確なコマンドを記載します
• 関連するスキルを名前で参照します（例：godmode:test-first）
• DRY、YAGNI、TDD、こまめなコミットを徹底します

実行の引き継ぎ

計画を保存した後、ユーザーに選択肢を提示します。

「計画が完成し、docs/plans/<filename>.md に保存されました。実行方法は2つあります。

1. 委任実行（このセッション） - タスクごとに新しいサブエージェントを起動し、タスク間でレビューしながら、素早く反復します

2. 別のセッション - task-runner を使って新しいセッションを開き、チェックポイントを設けながら一括実行します

どちらの方法にしますか？」

委任実行を選択した場合：

• 必須のサブスキル： godmode:delegated-execution を使用します
• このセッションを続けます
• タスクごとに新しいサブエージェントを起動し、コードレビューを行います

別のセッションを選択した場合：

• worktree で新しいセッションを開くよう案内します
• 必須のサブスキル： 新しいセッションでは godmode:task-runner を使用します

関連スキル

必須のワークフロースキル：

• godmode:intent-discovery - このスキルに渡す仕様／設計を作成します
• godmode:workspace-isolation - 必須：計画の前に隔離されたワークスペースをセットアップします
• godmode:task-runner - このスキルが作成した計画を実行します
• godmode:delegated-execution - 同じセッション内でサブエージェントを使って実行する代替方法です
• godmode:test-first - 計画内のすべてのタスクで TDD サイクルに従います
• godmode:merge-protocol - 計画の実行後に開発を完了します

計画の作成ワークフロー

digraph plan_construction {
    rankdir=TB;
    node [shape=box, style=filled, fontname="Helvetica"];

    start [label="Task received", shape=ellipse, fillcolor="#e0e0e0"];
    check_scope [label="Multi-step?\nMultiple files?", shape=diamond, fillcolor="#ffffcc"];
    no_plan [label="No plan needed\nJust do it", fillcolor="#ccffcc"];
    gate [label="Entry Protocol\nAll 6 items verified?", shape=diamond, fillcolor="#ffffcc"];
    go_back [label="Return to\nintent-discovery\nor ask human", fillcolor="#ffcccc"];
    write_header [label="Write plan header\nGoal / Architecture / Stack", fillcolor="#cce5ff"];
    write_tasks [label="Write granular tasks\nFiles / Test / Implement / Verify / Commit", fillcolor="#cce5ff"];
    review [label="Review plan\nAll paths exact?\nAll code complete?", shape=diamond, fillcolor="#ffffcc"];
    fix_plan [label="Fill gaps\nin plan", fillcolor="#ffcccc"];
    save [label="Save to\ndocs/plans/", fillcolor="#ccffcc"];
    handoff [label="Offer execution\nchoice to human", fillcolor="#ccffcc"];

    start -> check_scope;
    check_scope -> no_plan [label="no"];
    check_scope -> gate [label="yes"];
    gate -> go_back [label="gaps"];
    gate -> write_header [label="all verified"];
    go_back -> gate [label="resolved"];
    write_header -> write_tasks;
    write_tasks -> review;
    review -> fix_plan [label="gaps found"];
    fix_plan -> review;
    review -> save [label="complete"];
    save -> handoff;
}