writing-plans

計画の作成

概要

コードベースの知識がまったくなく、好みも疑わしいエンジニアを想定して、包括的な実装計画を作成します。タスクごとに変更するファイル、コード、テスト、確認が必要なドキュメント、テスト方法など、必要な情報をすべて記載します。計画全体を、取り組みやすい小さなタスクに分割します。DRY。YAGNI。TDD。こまめにコミットします。

熟練した開発者ではあるものの、使用するツールセットや問題領域についてはほとんど知らず、適切なテスト設計にもあまり詳しくないと想定してください。

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

コンテキスト： プロジェクトで既に使われている計画の保存場所とワークフローを使用します。コードを分離する必要がある場合は、専用のワークツリーが便利です。ただし、計画の作成に利用できないブレインストーミングスキルは必要なく、実装の許可にもなりません。

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

取り組みやすいタスクの粒度

各ステップは1つのアクション（2〜5分）です：

• 「失敗するテストを書く」- ステップ
• 「実行して失敗することを確認する」- ステップ
• 「テストを通すための最小限のコードを実装する」- ステップ
• 「テストを実行して成功することを確認する」- ステップ
• 「コミットする」- ステップ

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

すべての計画は、必ず次のヘッダーから始めてください：

# [Feature Name] Implementation Plan

> **Execution:** Follow this plan task-by-task within the user-authorized scope. If the installed environment provides an executing-plans skill, read it before use; this catalog entry does not bundle that dependency.

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

**Architecture:** [2-3 sentences about 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 it fails**

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"
```

外側のタスク構成テンプレートは、内側のコードブロックをそのまま含めて Markdown としてコピーしてください。コマンドと期待される出力は、計画された確認項目であり、実際に確認が実行された証拠ではありません。ファイルパスとツールの利用可否は、実際のリポジトリで確認してください。振る舞いとして意味のある単位やリポジトリの方針に合わせて、テストやコミットの粒度を調整し、編集のたびに機械的にテストやコミットを追加しないでください。

忘れずに

• ファイルパスを常に正確に記載する
• 計画内にコードをすべて記載する（「バリデーションを追加する」だけにしない）
• 期待される出力を含む、正確なコマンドを記載する
• 関連するスキルを @ 構文で参照する
• DRY、YAGNI、TDD、こまめなコミット

実行への引き継ぎ

計画を保存した後、実行方法を選べるようにします：

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

1. サブエージェント駆動（このセッション） - タスクごとに新しいサブエージェントを起動し、タスク間でレビューしながら迅速に進めます

2. 並行セッション（別セッション） - 新しいセッションを開き、executing-plans を使ってチェックポイントを設けながらまとめて実行します

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

サブエージェント駆動を選んだ場合：

• インストール済みのサブエージェント駆動開発手順があればそれを使用します。なければ、その依存関係が同梱されていると主張せず、利用できる実行ワークフローを説明します。
• このセッションを続けます
• タスクごとに新しいサブエージェントを使い、コードレビューを行います

並行セッションを選んだ場合：

• ワークツリーで新しいセッションを開くよう案内します
• インストール済みの executing-plans 手順があればそれを使用します。なければ、保存した計画とプロジェクトの指示を新しいセッションに引き継ぎます。

使用する場面

このスキルは、概要に記載されたワークフローやアクションを実行する場合に適用できます。

制限事項

• タスクが明らかに記載された範囲に該当する場合にのみ、このスキルを使用してください。
• 出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、成功基準が不足している場合は、作業を中断して確認を求めてください。