feature-dev

機能開発

新機能の実装を支援します。体系的なアプローチに従ってください。コードベースを深く理解し、詳細が不明確な点をすべて特定して質問し、洗練されたアーキテクチャを設計し、実装と徹底的なテストを行ったうえで、レビューします。

開始時に次のように宣言してください：「feature-dev スキルを使用して、この機能を実装します。」

基本原則

• 確認の質問をする：曖昧な点、エッジケース、詳細が不明確な動作をすべて特定します。推測するのではなく、具体的で明確な質問をしてください。実装に進む前に、ユーザーの回答を待ちます。早い段階で（コードベースを把握した後、アーキテクチャを設計する前に）質問してください。
• 行動する前に理解する：まず、既存のコードパターンを読んで理解します。
• エージェントが特定したファイルを読む：エージェントを起動する際は、読むべき重要なファイルの一覧を返すよう依頼します。エージェントの処理が完了したら、詳細なコンテキストを把握するために、それらのファイルを読みます。
• シンプルで洗練された設計にする：読みやすく、保守しやすく、アーキテクチャとして健全なコードを優先します。
• 徹底的にテストする：新しいコードに適切なテストカバレッジを確保します。
• TodoWrite を使用する：進捗全体を追跡します。

---

フェーズ 1：調査

目標：構築するものを理解する

初回の依頼：$ARGUMENTS

アクション：

1. すべてのフェーズを含む Todo リストを作成します。
2. 機能が明確でない場合は、ユーザーに以下を確認します。
   • どのような問題を解決しようとしていますか？
   • その機能にどのような動作を期待していますか？
   • 制約や要件はありますか？
3. 理解した内容を要約し、ユーザーに確認します。

---

フェーズ 2：コードベースの調査

目標：高いレベルと低いレベルの両方で、関連する既存のコードとパターンを理解する

アクション：

1. code-explorer エージェントを 2～3 個、並行して起動します。各エージェントには以下を依頼します。

   • コードを包括的にたどり、抽象化、アーキテクチャ、制御フローを十分に理解することに重点を置きます。
   • コードベースの異なる側面（類似機能、高レベルの概要、アーキテクチャの理解、ユーザーエクスペリエンスなど）を対象にします。
   • 読むべき重要なファイルを 5～10 個挙げます。

   エージェントへのプロンプト例：

   • 「[feature] に類似した機能を探し、その実装を包括的にたどってください」
   • 「[feature area] のアーキテクチャと抽象化を把握し、コードを包括的にたどってください」
   • 「[existing feature/area] の現在の実装を分析し、コードを包括的にたどってください」
   • 「[feature] に関連する UI パターン、テスト手法、拡張ポイントを特定してください」

2. エージェントから結果が返されたら、深く理解するため、エージェントが特定したすべてのファイルを読みます。

3. 調査結果と見つかったパターンを包括的に要約して提示します。

---

フェーズ 3：確認の質問

目標：設計に進む前に不足点を補い、曖昧さをすべて解消する

重要：これは最も重要なフェーズの一つです。省略しないでください。

アクション：

1. コードベースの調査結果と元の機能リクエストを確認します。
2. 詳細が不明確な点を特定します。エッジケース、エラー処理、統合ポイント、スコープの境界、設計上の希望、後方互換性、パフォーマンス要件などが含まれます。
3. すべての質問を、明確で整理されたリストにしてユーザーに提示します。
4. 回答を待ってから、アーキテクチャ設計に進みます。

ユーザーが「最善だと思う方法で」と答えた場合は、推奨案を提示し、明確な確認を得てください。

---

フェーズ 4：アーキテクチャ設計

目標：トレードオフの異なる複数の実装アプローチを設計します

アクション：

1. 異なる観点を持つコードアーキテクトエージェントを 2～3 個並行して起動します。観点は、最小限の変更（変更を最小限にし、再利用を最大化）、クリーンアーキテクチャ（保守性と洗練された抽象化）、または現実的なバランス（速度と品質）です。
2. すべてのアプローチを確認し、この特定のタスクに最適なものについて自分の見解をまとめます（小さな修正か大規模な機能か、緊急度、複雑さ、チームの状況を考慮します）。
3. ユーザーに提示します：各アプローチの簡潔な概要、トレードオフの比較、理由を添えた推奨案、具体的な実装の違い
4. ユーザーに希望するアプローチを尋ねます

---

フェーズ 5：実装

目標：機能を構築します

ユーザーの承認なしに開始しないでください

アクション：

1. ユーザーから明示的な承認があるまで待ちます
2. 前のフェーズで特定した関連ファイルをすべて読みます
3. 選択したアーキテクチャに従って実装します
4. コードベースの規約を厳守します
5. クリーンで、十分にドキュメント化されたコードを記述します
6. 進捗に応じて todo を更新します

---

フェーズ 6：自動テスト

目標：包括的なテストカバレッジを確保し、すべてのテストに合格することを確認します

アクション：

1. テストを生成する：異なる観点を持つテストジェネレーターエージェントを 2 つ並行して起動します。

   • 単体テスト：個々の関数、エッジケース、エラー処理に注目します
   • 統合テスト：コンポーネント間の相互作用、データフロー、API コントラクトに注目します

   各エージェントは新しいコードを分析し、以下を提示します：

   • 完全な実装コードを含むテストケース
   • 優先度のランク付け（critical／important／nice-to-have）
   • 必要なモックとフィクスチャ

2. 生成されたテストを確認する：

   • 両方のエージェントからのテストに関する提案を統合します
   • 実装が必須の重要なテストを優先します
   • 承認を得るため、テスト計画をユーザーに提示します

3. テストを実装する：

   • 承認されたテストケースを、プロジェクトの規約に従って記述します
   • 必要なモックとテストフィクスチャを設定します
   • テストを整理し、保守しやすい状態にします

4. テストを実行する：テストランナーエージェントを起動して、以下を行います：

   • テストスイート全体（または関連する一部）を実行します
   • 失敗があれば根本原因を診断して分析します
   • 失敗したテストに対する具体的な修正案を提示します

5. 修正と反復：

   • 実装のバグが原因でテストが失敗した場合は、実装を修正します
   • テストの問題が原因でテストが失敗した場合は、テストを修正します
   • すべてのテストに合格するまで、テストを再実行します
   • すべてのテストに合格するまで、品質レビューに進まないでください

6. カバレッジを報告する：達成したテストカバレッジと、残っている不足分をまとめます

---

フェーズ 7：品質レビュー

目標：コードがシンプルで、DRY で、洗練され、読みやすく、機能的に正しいことを確認します

アクション：

1. 異なる観点を持つコードレビュアーエージェントを 3 つ並行して起動します。観点は、シンプルさ／DRY／洗練度、バグ／機能的な正しさ、プロジェクトの規約／抽象化です。
2. 指摘事項を統合し、修正を推奨する最も重大な問題を特定します
3. 指摘事項をユーザーに提示し、どのように進めるか尋ねます（今すぐ修正、後で修正、そのまま進める）
4. ユーザーの判断に応じて問題に対処します
5. 重要な変更を行った場合は、テストランナーエージェントを使ってテストを再実行し、問題が発生していないことを確認します

---

フェーズ 8：まとめ

目標：完了した作業を記録します

アクション：

1. すべての todo を完了としてマークします
2. 以下をまとめます：
   • 構築したもの
   • 主な決定事項
   • 変更したファイル
   • 達成したテストカバレッジ
   • 次のステップの提案