feature-dev

機能開発ワークフロー

コードベースの調査、アーキテクチャ設計、品質レビューを専門とするエージェントを活用した、包括的で構造化された機能開発ワークフローです。

クイックスタート

ガイド付きの機能開発ワークフローを開始します。

/feature-dev Add user authentication with OAuth

または、対話形式で開始します。

/feature-dev

このワークフローでは、7 つのフェーズを順番に進めます。

概要

機能の構築には、コードを書くだけでなく、さまざまな作業が必要です。このスキルでは、次のような体系的なアプローチを提供します。

• 変更を加える前に、コードベースを把握する
• 確認の質問をして、曖昧さを解消する
• 複数のアーキテクチャ案を検討し、慎重に設計する
• 実装後に品質をレビューする

7 つのフェーズからなるワークフロー

フェーズ 1：調査

目標：構築する内容を把握する

• 不明確な機能リクエストを明確にする
• 問題、制約、要件を特定する
• 理解した内容を要約し、ユーザーに確認する

例：

User: /feature-dev Add caching
Agent: Let me understand what you need...
       - What should be cached? (API responses, computed values, etc.)
       - What are your performance requirements?
       - Do you have a preferred caching solution?

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

目標：関連する既存のコードとパターンを把握する

• code-explorer エージェントを 2～3 個並列で起動する
• 類似機能、アーキテクチャ、UI パターンを調査する
• 特定したすべてのファイルを読み、深く理解する
• 調査結果を包括的にまとめて提示する

起動するエージェント：

• 「[機能] に類似する機能を探し、実装をたどる」
• 「[領域] のアーキテクチャと抽象化をマッピングする」
• 「[関連機能] の現在の実装を分析する」

出力例：

Found similar features:
- User authentication (src/auth/): Uses JWT tokens, middleware pattern
- Session management (src/session/): Redis-backed, 24hr expiry

Key files:
- src/auth/AuthService.ts:45 - Core authentication logic
- src/middleware/authMiddleware.ts:12 - Request authentication

フェーズ 3：確認の質問

目標：不足している情報を補い、すべての曖昧さを解消する

• コードベースの調査結果と機能リクエストを確認する
• 詳細が不足している点（エッジケース、エラー処理、統合ポイントなど）を特定する
• 質問を整理して提示する
• 次に進む前に回答を待つ

例：

Before designing, I need to clarify:

1. OAuth provider: Which providers? (Google, GitHub, custom?)
2. User data: Store OAuth tokens or just profile?
3. Existing auth: Replace or add alongside current auth?
4. Sessions: Integrate with existing session management?
5. Error handling: How to handle OAuth failures?

重要：設計を始める前に、曖昧な点がないことを確認します。

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

目標：複数の実装アプローチを設計する

• 異なる観点を持つ code-architect エージェントを 2～3 個起動する。
  • 最小限の変更：変更を最小限に抑え、再利用を最大化する
  • クリーンアーキテクチャ：保守性と洗練された抽象化を重視する
  • 実用的なバランス：速度と品質の両立
• トレードオフと推奨案を比較して提示する
• 採用するアプローチを尋ねる

出力例：

Approach 1: Minimal Changes
- Extend existing AuthService with OAuth methods
Pros: Fast, low risk
Cons: Couples OAuth to existing auth

Approach 2: Clean Architecture
- New OAuthService with dedicated interface
Pros: Clean separation, testable
Cons: More files, more refactoring

Approach 3: Pragmatic Balance
- New OAuthProvider abstraction
Pros: Balanced complexity and cleanliness
Cons: Some coupling remains

Recommendation: Approach 3 - clean boundaries without excessive refactoring

フェーズ 5：実装

目標：機能を構築する

• 開始前に明示的な承認を待つ
• 前のフェーズで関連すると特定されたすべてのファイルを読む
• 選択したアーキテクチャに従って実装する
• コードベースの規約を厳守する
• 進捗を追跡するために todo を更新する

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

目標：コードがシンプルで、DRY かつ洗練され、機能的に正しいことを確認する

• code-reviewer エージェントを 3 個並列で起動する。
  • シンプルさ／DRY／洗練度：コード品質
  • バグ／正確性：機能的な正しさ
  • 規約／抽象化：プロジェクト標準
• 調査結果をまとめ、重大度の高い問題を特定する
• 対応方針を尋ねる：今すぐ修正する、後で修正する、または現状のまま進める

出力例：

High Priority Issues:
1. Missing error handling in OAuth callback (src/auth/oauth.ts:67)
2. Memory leak: OAuth state not cleaned up (src/auth/oauth.ts:89)

Medium Priority:
1. Could simplify token refresh logic (src/auth/oauth.ts:120)

What would you like to do?

フェーズ 7：要約

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

• すべての todo を完了にする
• 構築した内容、重要な決定事項、変更したファイルを要約する
• 次のステップを提案する

専門エージェント

code-explorer

目的：実行経路をたどり、既存のコードベースの機能を詳細に分析する

調査対象：

• エントリーポイントと呼び出しチェーン
• データフローと変換
• アーキテクチャのレイヤーとパターン
• 実装の詳細

出力：

• ファイル名と行番号を含むエントリーポイント
• ステップごとの実行フロー
• 主要なコンポーネントとその責務
• 読む必要がある重要なファイル

起動方法：フェーズ 2 で自動的に起動、または手動で起動

code-architect

目的：機能のアーキテクチャと実装の設計図を作成します

重点項目：

• コードベースのパターン分析
• アーキテクチャ上の意思決定
• コンポーネント設計
• 実装ロードマップ

出力：

• 見つかったパターンと規約
• 根拠を添えたアーキテクチャ上の決定
• 完全なコンポーネント設計
• ビルド順序を含む実装マップ

起動：フェーズ 4 で自動的に起動、または手動で起動

code-reviewer

目的：バグ、品質上の問題、プロジェクトの規約に照らしてコードをレビューします

重点項目：

• プロジェクトガイドライン（CLAUDE.md）への準拠
• バグの検出
• コード品質の問題
• 信頼度に基づくフィルタリング（信頼度 80％以上のみ）

出力：

• 重大な問題（信頼度 75〜100）
• 重要な問題（信頼度 50〜74）
• file:line 参照付きの具体的な修正案

起動：フェーズ 6 で自動的に起動、または手動で起動

使用パターン

完全なワークフロー（新機能に推奨）

/feature-dev Add rate limiting to API endpoints

エージェントの手動起動

機能を調査する：

"Launch code-explorer to trace how authentication works"

アーキテクチャを設計する：

"Launch code-architect to design the caching layer"

コードをレビューする：

"Launch code-reviewer to check my recent changes"

使用する場面

使用するケース：

• 複数のファイルにまたがる新機能
• アーキテクチャ上の意思決定が必要な機能
• 既存コードとの複雑な統合
• 要件がやや不明確な機能

使用しないケース：

• 1 行だけのバグ修正
• 些細な変更
• 明確に定義された単純なタスク
• 緊急のホットフィックス

ベストプラクティス

1. 複雑な機能には完全なワークフローを使用する：7 つのフェーズで徹底的に計画できます
2. 確認の質問には慎重に答える：フェーズ 3 で今後の混乱を防ぎます
3. アーキテクチャを慎重に選ぶ：フェーズ 4 で選択肢を提示するのには理由があります
4. コードレビューを省略しない：フェーズ 6 で本番環境に入る前に問題を見つけます
5. 提案されたファイルを読む：フェーズ 2 で重要なファイルを特定するため、背景を把握するために読みましょう

よくある問題

エージェントの処理に時間がかかりすぎる

原因：大規模なコードベースでは通常のことです
解決策：可能な場合、エージェントは並列で実行されます。徹底的に取り組むことで、より深い理解につながります。

確認の質問が多すぎる

原因：機能のリクエストが曖昧すぎます
解決策：最初のリクエストをより具体的にしてください。制約に関する背景をあらかじめ伝えましょう。

アーキテクチャの選択肢が多くて困る

原因：複数の有効なアプローチが提示されています
解決策：コードベースの分析に基づく推奨案を信頼してください。迷った場合は、現実的な選択肢を選びましょう。

要件

• Claude Code がインストールされていること
• Git リポジトリ（コードレビュー用）
• 既存のコードベース（ワークフローが既存のパターンから学習します）

ヒント

• 機能のリクエストを具体的にする：詳細にするほど、確認の質問が少なくなります
• プロセスを信頼する：各フェーズは前のフェーズを踏まえて進みます
• エージェントの出力を確認する：エージェントはコードベースに関する有益な知見を提供します
• フェーズを省略しない：各フェーズには目的があります
• 学習に活用する：調査フェーズを通じて、自分のコードベースについて学べます

検証チェックリスト

ワークフローの使用後：

• 7 つのフェーズすべてが正常に完了している
• フェーズ 3 で確認の質問に回答している
• フェーズ 4 でアーキテクチャのアプローチを選択している
• フェーズ 5 の開始前に実装を承認している
• フェーズ 6 でコードレビューの指摘事項に対処している
• フェーズ 7 で次のステップを含む概要を生成している
• 機能が想定どおりに動作している
• コードがプロジェクトの規約に従っている

参考資料

ワークフローの詳細については、README.md を参照してください。

エージェントの仕様については、以下を参照してください：

• agents/code-explorer.md
• agents/code-architect.md
• agents/code-reviewer.md

スラッシュコマンドの実装については、commands/feature-dev.md を参照してください。