Claude Code Team Builder

このスキルが生成するもの

任意のソフトウェアプロジェクトに対して、このスキルは完全な .claude/ ディレクトリを生成します：

.claude/
├── CLAUDE.md                              ← project context Claude reads every session
├── settings.json                          ← orchestration + autonomy configuration
├── agents/
│   ├── orchestrator/AGENT.md              ← mandatory: plans, assigns, validates
│   ├── problem-solver/AGENT.md            ← mandatory: self-healing, task repair
│   ├── test-engineer/AGENT.md             ← mandatory: validates every feature
│   ├── documentation-writer/AGENT.md      ← mandatory: PRDs before development
│   └── [project-specific]/AGENT.md
├── skills/
│   ├── run/SKILL.md                       ← autonomous execution loop
│   ├── status/SKILL.md                    ← project state reporting
│   ├── dashboard/SKILL.md                 ← visual progress tracker
│   ├── deploy/SKILL.md                    ← workflow skill
│   ├── test/SKILL.md                      ← workflow skill
│   ├── review/SKILL.md                    ← workflow skill
│   └── [domain skills]/SKILL.md           ← project-specific
└── workspace/                             ← result files, progress.log, orchestrator_state.json

CLAUDE.md が最も重要な出力です。セッション開始時に毎回読み込まれるプロジェクトコンテキスト：テックスタック、ドメイン概念、エージェントルーティング、プロジェクト完了基準、利用可能なコマンド、および規約が含まれます。

エージェント はサブフォルダ構造（agents/[name]/AGENT.md）を使用します。各エージェントは独自のハンドオフプロトコルを備えています。4つのエージェントはすべてのプロジェクトで必須です：オーケストレーター、問題解決者、テストエンジニア、ドキュメンテーション記述者。

スキル は2種類あります：

• 実行スキル — /run、/status、/dashboard — オーケストレーションと監視
• ワークフロースキル — /deploy、/test、/review、/migrate — 開発者ワークフロー
• ドメインスキル — このプロジェクトが実際に何をするかに合わせてカスタマイズ（例：/process-refund、/onboard-vendor）

settings.json はオーケストレーション動作を制御します：自律性モード、マイルストーン自動進行、再試行ポリシー、および自己修復パイプライン。

このスキルは以下を作成しません：

• PRD、アーキテクチャドキュメント、または仕様書（ドキュメンテーション記述者エージェントがこれを行います）
• ソースコードまたはプロジェクトスキャフォルディング（開発エージェントがこれを行います）
• .claude/ の外にあるアーティファクト

---

フェーズ1：ディスカバリー

モードの選択 — 他の何かをする前に常にユーザーに尋ねます：

これは必須です。ユーザーがスキルをトリガーする方法に関わらず、「新しいプロジェクトを設定する」と言うか、「私のSaaS アプリのためにチームを構築する」と言うか、予告なしにプロジェクトの完全な説明を貼り付けるか、常にモード選択を最初に提示します。 このステップをスキップしないでください。ユーザーが会話をどのように開始したかからモードを推測しないでください。

"プロジェクトを設定するために、2つの方法で作業できます：

• 貼り付けモード：知っていることすべてを共有してください — 説明、テックスタック、要件、制約 — 残りは推測します。
• Q&Aモード：各セクションごとに1つずつ質問します。より徹底的で、複雑なプロジェクト向けのより良い出力。

どちらをお好みですか？"

ユーザーが初めのメッセージでプロジェクト説明をすでに貼り付けている場合でも、尋ねてください — 彼らは考えなかったギャップを埋めるためにQ&Aモードを望むかもしれません。ユーザーが貼り付けモードを確認した場合は、すでに共有されているものを使用して進めます。

貼り付けモード

ユーザーはプロジェクト説明を貼り付けます。提供されたものから質問バンクへの回答を抽出し、その後、重大なギャップについてのみ尋ねます — 最大で3つのフォローアップです。何かが本当に不明な場合は、合理的な仮定を立て、明確に述べます。

Q&Aモード

質問バンク（references/question-bank.md）から、セクションごとに1つずつ質問します。各セクションは番号付きリストとして提示します。前の回答から答えが既に明らかな質問は尋ねないでください。

進むために必要（最小限の実行可能なディスカバリー）：

1. あなたは何を構築していますか？（タイプ＋目的）
2. テックスタックは何ですか？（フロントエンド、バックエンド、データベース）
3. 最もリスクが高いまたは最も複雑な技術領域は何ですか？

他のすべては合理的なデフォルトで推測できます。

---

フェーズ2：エージェントの決定

常に含める（必須）：

• orchestrator — タスクを計画し、割り当て、結果を検証し、実行ループを駆動します
• problem-solver — 自己修復：失敗したタスクを書き直し、複雑なタスクを分割し、受け入れ基準を修正します
• test-engineer — すべての機能を検証します
• documentation-writer — 開発前のPRD、クライアントハンドオフ用の仕様

テックスタックと複雑さに基づいて追加：

シグナル	追加
UIとAPIが異なるウェブアプリ	frontend-developer + backend-developer
フルスタックフレームワーク（Next.js、Nuxt、SvelteKit）	fullstack-developer（垂直スライシング向けの推奨）
データ量が多いスキーマ/複雑なクエリ	database-architect
デプロイメント/CI/CDの場合	devops-engineer
クライアント納品/支払いコード/機密ロジック	code-reviewer
支払い、請求、財務ロジックが中央	payments-engineer（ドメインスペシャリスト）
リアルタイム/ライブストリーミング/WebSocket	streaming-engineer（ドメインスペシャリスト）
既存のクライアントデザインシステム	design-system-integrator（ドメインスペシャリスト）
認証、OAuth、コンプライアンス	auth-security-engineer（ドメインスペシャリスト）
ML、AI機能、データサイエンス	ml-engineer（ドメインスペシャリスト）
iOS/Android/React Native	mobile-developer

チームサイズ：シンプルなプロジェクト向けは5～6エージェント（4つの必須＋1～2つの開発）、中程度の場合は6～8、複雑なマルチサーフェスプロジェクトの場合は8～10。

エージェント説明に関する重要なルール： description フィールドはClaudeがタスクをルーティングするために使用するものです。特定のテクノロジーとタスクタイプに名前を付ける必要があります。「バックエンドAPI開発」のような汎用説明は役に立ちません。良い説明は次のようなものです：

"Next.js App Router API routes、Prisma ORM クエリ、および Stripe Connect ウェブフック処理。TaskFlow プロジェクトのすべてのサーバー側ロジック、データベース作業、または支払い処理に使用します。"

すべてのエージェントファイルはプロジェクトの名前、スタック、ドメインを参照する必要があります。

認知負荷に基づくモデル割り当て： すべてのエージェントが同じモデルを必要とするわけではありません。仕事の推論複雑さに基づいて割り当てます：

ティア	モデル	エージェント	理由
計画	opus（またはsonnet）	orchestrator、problem-solver	タスク分解、障害診断、および依存関係推論には最も強力な計画能力が必要です。ユーザーのモデルバランス設定がそれを許可する場合はopusを使用。そうでない場合はsonnet。
実行	sonnet	すべての開発者エージェント、devops-engineer	よく定義されたスコープ内での集中的なコード生成。Sonnetはこれを適切に処理します。
検証	sonnet（またはhaiku）	test-engineer、code-reviewer、documentation-writer	基準と出力の確認、コードパターンのレビュー、構造化ドキュメントの作成。シンプルな検証タスクの場合、ユーザーがコストを最適化したい場合はhaikuで十分です。

ディスカバリー中（質問11）にユーザーの好みを尋ねます。デフォルト：すべてのエージェント向けのsonnet。コスト最適化が必要な場合は、検証エージェントをhaikuに低下させます。最大の品質が必要な場合は、計画エージェントをopusにアップグレードします。

---

フェーズ3：スキルの決定

実行スキル — 常に含める：

スキル	目的
/run	状態の和解を伴う自律実行ループ
/status	プロジェクト状態レポート
/dashboard	ビジュアルプログレストラッカー（HTML）

ワークフロースキル — 条件が合致した時に含める：

スキル	次の場合に含める
/deploy	プロジェクトはデプロイメントパイプラインまたはホスティングターゲットを持つ
/test	プロジェクトは自動テスト（またはそれを持つ予定）を持つ
/review	クライアントプロジェクトまたはコード品質が優先事項
/migrate	プロジェクトはリレーショナルデータベースを持つ
/pr	プロジェクトはGitHub/GitLabとPRを使用
/seed	プロジェクトは開発用のデータベースシードデータを持つ
/changelog	クライアントはリリースノートまたはバージョン管理された納品物を期待

ドメインスキル — プロジェクトの主要なワークフローから導出：

考えてみてください：「このデベロッパーが何度も繰り返す複数ステップのタスクは何か？」

ドメイン別の例：

• Eコマース：/process-refund、/add-product、/sync-inventory
• SaaS/マルチテナント：/onboard-tenant、/audit-usage、/manage-subscription
• マーケットプレイス：/approve-vendor、/process-payout、/handle-dispute
• ストリーミング/メディア：/check-stream-health、/rotate-cdn-keys
• データ/アナリティクス：/generate-report、/run-pipeline、/validate-schema
• 認証重視：/audit-permissions、/rotate-keys

プロジェクトが実際に何をするかに基づいて、1～3つのドメインスキルを作成します。

---

フェーズ4：ファイルの生成

生成ルール：構造セクションを逐語的にコピー

テンプレートには2種類のコンテンツが含まれています：

• プレースホルダー — [Project Name]、[tech stack]、[test framework]のような[括弧内]のテキスト。これらをプロジェクト固有の値に置き換えます。
• 構造セクション — エージェントとスキルの動作方法を定義する名前付きブロック。これらは生成されたファイルに逐語的にコピーされなければなりません。パラフレーズ、短縮、要約、または独自の言葉での書き直しはしないでください。

テンプレートから逐語的にコピーする必要がある構造セクション：

テンプレート	逐語的にコピーするセクション
orchestrator	Task Sizing Rules、State Management、State Summarization、Execution Loop、Self-Healing Pipeline、Handoff Protocol
problem-solver	Self-Healing Workflow、Handoff Protocol
その他すべてのエージェント	Handoff Protocol
/run skill	Execution Loop（Reconcile State、Self-healing pipelineを含むすべてのステップ）
/dashboard skill	ダッシュボードの動作方法、Important
CLAUDE.md	Task Sizing（テンプレートから一般的なルールをコピーし、その下にプロジェクト固有の行を追加）

これが重要な理由： これらのセクションには、単なる説明ではなく、推論ルールが含まれています。オーケストレーターが完全なTask Sizing Rules の代わりにパラフレーズされた要約を取得した場合、再計画中にエッジケースについて推論できません。エージェントが短縮されたHandoff Protocol を取得した場合、結果ファイルの作成をスキップする可能性があります。テンプレートは正確です。ルールが正確である必要があるからです。

プレースホルダーを置き換え、構造セクションをコピーした後、上記のリストされているすべての構造セクションが存在し、完全であること（短縮されていない、書き直されていない）を確認することで、生成されたファイルを検証します。

4A：エージェントファイル（サブフォルダ構造）

各エージェント用に .claude/agents/[name]/AGENT.md を作成します。references/templates/agents.md のテンプレートを使用します。すべてのプレースホルダーをプロジェクト固有のコンテンツに置き換えます。上記のルールに従って、すべての構造セクションを逐語的にコピーします。

4B：スキルファイル

各スキル用に .claude/skills/[skill-name]/SKILL.md を作成します。references/templates/skills.md のテンプレートを使用します。各スキルは：

• 明確なトリガー説明を持つ（description フロントマター フィールド）
• ワークフローをステップバイステップで説明する
• プロジェクトの実際のコマンド、パス、規約を参照する
• 短い — ワークフロースキルは通常30～60行

4C：CLAUDE.md — プロジェクトの脳

references/templates/claude-md.md を構造のテンプレートとして使用します。以下を含める必要があります：

1. プロジェクト概要 — 2～3文。それが何であるか、誰のためか、現在のステータス。
2. テックスタック — 完全なリスト
3. 主要ドメイン概念 — エンティティとビジネスルール（3～8つの概念）
4. エージェントルーティング — オーケストレーターが最高優先度である明示的なルール
5. 利用可能なスキル — /commands のリスト（1行の説明付き）
6. プロジェクト規約 — ファイル構造、命名、してはいけないこと
7. プロジェクト完了基準 — オーケストレーターの決定的な停止ポイント
8. タスクサイジング — テンプレートから一般的なルールをコピーし、その下にプロジェクト固有の行を追加します（上記の生成ルールに従う）
9. 現在のフォーカス — プロジェクトが進化するにつれてユーザーが更新するプレースホルダー

CLAUDE.md を130行以下に保ちます。密度が高いが、スキャン可能。

4D：settings.json

{
  "autonomy": {
    "mode": "supervised",
    "auto_advance_milestones": true,
    "escalation_enabled": true
  },
  "retry_policy": {
    "max_retries": 4,
    "strategy": "classify-then-act",
    "simple_failure_retry": 1
  },
  "self_healing": {
    "enabled": true,
    "pipeline": ["simple-retry", "refine-instructions", "split-task", "reassign-agent", "escalate"],
    "invoke_problem_solver": "structural-failures-only"
  },
  "model_tiers": {
    "planning": "sonnet",
    "execution": "sonnet",
    "validation": "sonnet"
  }
}

mode フィールドは3つの値を受け入れます：

• "supervised" — マイルストーン境界とエスカレーション時にヒューマンインプットを一時停止します（デフォルト）
• "autonomous" — 受け入れ基準がパスするとマイルストーンを自動進行、致命的な障害時のみエスカレーション
• "strict-autonomous" — エスカレーション完全に無効。問題解決者がすべてを処理します

model_tiers フィールドは各エージェントクラスが使用するモデルを制御します：

• "planning" — orchestrator、problem-solver（オプション："opus"、"sonnet"）
• "execution" — すべての開発者エージェント、devops（オプション："sonnet"、"haiku"）
• "validation" — test-engineer、code-reviewer、documentation-writer（オプション："sonnet"、"haiku"）
• デフォルト：すべてのティア向けの "sonnet"。コスト最適化の場合は、検証を "haiku" に設定します。最大品質の場合は、計画を "opus" に設定します。

4E：workspaceディレクトリとダッシュボード

.claude/workspace/ を空のディレクトリとして作成します。references/templates/dashboard.html を .claude/workspace/dashboard.html にコピーします。ダッシュボードHTMLをゼロから生成しないでください — 常に固定テンプレートを使用してください。

オーケストレーターはワークスペースに以下を入力します：

• orchestrator_state.json — セッション間で永続的な状態
• progress.log — タスク遷移ログ
• dashboard.html — 固定テンプレート、tasks.json と progress.log を動的に読み取ります
• [task-id].result.md — 個々のエージェント結果ファイル

---

フェーズ5：検証と要約

完了する前に、以下を確認します：

• ✅ テンプレートからのすべての構造セクションが生成されたファイル内に存在し、完全です（フェーズ4生成ルール参照）
• ✅ orchestrator エージェントが以下を持つ：State Management、State Summarization、Task Sizing Rules、Execution Loop、Self-Healing Pipeline、Handoff Protocol — すべて逐語的
• ✅ problem-solver エージェントが以下を持つ：Self-Healing Workflow、Handoff Protocol — 逐語的
• ✅ その他すべてのエージェントが以下を持つ：Handoff Protocol — 逐語的
• ✅ すべてのエージェントがサブフォルダ構造（agents/[name]/AGENT.md）を使用
• ✅ すべてのエージェント説明がこのプロジェクトの実際のテックスタックとドメインを参照
• ✅ CLAUDE.md Task Sizing が一般的なルールと、それに続くプロジェクト固有の行を持つ
• ✅ CLAUDE.md はエージェントルーティング、スキルリスト、ドメイン概念、完了基準、および規約を含む
• ✅ settings.json が自律性、再試行、自己修復、およびモデルティア設定を含む
• ✅ dashboard.html in workspace が references/templates/dashboard.html からコピーされた固定テンプレート
• ✅ 実行スキル（/run、/status、/dashboard）を含める
• ✅ 最低2つのワークフロー/ドメインスキルを作成
• ✅ PRD、仕様書、アーキテクチャドキュメント、またはソースコードなしで作成
• ✅ 合計ファイル数 ≤ 25

その後、以下を要約します：

• 作成されたエージェントとその理由
• 作成されたスキルとそれが何をするか
• CLAUDE.md 内の内容
• 設定された自律性モード、および変更方法
• 推奨される最初のアクション：/run --plan を実行してタスク分解を生成し、確認してから、/run を実行して実行を開始

---

リファレンスファイル

• references/question-bank.md — カテゴリ別に整理された完全なディスカバリー質問バンク
• references/templates/agents.md — 各ロール向けのエージェントファイルテンプレート（orchestrator + problem-solver を含む）
• references/templates/skills.md — 実行、ワークフロー、およびドメインスキル向けのスキルファイルテンプレート
• references/templates/claude-md.md — CLAUDE.md 構造テンプレート
• references/templates/dashboard.html — 固定ダッシュボードテンプレート（ワークスペースにコピー、再生成しない）