joris887/exosuit

---

build

プロジェクトを自然言語の説明から構築します。セットアップ、計画、実装を自動的にまとめて実行します。

ユーザー向けの出力はすべて、必ず平易な英語を使用してください。専門用語は使用しないでください：「TDD」、「スプリント」、「PR」、「スカッシュマージ」、「CI/CD」、「ORM」、「ミドルウェア」などは使わないでください。技術用語が避けられない場合は、括弧内で説明を加えてください。

引数

$ARGUMENTS — 構築するものの平易な英語での説明（例：「ユーザーアカウントと期限付きのタスク管理アプリ」）。

フェーズ0：セットアップの確認

CLAUDE.mdから現在のプロファイルを読み取ります。leanでない場合は、プロファイルをメモしますが、続行します — /build は、プロジェクトのプロファイルに関係なく、内部では常にleanスタイルの実行を使用します。

フェーズ1：分解

表示：「構築に必要なものを計画しています...」

説明を /ideate ロジックを使用して、内部で依存関係順のストーリーに分解します：

1. 説明されたコアエンティティと機能を特定
2. 依存関係順の実装ステップに分割
3. それぞれを機能、インフラストラクチャ、またはテストとして分類
4. 各ステップのサイズを見積もる（5ファイル以下に影響するステップを目指す）

これをユーザーに表示しないでください。 ストーリータイプ、SPIDR、優先度ラベル、方法論の用語は一切使用しないでください。分解は内部に留めてください。

内部計画を作成します（ユーザーには表示しません）：

steps:
  - summary: "データベーステーブルを設定する"
    type: infrastructure
    files: [...]
  - summary: "APIエンドポイントを構築する"
    type: feature
    files: [...]
  - summary: "ユーザー認証を追加する"
    type: feature
    files: [...]
  - summary: "テストを書く"
    type: testing
    files: [...]

発見のキャプチャ（事後的）

将来のフェーズレビューのために、発見コンテキストをサイレントでキャプチャします — ユーザーには表示されません：

1. 説明からアーキタイプを推測（.claude/skills/discover/references/scale-guide.md の10のアーキタイプに対して分類）
2. スケールをQuick Buildに設定
3. 最小限の docs/reference/DECISION_LOG.md を自動生成（.claude/skills/discover/assets/decision-log.md からテンプレートをコピー）、すべての技術的判断を信頼度ASSUMEDで記録
4. フェーズ移行ストーリー（E0N-REVIEW：3ストーリーのクイックバリアント — E0N-001、E0N-004、E0N-006）を最後の内部ステップとして含める
5. 分類を vision/classification.md に保存

これにより、/build ユーザーは事前の摩擦なくレビューサイクルを利用できます。

フェーズ2：実行

依存関係順に各ステップを実行します：

1. 進捗を平易な英語で表示：

   • 「データベースを設定しています...」/「APIを構築しています...」/「ユーザーログインを追加しています...」/「すべてが正常に動作することを確認するテストを書いています...」
   • ユーザーが理解できる言葉を使用してください。絶対にやらないこと：「ストーリーE01-003を実行中（タイプ：機能、サイズ：STANDARD）」

2. ストーリーサイクルのLean動作を使用して実行：

   • 計画（軽量 — 信頼度スコアは付けない）
   • 重要な部分ではTDDで構築（テストを実行するが、TDDの方法論は説明しない）
   • テストが合格することを確認
   • 従来の形式でコミット（コミット規則は説明しない）

3. すべての技術的判断を黙って行う：

   • フレームワーク/ライブラリの選択：最適なものを選び、最終サマリーに文書化
   • アーキテクチャ：検出されたスタックの標準パターンに従う
   • ファイル構造：既存のプロジェクト規則または検出されたスタックのデフォルトに従う
   • 本当に製品の曖昧さがある場合のみ停止：「デザインには2つの方向性があります：[A] または [B]。どちらを希望されますか？」
   • 以下の理由では絶対に停止しない：データベースの選択、APIスタイル、ファイル命名、テストフレームワーク、フォルダ構造

4. 障害を優雅に処理：

   • ステップが2回試行しても失敗した場合、次のようなメモを添えてスキップ：「[X]を自動的に動作させることができませんでした。手動で行う必要があるものは次の通りです：[説明]」
   • 残りのステップを続行 — ビルド全体をブロックしない

フェーズ3：完了

3A. 起動と確認（該当する場合）

CLAUDE.mdのコマンドで dev: コマンドを確認します。設定されている場合：

1. 表示：「プロジェクトを起動しています...」
2. Bashで run_in_background: true を使用してdevコマンドをバックグラウンドで実行
3. 数秒待機。出力を読み取ります — URL、ポート、ファイルパス、ステータスメッセージを探します。
4. コマンドが生成したものを表示します。URLが出力された場合は強調表示します。CLIの場合はヘルプ出力を表示します。サーバーを起動した場合はアドレスを表示します。
5. 確認：「ご確認いただき、感想をお聞かせください！」
6. フィードバックを待ちます。肯定的 → 完了レポートに進みます。問題あり → 修正して再実行します。

dev コマンドが設定されていない場合（ライブラリ、パッケージ、パイプラインなど）→ このステップはスキップします。テストは既にビルドを確認済みです。

localhostや特定のURLを想定しないでください。 実際のコマンド出力を読み取ってください。プロジェクトが異なれば、結果も異なります。

3B. 完了レポート

完了レポートを平易な英語で表示します：

## 完了しました！

### 構築したもの
- [機能1]：[何をするかの平易な英語での説明]
- [機能2]：[説明]
- ...

### 作成/変更したファイル
- `src/models/user.ts` — ユーザーデータモデル
- `src/api/auth.ts` — ログインと登録エンドポイント
- ...

### テスト
- [N]件のテストを作成、すべて合格

### 行った技術的判断
- **データベース：** PostgreSQL（信頼性が高く、無料で、[フレームワーク]と相性が良い）
- **認証：** [選択したアプローチ] — [一行の理由]
- ...

### 試してみる
[devコマンドを実行した場合：「プロジェクトは実行中です — 上記を参照してください」]
[devコマンドは存在するが起動しなかった場合：「`[dev command]` を実行して起動してください」]
[devコマンドがない場合：このセクションは省略]

### 次のステップ
- [提案1（例：「/build 'Stripe決済統合' で支払いシステムを追加する」）]
- [提案2]

ルール

• 平易な英語のみ — ユーザー向けのすべてのメッセージは、コーディング経験のない人にも理解可能でなければなりません
• 黙って技術的判断を行う — 適切なデフォルトを選び、完了レポートに文書化し、決して尋ねない
• 製品に関する質問でのみ停止する — 「ユーザーは自分のアカウントを削除できるべきですか？」は有効です。「RESTですか、それともGraphQLですか？」は有効ではありません。
• セーフティフックは引き続き実行される — シークレット検出、git保護、テスト実行は透過的に行われます
• Lean実行 — 品質エージェントのディスパッチ、スプリント仕様、レトロスペクティブ、作業に必要な以上のドキュメント生成は行いません
• 優雅にスキップ — 失敗したステップは記録されますが、致命的ではありません。ビルドは続行されます。
• 1セッション — /build の最初のバージョンは1セッションで完了します。複数セッションのビルドは将来の作業です。