build

機能開発パイプライン — 主要な機能を調査、計画、追跡、実装します。

手順

このコマンドは、主要な機能を構築するための4段階の機能開発ワークフローを管理します。$ARGUMENTS を解析して、実行するサブコマンドを決定します。

指定された引数： $ARGUMENTS

引数の解析

$ARGUMENTS の最初の単語を解析して、サブコマンドを決定します。

• research [name] → 調査フェーズを実行します
• implementation [name] → 実装フェーズを実行します
• progress [name] → 進捗フェーズを実行します
• phase [n] [name] → 実装のフェーズ n を実行します
• status [name] → 現在のステータスを表示し、次のステップを提案します
• （空または認識されない場合）→ 使用方法を表示します

引数に機能名が指定されていない場合は、必ず AskUserQuestion を使って入力を求めてください。

---

サブコマンド：ヘルプ（引数なし）

引数が指定されていない場合は、次のヘルプを表示します。

/build - Feature Development Pipeline

Subcommands:
  /build research [name]        Deep research on a feature idea
  /build implementation [name]  Create phased implementation plan
  /build progress [name]        Set up progress tracking
  /build phase [n] [name]       Execute implementation phase n
  /build status [name]          Show status and next steps

Example workflow:
  /build research chat-interface
  /build implementation chat-interface
  /build progress chat-interface
  /build phase 1 chat-interface

次に AskUserQuestion を使って、希望する操作を尋ねます。

• question: "何をしますか？"
• header: "操作"
• multiSelect: false
• options:
  • label: "新しい機能の調査を開始" description: "新しい機能のアイデアを詳しく調査します"
  • label: "既存の機能を続ける" description: "すでに進行中の機能に取り組みます"
  • label: "ステータスを確認" description: "機能の次のステップを確認します"

---

サブコマンド：research

ステップ 1：機能名を取得する

引数に機能名が指定されていない場合は、AskUserQuestion を使います。

• question: "この機能の短い識別子を入力してください（小文字、ハイフン使用可。例：'chat-interface'、'user-auth'、'data-export'）。入力するには「Other」を選択してください。"
• header: "機能名"
• multiSelect: false
• options:
  • label: "名前を入力します" description: "機能を表す短いケバブケースの識別子を入力します"

ステップ 2：既存の調査を確認する

docs/{name}/RESEARCH.md がすでに存在するか確認します。

存在する場合は、AskUserQuestion を使います。

• question: "この機能の RESEARCH.md はすでに存在します。どうしますか？"
• header: "既存のドキュメント"
• multiSelect: false
• options:
  • label: "上書き" description: "既存の調査を新しい調査で置き換えます"
  • label: "追記" description: "既存の内容の下に新しい調査を追加します"
  • label: "スキップ" description: "既存の調査を維持し、次のステップを提案します"

「スキップ」が選択された場合は、/build implementation {name} の実行を提案して終了します。

ステップ 3：機能のコンテキストを収集する

AskUserQuestion を使って機能を把握します。

• question: "構築したい機能について説明してください。どのような問題を解決しますか？どのような動作を想定していますか？（説明を入力するには「Other」を選択してください）"
• header: "説明"
• multiSelect: false
• options:
  • label: "説明を入力します" description: "機能について詳しく説明します"

ステップ 4：調査範囲

AskUserQuestion を使います。

• question: "調査ではどのような点に焦点を当てますか？"
• header: "重点分野"
• multiSelect: true
• options:
  • label: "技術的な実装" description: "API、ライブラリ、アーキテクチャパターン"
  • label: "UI/UX デザイン" description: "インターフェースデザイン、ユーザーフロー、インタラクション"
  • label: "データ要件" description: "保存するデータ、スキーマ、プライバシー"
  • label: "プラットフォームの機能" description: "OS API、システム連携、権限"

ステップ 5：詳細な調査を実施する

ここから機能について詳細な調査を実施します。

1. コードベースの調査：既存のパターン、類似機能、関連コードを把握します
2. ウェブ検索：ベストプラクティス、類似の実装、関連 API を調査します
3. 技術の詳細調査：特定の技術、ライブラリ、フレームワークを詳しく調べます
4. AskUserQuestion を頻繁に使用：前提を検証し、要件を明確にし、判断に関する意見を得ます

調査では、以下を取り上げてください。

• 問題の定義とユーザーのニーズ
• 技術的なアプローチとトレードオフ
• 必要なデータモデルとストレージ
• UI/UX に関する考慮事項
• 既存コードとの統合ポイント
• 想定される課題とリスク
• 根拠を添えた推奨アプローチ

Step 6: 調査ドキュメントを作成する

必要に応じてディレクトリを作成します：docs/{name}/

次の構成で、調査結果を docs/{name}/RESEARCH.md に記述します。

# {Feature Name} Research

## Overview
[Brief description of the feature and its purpose]

## Problem Statement
[What problem this solves, why it matters]

## User Stories / Use Cases
[Concrete examples of how users will use this]

## Technical Research

### Approach Options
[Different ways to implement this, with pros/cons]

### Recommended Approach
[The approach you recommend and why]

### Required Technologies
[APIs, libraries, frameworks needed]

### Data Requirements
[What data needs to be stored/tracked]

## UI/UX Considerations
[Interface design thoughts, user flows]

## Integration Points
[How this connects to existing code/features]

## Risks and Challenges
[Potential issues and mitigation strategies]

## Open Questions
[Things that still need to be decided]

## References
[Links to relevant documentation, examples, articles]

Step 7: 次のステップ

調査ドキュメントの作成後、ユーザーに次のように伝えます。

"調査が完了しました！ドキュメントを docs/{name}/RESEARCH.md に保存しました。

次のステップ： /build implementation {name} を実行して、段階的な実装計画を作成します。"

---

サブコマンド：implementation

Step 1: 機能名を取得する

引数に機能名が指定されていない場合は、AskUserQuestion を使用して機能名を尋ねます（research フェーズと同様）。

Step 2: 調査ドキュメントの存在を確認する

docs/{name}/RESEARCH.md が存在するか確認します。

存在しない場合：

• ユーザーに次のように伝えます："docs/{name}/RESEARCH.md に調査ドキュメントが見つかりません"
• 次のように提案します：調査ドキュメントを作成するため、先に /build research {name} を実行してください。
• 終了します

Step 3: 既存の実装ドキュメントを確認する

docs/{name}/IMPLEMENTATION.md がすでに存在するか確認します。

存在する場合は、AskUserQuestion を使用します。

• question: "IMPLEMENTATION.md はすでに存在します。どのようにしますか？"
• header: "既存のドキュメント"
• multiSelect: false
• options:
  • label: "上書き" description: "新しい実装計画を作成します"
  • label: "追記" description: "既存の内容の下に新しいフェーズを追加します"
  • label: "スキップ" description: "既存の計画を維持し、次のステップを提案します"

「スキップ」が選択された場合は、/build progress {name} の実行を提案して終了します。

Step 4: 調査ドキュメントを読む

docs/{name}/RESEARCH.md を読み、以下を把握します。

• 推奨されるアプローチ
• 技術要件
• 必要なデータモデル
• UI/UX デザイン
• 統合ポイント

Step 5: 実装フェーズを設計する

調査内容を、実践的な実装フェーズに分割します。各フェーズは次の条件を満たす必要があります。

• 独立した価値があり、使用可能な成果を提供する
• 集中して取り組めば完了できる規模である
• 前のフェーズを土台にする
• 明確な成功基準がある

AskUserQuestion を使用して、フェーズの分割を確認します。

• question: "実装フェーズはどの程度細かく分けますか？"
• header: "フェーズの規模"
• multiSelect: false
• options:
  • label: "小規模なフェーズ（1～2時間）" description: "集中して取り組めるフェーズを多く設け、進捗を追いやすくします"
  • label: "中規模なフェーズ（半日）" description: "バランスの取れたアプローチで、フェーズ数も適度にします"
  • label: "大規模なフェーズ（1日）" description: "フェーズ数を少なくし、それぞれで大幅な機能を実現します"

Step 6: フェーズごとの調査を行う

計画する各フェーズについて、対象を絞って調査します。

• 実装の詳細をウェブ検索する
• コードベース内の関連コードを確認する
• フェーズ間の依存関係を特定する

フェーズの順序や範囲に不明点がある場合は、AskUserQuestion を使用します。

Step 7: 実装ドキュメントを作成する

次の構成で、docs/{name}/IMPLEMENTATION.md に記述します。

# {Feature Name} Implementation Plan

## Overview
[Brief recap of what we're building and the approach from research]

## Prerequisites
[What needs to be in place before starting]

## Phase Summary
[Quick overview of all phases]

---

## Phase 1: [Phase Title]

### Objective
[What this phase accomplishes]

### Rationale
[Why this phase comes first, what it enables]

### Tasks
- [ ] Task 1
- [ ] Task 2
- [ ] Task 3

### Success Criteria
[How to verify this phase is complete]

### Files Likely Affected
[List of files that will probably need changes]

---

## Phase 2: [Phase Title]

[Same structure as Phase 1]

---

[Continue for all phases]

---

## Post-Implementation
- [ ] Documentation updates
- [ ] Testing strategy
- [ ] Performance validation

## Notes
[Any additional context or decisions made during planning]

Step 8: 次のステップ

実装ドキュメントの作成後、ユーザーに次のように伝えます。

"実装計画が完了しました！ドキュメントを docs/{name}/IMPLEMENTATION.md に保存しました。

次のステップ： /build progress {name} を実行して、進捗の追跡を設定します。"

---

サブコマンド：progress

Step 1: 機能名を取得する

引数に機能名が指定されていない場合は、AskUserQuestion を使用して機能名を尋ねます。

Step 2: 実装ドキュメントの存在を確認する

docs/{name}/IMPLEMENTATION.md が存在するか確認します。

存在しない場合：

• ユーザーに次のように伝えます："docs/{name}/IMPLEMENTATION.md に実装ドキュメントが見つかりません"
• 次のように提案します：先に /build implementation {name} を実行してください。
• 終了します

Step 3: 既存の進捗ドキュメントを確認する

docs/{name}/PROGRESS.md がすでに存在するか確認します。

存在する場合は、AskUserQuestion を使用します。

• question: "PROGRESS.md はすでに存在します。どのようにしますか？"
• header: "既存のドキュメント"
• multiSelect: false
• options:
  • label: "上書き" description: "進捗の追跡を最初から始めます"
  • label: "既存の内容を維持" description: "現在の進捗を維持し、次のステップを提案します"

「既存の内容を維持」が選択された場合は、進捗ドキュメントを読み、次に完了すべきフェーズを提案します。

ステップ 4：実装ドキュメントを読む

docs/{name}/IMPLEMENTATION.md を読み、以下を抽出します。

• すべてのフェーズのタイトル
• 各フェーズのタスク
• 成功基準

ステップ 5：進捗ドキュメントを作成する

次の構成で docs/{name}/PROGRESS.md に書き込みます。

# {Feature Name} Progress

## Status: Phase 1 - Not Started

## Quick Reference
- Research: `docs/{name}/RESEARCH.md`
- Implementation: `docs/{name}/IMPLEMENTATION.md`

---

## Phase Progress

### Phase 1: [Title from Implementation]
**Status:** Not Started

#### Tasks Completed
- (none yet)

#### Decisions Made
- (none yet)

#### Blockers
- (none)

---

### Phase 2: [Title]
**Status:** Not Started

[Same structure]

---

[Continue for all phases]

---

## Session Log

### [Date will be added as work happens]
- Work completed
- Decisions made
- Notes for next session

---

## Files Changed
(Will be updated as implementation progresses)

## Architectural Decisions
(Major technical decisions and rationale)

## Lessons Learned
(What worked, what didn't, what to do differently)

ステップ 6：次のステップ

進捗ドキュメントを作成した後：

「進捗管理を設定しました！ドキュメントは docs/{name}/PROGRESS.md に保存されました。

次のステップ： /build phase 1 {name} を実行して実装を開始してください。」

---

サブコマンド：phase

ステップ 1：引数を解析する

引数を解析し、以下を取得します。

• フェーズ番号（指定されている場合）
• 機能名（指定されている場合）

どちらも指定されていない場合は、AskUserQuestion を使って両方を尋ねます。

ステップ 2：機能名を取得する

機能名が特定できていない場合は、AskUserQuestion を使って尋ねます。

ステップ 3：すべてのドキュメントが存在することを確認する

次の 3 つのドキュメントがすべて存在することを確認します。

• docs/{name}/RESEARCH.md
• docs/{name}/IMPLEMENTATION.md
• docs/{name}/PROGRESS.md

いずれかが存在しない場合は、どのドキュメントが不足しているかをユーザーに伝え、作成に適切な /build コマンドを提案します。

ステップ 4：フェーズ番号を取得する

引数にフェーズ番号が含まれていない場合：

docs/{name}/IMPLEMENTATION.md を読み、利用可能なフェーズを抽出します。

AskUserQuestion を使ってユーザーに選択してもらいます。

• question: 「どのフェーズに取り組みますか？」
• header: 「フェーズ」
• multiSelect: false
• options: [IMPLEMENTATION.md で見つかったフェーズから動的に生成し、完了済みのものには印を付ける]

ステップ 5：すべてのコンテキストを読む

以下を十分に理解するため、3 つのドキュメントをすべて読みます。

• 調査内容と根拠（RESEARCH.md）
• 該当フェーズのタスクと成功基準（IMPLEMENTATION.md）
• 現在の進捗と決定事項（PROGRESS.md）

ステップ 6：フェーズについて詳しく調査する

実装を開始する前に：

1. ウェブ検索で、このフェーズに関連する具体的な実装方法を調べます
2. コードベースを調査し、関連する既存コードを確認します
3. フェーズの要件に曖昧な点があれば、AskUserQuestion を使って確認します

ステップ 7：フェーズの作業を実行する

フェーズの実装を開始します。

1. フェーズ内の各タスクに順番に取り組みます
2. 実装上の判断について、AskUserQuestion を頻繁に使用します
3. 「常に動作する」方針に従い、作業を進めながらテストします
4. 決定事項はその都度 PROGRESS.md に記録します

ステップ 8：進捗ドキュメントを更新する

作業を進めながら、docs/{name}/PROGRESS.md を更新します。

• タスクを完了済みとしてマークする
• 決定事項とその理由を記録する
• 発生した阻害要因を記録する
• 変更したファイルを一覧にする
• アーキテクチャ上の決定事項を追加する
• 本日の作業をセッションログに更新する

フェーズのステータスを更新します。

• 開始時は「進行中」
• すべてのタスクが完了し、成功基準を満たしたら「完了」

ステップ 9：次のステップ

フェーズの完了後：

1. PROGRESS.md を読み、次に未完了のフェーズを確認します
2. 完了をユーザーに伝え、次のアクションを提案します。

「フェーズ {n} が完了しました！進捗を docs/{name}/PROGRESS.md に更新しました。

次のステップ： /build phase {n+1} {name} を実行して、次のフェーズ（[次のフェーズのタイトル]）に進んでください。」

または、すべてのフェーズが完了している場合：

「すべてのフェーズが完了しました！{feature name} 機能の実装が完了しました。

以下をご検討ください。

• テストを実行して、すべてが正しく動作することを確認する
• ドキュメントを更新する
• レビュー用の PR を作成する」

---

サブコマンド：status

ステップ 1：機能名を取得する

引数に機能名が含まれていない場合は、AskUserQuestion を使って尋ねます。

ステップ 2：存在するドキュメントを確認する

以下が存在するか確認します。

• docs/{name}/RESEARCH.md
• docs/{name}/IMPLEMENTATION.md
• docs/{name}/PROGRESS.md

ステップ 3：ステータスと次のステップを判断する

存在するドキュメントに基づいて判断します。

ドキュメントが存在しない場合： "機能「{name}」のドキュメントが見つかりませんでした。 次のステップ： /build research {name} を実行して開始してください。"

RESEARCH.md のみが存在する場合： "「{name}」の調査が完了しました。 次のステップ： /build implementation {name} を実行して実装計画を作成してください。"

RESEARCH.md と IMPLEMENTATION.md が存在する場合： "「{name}」の調査と実装計画が完了しました。 次のステップ： /build progress {name} を実行して進捗管理を設定してください。"

3 つすべてが存在する場合： PROGRESS.md を読み、現在のフェーズのステータスを確認します。 "機能「{name}」は進行中です。 現在のステータス：［フェーズ X - ステータス］ 次のステップ： /build phase {next incomplete phase} {name} を実行して続行してください。"

すべてのフェーズが完了している場合： "機能「{name}」の実装が完了しました！"

---

重要なガイドライン

AskUserQuestion を積極的に活用する

すべてのフェーズを通じて、次の場合は AskUserQuestion を使用してください。

• 要件が曖昧な場合
• 複数のアプローチが考えられる場合
• 仮定を検証する必要がある場合
• 判断が実装に大きな影響を与える場合
• スコープや優先順位が不明な場合

深い調査で求められること

「深い調査」とは、次のことを意味します。

• 異なる側面について複数回ウェブ検索する
• コードベースを徹底的に調査する
• 関連ドキュメントを読む
• 複数のアプローチを検討する
• トレードオフを理解する

調査を急がないでください。調査は優れた実装の基盤です。

進捗管理

フェーズ作業中は、PROGRESS.md をリアルタイムで更新してください。

• 終了まで更新を待たない
• 決定事項を決まり次第記録する
• ブロッカーをすぐに記録する
• これにより、今後のセッションで役立つコンテキストが生まれます

スコープ管理

このワークフローの主な目的の 1 つは、スコープクリープを防ぐことです。

• 各フェーズの境界を明確にする
• 新しい要件が出てきた場合は、今後のフェーズ向けに記録する
• 実装中に現在のフェーズのスコープを広げない
• 対象スコープに含まれるかどうかを確認するには、AskUserQuestion を使用する

常に動作する状態を保つ考え方

フェーズを実装する際は、次の点を守ってください。

• 変更を加えながらテストする
• コードが動作すると決めつけず、検証する
• 動作しない場合は、先に修正してから次に進む
• 目標は、コードを書くだけではなく、動作するソフトウェアを作ることです