plan

name	plan
description	実装計画を策定してTODO.mdに書き出し、ユーザーの承認を得るまで待機するスキル。 docs/workflow.md のフェーズ1に相当。承認なしに実装を開始しない。
user-invocable	true
model	sonnet

計画スキル（フェーズ1）

/plan <タスク概要> で起動。引数がなければユーザーに確認する。 最終的に指定のフォーマットでTODO.mdを作成する。

トークンは節約しすぎるとTODO.mdの出力を省略してしまうなどの挙動につながる。 Claudeはトークンをある程度潤沢に使い、手順を遵守する。

手順

1. 要件整理

タスクの概要を整理し、以下を明確にする。

• 何を実現するか（目的）
• 影響するファイル・機能・レイヤー
• 考慮すべき制約（認証・バリデーション・既存APIとの整合性など）

必要なら codebase-research スキルを呼び出してコードベースを調査する。

2. テスト計画の策定

以下を必ず実施してからテスト計画をTODO.md へ書き出す。

1. docs/testing.md を Read ツールで参照し、テストサイズ・実装方針を確認する
2. codebase-research スキルで同レイヤーの既存テストファイルを調査し、テストパターン（DB セットアップ・モック方法・ケース構成）を把握する

その上で、TDD の最初のステップで実装するテストを書き出す。 テストで行う処理 or 操作と、期待する結果（UI の状態、データベースなどアプリケーション外部の状態）を定義する。

3. 作業計画の策定

順序ルールに則る。

バックエンド（API・ロジック）の場合：

1. テスト計画に基づくテストコードを実装する
2. テストが通らないことを確認する（Red）。通ってしまう場合はその場で中断して報告する
3. テストを満たす実装を行い、テストが通ることを確認する（Green）
4. テストを通したままリファクタリングを行う（Refactor）

UI（フロントエンド）の場合：

1. テスト計画に基づくテストコードを実装する（E2E テストは Red 確認をスキップしてよい）
2. テストを満たす実装を行う
3. テストが通ることを確認し、通したままリファクタリングを行う

TODO.md の作業ステップはこの順序で記載すること。テストコードの実装を、対応する実装ステップより必ず前に置く。

以下のフォーマットで /Users/naary/repo/risutopo/TODO.md を必ず Write ツールで作成・上書きしてユーザーへ確認を促す。

# TODO: <タスク名>

## 目的
<1〜3行で目的を記述>

## テスト計画

<!-->テーブル形式でテスト計画を記載する<-->

### API

<テスト方法、使用するツールなど>

| テスト対象のファイル | 入力値 | 期待する結果or期待値 |
| --- | --- |
| ~~/~~/XXXXXaction.ts. | 自身のユーザーID、〇〇のデータ | XXXXテーブルにレコードが追加されている |

### UI

<テスト方法、使用するツールなど>

| テストで行う操作 | 期待する結果 |
| --- | --- |
| 例：〇〇をクリックし、メニューから××を選択する | UIが〜のように変わる、△△が表示される |

## 作業ステップ

- [ ] <ステップ1>
- [ ] <ステップ2>
- [ ] ...

## 影響範囲
<変更するファイル・レイヤーの一覧>

## 注意事項
<制約・考慮点があれば記述>

3. ユーザーへの提示と承認待ち

以下の文言で承認を求める。

TODO.md に計画を書き出しました。内容を確認して「承認」または修正指示をお願いします。承認後にフェーズ2（実装）へ進みます。

承認が得られるまで実装（ファイル編集・コード生成）を開始しない。

修正指示が来た場合は TODO.md を更新して再度提示する。

制約

• as による型アサーション禁止（as const は許可）
• ループ内 DB クエリ禁止