plan-feature

機能の計画

機能や複雑な変更について、具体的で実装可能な計画を作成します。

計画中はコードを書かないでください。調査、分析、文書化のみを行います。

計画を立てる基準

詳細な計画に入る前に、まず対象範囲をすばやく確認します。

• 変更が3つ以上のファイル、または複数のシステムに影響する場合は、詳細に計画します
• 要件が不明確な場合、またはアーキテクチャ上のトレードオフがある場合は、詳細に計画します
• 要件が明確な単一ファイルの変更では、重厚な計画は省略します
• 小規模で明白な変更では、完全な仕様の代わりに短い実行概要を提示します

計画のワークフロー

1. 調査

意図を明らかにするため、的を絞った質問をします。質問ごとに次のことを行います。

• トレードオフを含む具体的な選択肢を2～3個提示します
• 明確な理由とともに、推奨する選択肢を示します
• 質問は一度に1つだけ行い、ユーザーの回答を待ちます
• ユーザーがすでに回答した質問は省略します

重要な質問：

• どのような問題を解決しますか？（ユーザーの課題、ビジネス目標）
• どのような動作にすべきですか？（期待する動作、成功基準）
• 何が起きてはいけませんか？（制約、避けるべきエッジケース）
• 誰が利用しますか？（ユーザーの種類、環境、規模）
• 動作の確認方法は何ですか？（テスト方法、検証）

学習速度の参考資料

• 軽量なリリースサイクルとフィードバックの頻度については、ship-fast-loop.mdを使用します。

2. 分析

コードベースを体系的に調査します。

• 関連ファイルを特定します（行番号とともにパスを記録）
• 既存のパターンを整理します（アーキテクチャ、命名、データフロー）
• 依存関係を特定します（変更の影響を受けるもの）
• 一貫性を保つため、類似の実装を探します
• 関連する標準を確認します（implement-frontend、define-architectureなど）

調査結果を記録します。

• ファイル：path/to/file.ts:123 - 役割と関連性
• パターン：類似機能で採用されている既存のアプローチ
• 制約：技術的な制限または要件

3. 計画

具体的で順序立てた計画を、次の内容で作成します。

変更ごとに、次の内容を指定します。

• ファイルパスとおおよその行番号
• 変更する関数、コンポーネント、クラスを明記
• 追加、削除、変更する内容を具体的に記載
• この変更を行う理由（目標にどう結び付くか）
• 依存関係（先に行う必要があること）

計画の構成：

## Goal
[One sentence: what we're building and why]

## Changes

### 1. [Description]
- File: `path/to/file.ts:45`
- Action: Add `functionName()` that does X
- Reasoning: Needed because Y
- Dependencies: None

### 2. [Description]
- File: `path/to/other.ts:89`
- Action: Modify `existingFunction()` to handle Z
- Reasoning: Integrates with change #1
- Dependencies: #1 must complete first

## Validation
- [ ] Tests pass
- [ ] Feature works for case A
- [ ] Edge case B is handled
- [ ] Follows `implement-frontend` (if frontend)
- [ ] No console logs or debug code

4. 標準の参照

適用する標準を明記します。

• フロントエンドの変更：implement-frontend、audit-uiを参照
• UIの変更：design-uiを参照
• モーション：ui-animationを参照
• バックエンド：define-architectureを参照
• タイポグラフィ：audit-uiを参照

形式：「この計画では、フォームと型安全性についてimplement-frontendに従う必要があります。」

アンチパターン

曖昧な計画を避けます。

• 悪い例：「認証システムを更新する」
• 良い例：「auth/middleware.ts:34を変更し、トークンの有効期限を確認するvalidateSession()を追加する」

前提情報の不足を避けます。

• 悪い例：「エラーハンドリングを追加する」
• 良い例：「auth/api.ts:67のAPI呼び出しをtry/catchで囲み、エラー時にaudit-uiに従ってトーストを表示する」

知識があると決めつけないようにします。

• 悪い例：「標準的なパターンを使う」
• 良い例：「user/dao.ts:12にある既存のDAOパターン（明示的な型を使うクラスベースの実装）に従う」

受け入れ基準の不足を避けます。

• 悪い例：「動作することを確認する」
• 良い例：「次の点を確認する：（1）Enterキーでフォームが送信される、（2）インラインエラーが表示される、（3）リクエスト中は送信が無効になる」

標準を無視しないようにします。

• 悪い例：any型と手動のフォーム状態管理を使う計画
• 良い例：implement-frontendを徹底する計画：anyを使わず、React Hook Formを使用する

検証チェックリスト

計画を引き渡す前に、次の点を確認します。

• 誰かが質問せずに実装できる
• ファイルパスが正しく、おおよその行番号が記載されている
• 手順が依存関係を明確にして順序立てられている
• 受け入れ基準をテストできる
• 関連するスキルの標準が明示的に参照されている
• すべての判断に理由がある
• 曖昧な表現（具体性を伴わない「更新」「改善」「強化」）がない