team-executor

Team Executor

ブレインダンプを、エキスパートによる計画と自律的な実行という2つのフェーズを通じて、実行済みの成果へと変える自律型マルチエージェントオーケストレーションスキルです。

概要

このスキルは、次の2つの異なるフェーズで動作します。

フェーズ1 — 計画：未整理の入力をまとめ、エキスパートエージェントのチームを編成し、それぞれの専門分野の知識に基づいて目標を分析させ、包括的な実行計画を作成します。

フェーズ2 — 実行：新たに編成されたエージェントチームが、人間の介入を必要とせず、計画を最後まで自律的に実行します。

中核となる理念は、エキスパートが計画し、エキスパートが実行し、成果物をそのまま本番環境で使える状態にすることです。

中核原則：コーディングエージェント実行モデル

このスキルが作成する計画は、人間ではなくコーディングエージェントが実行します。これにより、あらゆる段階で判断基準が変わります。

実装はコーディングエージェントが行います。人間の時間、速度、労力に関する見積もりは適用されません。人間なら時間がかかるという理由で、より堅牢なソリューションを避けてはなりません。リスク、セキュリティ、保守性、既存プロジェクトの規約との一貫性を考慮してください。既存のツールやスタイル、コンポーネントを活用する、最も堅牢で適切に設計された選択肢を優先してください。既存のパターンが適用できる場合は、並行するパターンを導入しないでください。

チームがトレードオフを判断するあらゆる場面で、これを適用してください。アプローチの選択、対立の解決、計画のレビュー、実行中の詳細の補完が該当します。ソリューションを却下する理由は、リスク、セキュリティ、保守性、または規約に限ります。作業量が「多い」から、あるいは「人間なら時間がかかる」からという理由で却下してはなりません。これが計画における経済原則です。人間の労力は、判断の決め手にはなりません。コードにおいて実際に「堅牢」とは何を意味するのか、つまり差分が満たすべきエンジニアリング基準は、ここではなくsoftware-engineerスキルが定義します。

エンジニアリングは委任するものであり、内包するものではありません

team-executorは調整を担います。コーディング標準、アーキテクチャパターン、ソフトウェアエンジニアリングのペルソナは持ちません。担うのは、どの役割を何人割り当てるか、並列か逐次か、対立をどう解決するか、フェーズをいつ移行するかといった、調整に関する判断です。エンジニアリングに関する判断はsoftware-engineerスキルが担います。これは、あらゆるコーディングエージェントに適用されるアーキテクト／開発者／レビュアーの専門家であり、基盤となるエンジニアリングレイヤーです。

ルール：コードを書く、更新する、またはレビューするすべてのエージェントに、software-engineerスキルを割り当てます。 エージェントはそのスキルを読み、基準（Three Lenses、Eight Standards、ドメインごとの実践、レビューゲート）を体現します。team-executorがそれらの基準を独自に記述することは、今後ありません。

優雅な機能縮退（存在する場合に優先）。 team-executorは単独でインストールできますが、software-engineerが存在しない場合があります。team-executor向けにimplement-issueが採用しているものと同じ「存在する場合に優先」方式を使います。

• software-engineerがインストールされている場合（Step 2のスキルスキャンで~/.claude/skills/software-engineer/、.claude/skills/software-engineer/、../software-engineer/、/mnt/skills/software-engineer/、またはskills-lock.jsonのエントリーから検出された場合）：コーディング、アーキテクト、レビューを担当するすべてのエージェントに割り当てます。
• インストールされていない場合：本番環境で使える品質、セキュリティ、保守性、既存の規約との一貫性を重視した、簡潔な汎用インライン指示にフォールバックします。software-engineerにハード依存したり、存在しない場合に動作しなくなったりしてはなりません。

同梱リソース

ファイル	用途
agent-templates.md	ペルソナ構築フレームワークとすぐに使えるエージェントテンプレート
orchestration-workflow.md	エージェントの起動、出力の収集、対立の解決、フェーズの移行
scan-project.sh	エージェントのプロンプトに使うプロジェクトコンテキスト（ディレクトリ構造、設定、技術）を収集します
init-plan-dirs.sh	エージェントの出力先としてdocs/plans/ディレクトリ構造を初期化します

---

フェーズ1：計画

ステップ 1：入力を整理する

ユーザーの入力は、散在するアイデア、目標、要件、希望が混在したブレインダンプである可能性があります。まずは内容を理解してください。

入力を注意深く読み、構造化して解釈します。

1. 個別の目標を特定する — 絡み合ったアイデアを、個別の目的に分けます
2. 重複を取り除く — 冗長な項目や重複する項目を統合します
3. 不足を補う — 論理的に必要な不足情報を推測します（推測した内容にはその旨を明記します）
4. 論理的な流れを確立する — 依存関係と優先度に基づいて目標を並べます
5. 曖昧さを明確にする — 曖昧な表現を、具体的で実行可能な説明にします

整理した内容を docs/plans/goal-analysis.md に書き込みます。これは、すべてのエージェントが参照する正式な基準となります。

ステップ 2：利用可能なスキルを確認する

チームを編成する前に、利用可能なスキルをすべて確認し、どのような専門能力があるかを把握します。次の場所で SKILL.md ファイルを探してください。

• Claude Code のユーザースキル：~/.claude/skills/
• Claude Code のプロジェクトスキル：プロジェクトルートの .claude/skills/
• システムスキル：/mnt/skills/（Codex および類似プラットフォーム）
• インストール済みスキル：プロジェクトルートに skills-lock.json がある場合は確認します

# Discover skills across all known locations
for dir in ~/.claude/skills .claude/skills /mnt/skills; do
  find "$dir" -name "SKILL.md" -type f 2>/dev/null
done

各 SKILL.md のフロントマター（name と description）を読み、能力の一覧を作成します。これらのスキルは、役立つチームエージェントに割り当てることができます。すべてのエージェントにスキルが必要なわけではありません。エージェントの役割に本当に合致する場合にのみ割り当ててください。

エンジニアリングの基盤レイヤーに注意してください。 スキャンで software-engineer が見つかった場合、これは特別です。コーディング、アーキテクト、レビューを担当するエージェントに付与するエンジニアリングの基盤レイヤーです（役割固有の適合スキルではなく、コードに触れるすべてのエージェントが満たすべきエンジニアリング基準です）。見つかった場合は、該当するエージェントに割り当ててください。見つからない場合は、「Engineering Is Delegated, Not Embedded」で説明されている簡略版のインライン指示を使用します。スタック／SDK スキル（heroui、drizzle-orm、temporal など）は引き続き役割固有のオーバーレイとして、その上に割り当てます。

ステップ 3：R&D が必要かどうかを判断する

計画を始める前に調査が必要な目標もあります。次の点を確認してください。

• チームが十分に把握していない可能性がある技術、API、ツールへの言及
• 調査が必要な曖昧な要件
• 外部システムとの統合箇所
• 不慣れな分野や専門知識が必要な領域

R&D が必要な場合は、最初に R&D エージェントを起動します（R&D エージェントのテンプレートは agent-templates.md を参照してください）。R&D エージェントは次の作業を行います。

• コードベースとプロジェクトドキュメントを検索し、既存のパターンや規約を確認します
• 関連するドキュメントとソースファイルを読みます
• 技術的な実現可能性を調査します
• 調査結果を docs/plans/research/ に Markdown ファイルとして記録します

R&D の結果をもとに必要な専門家を判断するため、計画チームを編成する前に R&D の完了を待ちます。

Step 4: 計画チームを編成する

整理した目標と R&D の調査結果に基づき、3～7 人の専門エージェントからなるチームを作成します。各エージェントには、次の要素が必要です。

1. 具体的なペルソナ — 単なる役職ではなく、深い専門知識、意見、独自の視点を備えた完全な専門家像です。ペルソナの作成方法については、agent-templates.md を参照してください。

2. 明確な分析指示 — 目標のどの側面を評価する責任があるのかを明示します。

3. スキルの割り当て — ソフトウェア領域のエージェント（アーキテクト、バックエンド、フロントエンド、DevOps、QA、セキュリティ、データ）には、エンジニアリングスキルとして software-engineer を割り当てます。エージェントはこのスキルを読み、その基準に沿って行動します。team-executor がそれらの基準をインラインで記述する必要はなくなります。必要に応じて、役割に合ったスタック／SDK のオーバーレイスキルを 1 つ 追加します（heroui、drizzle-orm など）。基本のエンジニアリングレイヤーにオーバーレイを 1 つ追加します（agent-templates.md のスキル割り当てに関する例外を参照）。ソフトウェア領域以外のエージェントには、役割に真に適合するスキルがある場合に限り割り当てます。software-engineer がインストールされていない場合は、簡略化したインライン指示に切り替えます（「エンジニアリングは委任し、埋め込まない」を参照）。

4. プロジェクトのコンテキストへのアクセス — 関連するファイル、ドキュメント、整理済みの目標分析を提示します。

チーム構成では、必要なすべての視点をカバーします。一般的な構成例は次のとおりです。

• ソフトウェアプロジェクト：アーキテクト、バックエンドエンジニア、フロントエンドエンジニア、DevOps／インフラ担当、QA／テスト戦略担当
• データプロジェクト：データエンジニア、アナリスト、ML エンジニア、ドメインエキスパート
• コンテンツ／クリエイティブ：ストラテジスト、ライター、エディター、デザイナー、ドメインエキスパート
• インフラストラクチャ：システムアーキテクト、セキュリティエンジニア、SRE、ネットワークスペシャリスト
• 複合プロジェクト：必要に応じて複数の構成例から選びます

すべてのチームには、ほかのすべてのエージェントの意見を統合して最終計画を作成する プロジェクトリード エージェントが含まれます。

Step 5: 計画チームを実行する

すべての専門エージェントを起動します。各エージェントには、次のプロンプト構成を渡します（エージェントごとにカスタマイズしてください）。

You are [PERSONA_DESCRIPTION].

## Your Assignment

Analyze the following project goals from your area of expertise. Provide:

1. **Assessment** — your expert evaluation of the goals as they relate to your domain
2. **Approach** — the specific technical/strategic approach you recommend
3. **Steps** — detailed, ordered steps for your domain's contribution
4. **Dependencies** — what you need from other team members
5. **Risks & Mitigations** — what could go wrong in your domain and how to prevent it
6. **Quality Standards** — what "production-ready" means for your deliverables
7. **Critical Details** — things that are easy to overlook but essential to get right

## Project Goals
[INSERT contents of docs/plans/goal-analysis.md]

## Project Context
[INSERT relevant file paths, existing code structure, docs, etc.]

## Engineering Skill (software-domain agents)
Read and follow the `software-engineer` skill before starting — it is your
engineering base layer (architect/developer/reviewer SME): [SOFTWARE_ENGINEER_PATH]
(If `software-engineer` is not installed, this slot is replaced by a short inline
instruction: build/recommend for production-readiness, security, maintainability,
and consistency with existing project conventions.)

## Available Skill (if assigned)
Read and follow: [STACK_OVERLAY_SKILL_PATH]

## Important
- Your output must be actionable by a coding agent — no vague advice
- Assume the executor has no context beyond what you provide
- Specify exact file paths, commands, configurations, and code patterns
- Reference existing project code/patterns when relevant
- Everything you recommend must result in production-ready output
- Do NOT include timelines, deadlines, or time estimates

## Execution Model
The implementation will be carried out by coding agents. Human time, speed, and effort estimates DO NOT apply — do not shy away from a more robust solution because a human would find it slow. Account for risk, security, maintainability, and consistency with existing project conventions. Prefer the most robust, well-engineered option that uses existing tooling/styles/components. Do not introduce parallel patterns when an existing one fits.

Step 6: 実行計画にまとめる

すべてのエージェントから報告を受け取ったら、プロジェクトリード エージェントが内容を統合し、単一の実行計画にまとめます。プロジェクトリードを別途起動していない場合は、自分で統合します。

統合の手順は次のとおりです。

1. すべてのエージェントの出力を収集する — 各エージェントの分析をすべて読みます。
2. 意見の相違を解決する — エージェント間で意見が異なる場合は、全体の目標に最も適した方法を選び、その理由を記録します。判断基準は、リスク、セキュリティ、保守性、既存の規約との一貫性です。優れた方法のほうが「作業量が多い」という理由で、より劣る方法に格下げしてはいけません。計画を実行するのはコーディングエージェントであり、人間の作業コストは判断基準になりません。
3. 依存関係を統合する — 統一された依存関係グラフを作成します。
4. 実行順序を決める — すべての領域の手順を、論理的な実行順序に並べます。
5. 重複を排除する — 複数のエージェントが個別に提案した重複手順を取り除きます。
6. 統合ポイントを追加する — 異なるエージェントの作業が連携する箇所に、明示的な統合手順を追加します。

Step 7: ソフトウェア開発のレビューゲート

プロジェクトにソフトウェア開発（コード、API、インフラストラクチャなど）が含まれる場合は、最終決定の前にレビューゲートエージェントを 1 つ追加で起動します。team-executor はレビュアーの基準を備えていません。それらは software-engineer に含まれています。

推奨（software-engineer がインストールされている場合）。 レビューゲートエージェントを起動し、software-engineer スキルを割り当てます。ドラフト計画をレビュー待ちの差分とみなし、レビュアーの視点（../software-engineer/references/review-gate.md）を適用するよう指示します。

You are a review-gate agent. Read and follow the `software-engineer` skill,
and apply its Reviewer Lens to the draft execution plan below:
[SOFTWARE_ENGINEER_PATH] — specifically references/review-gate.md.

## Your Task
Treat the draft plan as a diff awaiting review. For each section:
1. Flag anything that would not survive the review gate / would not pass a
   production code review
2. Add missing steps an experienced engineer would expect
3. Strengthen vague instructions with specific implementation details
4. Verify the plan follows existing project patterns (check the codebase)

The agents executing this plan will follow it literally. Be constructive but thorough.

## Execution Model
This plan will be executed by coding agents, not humans. Do NOT recommend
simpler/weaker approaches on the grounds that the robust option is "too much
work" or "would take a human too long." Flag issues only on risk, security,
maintainability, scalability, or convention grounds. If the plan picks a
less-robust approach to save effort, push back and recommend the stronger one.

## Execution Plan
[INSERT the draft plan]

## Project Codebase
[INSERT relevant file tree and key files]

代替方法（software-engineer がインストールされていない場合）。 同じレビューゲートエージェントを起動し、スキル割り当ての代わりに次の短いインライン指示を与えます。その際、上記の実行モデルの段落は残してください。

Review the draft execution plan as if it were a diff awaiting a demanding
production review. Flag anything that would not ship: gaps in
production-readiness, security, maintainability, or consistency with existing
project conventions. Add missing steps, make vague instructions specific, and
verify the plan follows existing project patterns (check the codebase).

このレビュアーのフィードバックを最終計画に反映します。

ステップ 8：最終計画を作成する

以下の構成で、最終計画を docs/plans/execution-plan.md に作成します。

# Execution Plan: [Project Title]

## Overview
[2-3 sentence summary of what this plan accomplishes]

## Goals
[Numbered list of concrete objectives from the goal analysis]

## Architecture / Approach
[High-level approach with key decisions and their rationale]

## Execution Steps

### Phase N: [Phase Name]

#### Step N.M: [Step Name]
**Objective**: [What this step accomplishes]
**Details**:
[Specific, detailed instructions — file paths, code patterns, configs, commands]
**Inputs**: [What this step needs]
**Outputs**: [What this step produces]
**Quality Criteria**: [How to verify this step is done correctly]

[Repeat for all steps...]

## Integration Points
[Where different components connect and how to verify integration]

## Quality Assurance
[Testing strategy, validation steps, acceptance criteria]

## Risk Register
[Known risks and their mitigations]

## File Structure
[Expected project structure after execution]

この計画には、次の特性があります。

• 自己完結型 — 事前のコンテキストがないエージェントでも実行できます
• 具体的 — 正確なファイルパス、コードパターン、コマンドの実行順序が記載されています
• 順序立てられている — 依存関係に基づいて手順が並んでいます
• 検証可能 — 各手順に明確な完了条件があります
• 本番品質 — 出力がプロフェッショナルな基準を満たしています
• タイムラインなし — 日付、期限、所要時間の見積もりは一切含まれていません
• 工数に左右されない — 計画の決定では、人間の作業コストではなく、リスク、セキュリティ、保守性、慣例との適合性を重視し、迅速な妥協案ではなく、より優れた堅牢な解決策を選択します

---

フェーズ 2：実行

フェーズ 2 では、まったく新しいエージェントチームを使用します。エージェントが受け取るのは実行計画とプロジェクトのコンテキストのみで、フェーズ 1 の検討履歴は受け取りません。これにより、計画フェーズの先入観に左右されずに実行できます。

ステップ 9：実行チームを編成する

docs/plans/execution-plan.md を読み、計画のフェーズと手順に基づいて実行エージェントを作成します。各実行エージェントは、次の条件を満たします。

1. 担当範囲が明確 — 特定のフェーズ、または関連する一連の手順を担当します
2. 完全なペルソナを備えている — 実施する作業に合った専門家としての役割を持ちます（agent-templates.md を参照）
3. 適切なスキルを備えている — 作業に合ったスキルを割り当てます。コードの作成、更新、レビューを行うエージェントには、計画時と同様に software-engineer を 基本となるエンジニアリングレイヤー として割り当てます（必要に応じてスタックまたは SDK のオーバーレイを 1 つ追加できます）。実際に開発を担うのは実行エージェントであるため、ここでエンジニアリングの基準が適用されます。software-engineer がインストールされていない場合は、簡潔にしたインライン指示にフォールバックします（「Engineering Is Delegated, Not Embedded」を参照）。
4. 自律的に動作する — プロジェクトのコンテキストに基づいて、すべての判断を独立して行います

実行チームのプロンプト構成：

You are [PERSONA_DESCRIPTION].

## Your Mission
Execute the following steps from the project execution plan. Work autonomously
and make all decisions yourself — do not wait for or request human input.

## Decision-Making Guidelines
- Root all decisions in the existing project code, docs, and conventions
- When multiple valid approaches exist, choose the one most consistent with the codebase
- If you encounter ambiguity, choose the most production-appropriate option
- Document significant decisions as code comments or in docs/
- You are a coding agent, not a human — do not cut corners or pick a weaker approach because the robust one would take "a long time." Optimize for risk, security, maintainability, and consistency. Effort cost is not a constraint.

## Steps to Execute
[INSERT relevant steps from execution-plan.md]

## Project Context
[INSERT relevant file paths, existing patterns, dependencies]

## Engineering Skill (if this agent writes/updates/reviews code)
Read and follow the `software-engineer` skill before starting — it is your
engineering base layer (architect/developer/reviewer SME): [SOFTWARE_ENGINEER_PATH]
(If `software-engineer` is not installed, this slot is replaced by a short inline
instruction: build for production-readiness, security, maintainability, and
consistency with existing project conventions.)

## Available Skill (if assigned)
Read and follow: [STACK_OVERLAY_SKILL_PATH]

## Critical Requirements
- All output must be production-ready — no TODOs, no placeholders, no stubs
- Follow existing project conventions and patterns
- Meet the engineering bar defined by the `software-engineer` skill (or the inline fallback above) for code quality — error handling, clarity, and maintainability are defined there, not here
- Run and verify your work before considering a step complete
- If a step depends on another agent's output, check for it and adapt as needed

ステップ 10：実行する

すべての実行エージェントを起動します。主な原則は次のとおりです。

1. 可能な場合は並列実行 — 独立した手順を担当するエージェントは、同時に実行できます
2. 必要な場合は順次実行 — 計画にある依存関係の順序を守ります
3. 人間の入力なし — エージェントはプロジェクトのコンテキストを使って、すべての判断を自律的に行います
4. 作業中に検証 — 各エージェントは作業内容を検証します（テストの実行、リンターの実行、出力の確認）

ステップ 11：統合と検証

すべての実行エージェントが完了したら、最終的な統合確認を行います。

1. すべての出力が存在することを確認 — 計画にあるすべての成果物が作成されたことを確認します
2. 統合チェックを実行 — プロジェクトにテストがあれば実行し、ビルドがあればビルドします
3. 整合性を確認 — 各エージェントの出力に互換性があることを確認します
4. 統合上の問題を修正 — 問題があれば、対象を絞ったエージェントを起動して解決します
5. 最終的な品質チェック — 結果が計画の品質基準を満たしていることを確認します

ステップ 12：報告する

完了報告を docs/plans/execution-report.md に作成します。

# Execution Report: [Project Title]

## Summary
[What was accomplished]

## Completed Steps
[List of all executed steps with status]

## Key Decisions Made
[Significant autonomous decisions and their rationale]

## Files Created/Modified
[Complete list of all changes]

## Verification Results
[Test results, build status, integration check outcomes]

## Known Limitations
[Anything that couldn't be fully resolved]

## Next Steps (if any)
[Remaining work that requires human input or was out of scope]

---

エージェントの起動

オーケストレーターは、プラットフォームのエージェント／サブエージェント機能を使用してエージェントを起動します。プラットフォーム固有の起動方法（Claude Code Agent tool、Codex のサブエージェント、順次実行へのフォールバック）については、orchestration-workflow.md を参照してください。

起動に関する主な原則：

• 計画エージェントは並列実行します — それぞれ独立して分析します
• R&D エージェントは計画エージェントより先に実行します — 得られた知見をチーム編成に反映します
• 実行エージェントは依存関係グラフに従います — 独立した手順は並列実行し、依存する手順は順次実行します
• 統合エージェントはすべての実行エージェントの完了後に実行します

オーケストレーターへのガイダンス

オーケストレーターの役割は、世界トップクラスのチームを編成し、指揮する CTO のようなものです。必要な専門知識を見極め、適切な人材を集め、明確な任務を与え、その成果を統合します。

豊かなペルソナほど、より良い成果を生みます。 エージェントのペルソナが具体的で明確な意見を持つほど、分析と実行の質が高まります。「バックエンド開発者」では一般的な助言しか得られません。一方、「大規模な本番環境の障害をデバッグした経験があり、冪等な操作とサーキットブレーカーにこだわる分散システムエンジニア」なら、実戦で培われた助言が得られます。

まずプロジェクトを読みましょう。 チームを編成する前に、既存のものを把握してください。プロジェクトの構成、主要なソースファイル、既存のドキュメント、設定を確認します。このコンテキストは、関連性の高いエージェントや現実的な計画を作成するうえで不可欠です。

計画策定には、3～5人のエージェントが最適です。 エージェントを増やすほど、統合の作業と意見の食い違いが生じる可能性が増えます。明確に異なる視点をもたらす場合に限り、エージェントを追加してください。

フェーズ 2 では、新しいコンテキストが与えられます。 これは意図的なものです。実行エージェントは、計画を立てるまでの複雑な議論ではなく、計画に従います。計画がフェーズ 1 とフェーズ 2 の間のインターフェースとなります。

人間の作業量ではなく、堅牢性を重視してください。 計画を実行するのはコーディングエージェントです。リスク、セキュリティ、保守性、規約との不一致を理由に解決策を退けるのは構いませんが、人間にとって「作業量が多い」という理由で退けてはいけません。チームが有能ではあるものの保守的な計画を作成した場合は、より優れた選択肢を検討するよう促してください。このスキルの目的は、コーディングエージェントによる実行によって、通常ソフトウェアチームを制約する労力やスコープの上限を取り払うことです。