name: add-feature description: 新機能の要件定義・設計・タスクリスト作成まで行うコマンド

Add Feature Command

新機能の実装に向けて、対話形式で以下を行うコマンドです:

要件定義: ユーザーとの対話で要件を明確化
技術設計: DB・API・UI の設計を決定
タスクリスト作成: TDD実装のためのタスク一覧を作成

このコマンドは設計まで。実装は /implement-feature で行います。

実行条件

Planモードでは実行不可

このスキルはファイル作成・Git操作を伴うため、Planモードでは実行できません。 Planモード中に実行された場合は、以下のメッセージを表示して終了:

このコマンドはPlanモードでは実行できません。
Planモードを終了してから再度実行してください。

出力ファイル

docs/steering/{YYYYMMDD}-{feature-name}/
├── progress.md       # プロセス進捗（Step 6で作成）
├── requirements.md   # 要件定義（Phase 1で作成）
├── design.md         # 技術設計（Phase 2で作成）
├── tasklist.md       # タスクリスト（Phase 3で作成）
└── reports/          # サブエージェントのレポート
    ├── file-finder.md      # コードベース調査結果（Step 8）
    └── impact-analyzer.md  # 影響範囲分析結果（Step 10）

命名例: docs/steering/20260113-bookmark-feature/

スキップ条件

CLAUDE.md の「実装ワークフロー」セクションに記載の例外条件に従う。

開始前の準備

main ブランチが最新であることを確認:

git checkout main && git pull origin main

Phase 1: 対話的な要件ヒアリング

Step 1: 初期入力の受け取り

ユーザーが自由形式で入力できるように促す:

新機能の実装を始めましょう！

どんな機能を作りたいですか？
自由に教えてください。「〇〇みたいなことがしたい」「△△ができると嬉しい」など、何でもOKです。

Step 2: 初期入力の解釈と確認

ユーザーの回答を受け取ったら:

AIが内容を解釈・整理
理解内容を要約して提示
最初の深掘り質問を行う

ありがとうございます！いくつか確認させてください。

---
### 現時点での理解

**やりたいこと**: {AIが解釈した内容を1-2文で要約}

---

では、詳しく教えてください。

{最初の質問}

Step 3: 一問一答の深掘り

以下のルールで質問を進める:

質問スタイルの使い分け:

技術的な質問 → 選択肢付きで提示
ユーザー体験の質問 → オープン形式

質問例（技術的・選択肢付き）:

**Q. データの保存**
この機能で扱うデータは保存が必要ですか？

A. はい、DBに永続化したい
B. はい、ローカルストレージに一時保存したい
C. いいえ、保存不要（その場限り）
D. まだわからない

質問例（ユーザー体験・オープン）:

**Q. 完了したときの体験**
この機能が完成したら、ユーザーにとって何が嬉しいですか？
今できないことで、できるようになることを教えてください。

質問カテゴリ:

ユースケース理解（誰が、いつ、どんな状況で使うか）
技術的な方向性（データ保存、API、UI配置）
期待値・優先度（何を重視するか）

Step 4: 中間確認（3-4回の質問ごと）

3-4回の質問を行ったら、中間確認を挟む:

---
### ここまでの理解

**機能概要**: {1-2文で要約}

**ユースケース**:
- {ユースケース1}
- {ユースケース2}

**技術的な方向性**:
- データ保存: {選択された方式}
- UI: {想定されるUI}

---

ここまでの理解は合っていますか？修正点があれば教えてください。
問題なければ「OK」と入力してください。

ユーザーが「OK」と回答したら、必要に応じてさらに質問を続ける。

Step 5: 終了判定と仕様確定

以下が明確になったら終了を提案:

解決したい課題
ユーザーが得られる価値
主要なユースケース（1-2個）
技術的な方向性（DB/API/UIの有無）
ゴールと非ゴール

十分な情報が集まりました！

---
### 要件サマリー

**機能名（提案）**: {AIが提案する機能名}

**解決する課題**:
{1-2文}

**期待する結果**:
- ユーザーは〇〇できるようになる
- ユーザーは△△できるようになる

**ゴール**:
- [ ] {ゴール1}
- [ ] {ゴール2}

**非ゴール**:
- {今回は対象外とすること}

**成功指標**:
- {指標1}

---

この内容で仕様を固めてよいですか？
修正したい点があれば教えてください。OKであれば「確定」と入力してください。

Step 6: ステアリングディレクトリの作成

ユーザーが「確定」と回答したら:

日付取得（date +%Y%m%d）、機能名をkebab-caseに変換
docs/steering/{YYYYMMDD}-{feature-name}/ ディレクトリを作成
テンプレートからファイル作成:
- progress.md（テンプレート: .claude/skills/add-feature/templates/progress-template.md）
- requirements.md（テンプレート: .claude/skills/add-feature/templates/requirements-template.md）
対話で得た内容を requirements.md に反映

Step 7: requirements.md のレビュー

requirements.md の内容をユーザーに提示してレビューを依頼:

要件定義ドキュメントを作成しました。

📄 **ファイル**: `docs/steering/{YYYYMMDD}-{feature-name}/requirements.md`

内容を確認してください。修正が必要な場合はお知らせください。
問題なければ「承認」と入力してください。

ユーザーが「承認」と回答したら、技術設計に進む。

Phase 2: 技術設計

Step 8: コードベース調査（file-finder エージェント）

技術設計に入る前に、関連する既存コードを調査します。
**file-finder エージェントを実行します（独立コンテキスト）**

→ file-finder エージェントへの入力:

機能名/キーワード: {Phase1で決まった機能名}
検索範囲: src/app/api/, src/components/, src/hooks/, src/types/
検索目的: 技術設計のための既存コード調査
レポート保存先: docs/steering/{YYYYMMDD}-{feature-name}/reports/file-finder.md

調査結果を reports/file-finder.md に保存し、設計の検討に進む。

Step 9: 技術設計の検討

技術設計を検討しましょう。以下の観点で考えていきます:

1. **データ設計**: 新しいテーブルやカラムは必要ですか？
2. **API設計**: どんなエンドポイントが必要ですか？
3. **UI設計**: どの画面に、どんなUIを追加しますか？

まず、データの保存について考えましょう。この機能で扱うデータは何ですか？

対話を通じて以下を決定:

データベーススキーマ（Prismaモデル）
APIエンドポイント
コンポーネント構成

決定後、design.md を作成（テンプレート: .claude/skills/add-feature/templates/design-template.md）

Step 10: 影響範囲分析（impact-analyzer エージェント）

設計内容をもとに、既存コードへの影響を分析します。
**impact-analyzer エージェントを実行します（独立コンテキスト）**

→ impact-analyzer エージェントへの入力:

変更内容: {技術設計で決まった変更概要}
変更対象ファイル: {新規作成・修正予定のファイルパス}
分析観点: DBスキーマ変更、API変更、型変更など該当する観点
レポート保存先: docs/steering/{YYYYMMDD}-{feature-name}/reports/impact-analyzer.md

分析結果を reports/impact-analyzer.md に保存し、design.md の「7. 影響範囲」「8. リスクと代替案」セクションにも反映。

Step 11: テストケース設計

技術設計に基づいて、テストケースを設計しましょう。

**テスト対象の確認**:
この機能で作成するコンポーネント/関数のうち、テストが必要なものはどれですか？

- [ ] APIルート（バリデーション、認証、レスポンス）
- [ ] カスタムフック（状態管理、副作用）
- [ ] UIコンポーネント（レンダリング、ユーザー操作）
- [ ] ユーティリティ関数（純粋関数）

対話を通じて以下を決定:

テスト対象の優先度（必須 / 推奨 / オプション）
各対象の正常系・異常系テストケース
モックが必要な外部依存

決定後、design.md の「6. テスト戦略」セクションを詳細に記入。

Step 12: design.md のレビュー

design.md の内容をユーザーに提示してレビューを依頼:

技術設計ドキュメントを作成しました。

📄 **ファイル**: `docs/steering/{YYYYMMDD}-{feature-name}/design.md`

内容を確認してください。修正が必要な場合はお知らせください。
問題なければ「承認」と入力してください。

ユーザーが「承認」と回答したら、実装計画に進む。

Phase 3: 実装計画

Step 13: 実装計画の策定

実装計画を策定しましょう。

**機能タイプの確認**:
この機能はどのタイプに該当しますか？

A. **フロントエンドのみ**: UIコンポーネント、モーダル追加
B. **バックエンドのみ**: APIエンドポイント追加・拡張
C. **フルスタック**: DB + API + UI の新機能
D. **複合ページ**: 複数機能を持つページ追加

機能タイプが決まったら、該当するテンプレートで tasklist.md を作成:

A → .claude/skills/add-feature/templates/tasklist-frontend.md
B → .claude/skills/add-feature/templates/tasklist-backend.md
C → .claude/skills/add-feature/templates/tasklist-fullstack.md
D → .claude/skills/add-feature/templates/tasklist-complex.md

Step 14: 最終確認と実装開始案内

すべてのファイルが揃ったら:

設計ドキュメントが完成しました！

📁 **ステアリングディレクトリ**: `docs/steering/{YYYYMMDD}-{feature-name}/`

| ファイル | 内容 |
|----------|------|
| requirements.md | 要件定義（ゴール、成功指標） |
| design.md | 技術設計（API、DB、UI） |
| tasklist.md | タスクリスト |

---

## サマリー

- **機能名**: {機能名}
- **変更ファイル数**: {概算}
- **影響範囲**: {低/中/高}

---

Step 15: ブランチ作成とコミット

設計ドキュメントをバージョン管理に登録:

フィーチャーブランチを作成:

git checkout -b feature/{YYYYMMDD}-{feature-name}

ステアリングディレクトリをコミット:

git add docs/steering/{YYYYMMDD}-{feature-name}/
git commit -m "docs: add steering documents for {feature-name}"

完了メッセージを表示:

✅ 設計フェーズが完了しました！

📁 **ブランチ**: `feature/{YYYYMMDD}-{feature-name}`
📄 **コミット済み**: ステアリングドキュメント一式

実装を開始する場合は `/implement-feature` を実行してください。

ステータス遷移

ファイル	初期値	主な遷移
progress.md	Phase 1	Phase 1 → 2（Step 7承認後）→ 3（Step 12承認後）→ 完了（Step 15）
requirements.md	作成中	→ 要件確定（Step 7承認後）
design.md	設計中	→ 設計確定（Step 12承認後）
tasklist.md	計画中	→ 計画確定（Step 15）

注意事項

ディレクトリは Step 6 で即座に作成し、以降のファイルは随時追加・更新する
各ステップでユーザーの回答を待ってから次に進む
既存のコードパターンに従った設計を提案する
技術的な判断が必要な場合は、CLAUDE.md を参照する
対話が中断されても、途中まで入力した内容はファイルに保存されている
設計完了後、実装は /implement-feature で行う

add-feature

SKILL.md