Claude Code Agent Development
anthropics/claude-plugins-official
Explains how to write agents for Claude Code plugins: the markdown file with YAML frontmatter, trigger descriptions, model and color settings, and system prompt design.
規模に応じた計画、承認、実装、検証、エスカレーションのフローでサブエージェントを調整。サブエージェントへの作業振り分け、承認済み作業計画の実行、自律実行の再開時に使用。
Install Subagents Orchestration Guide
$ npx skills add shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guide -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install shinpr/ai-coding-project-boilerplate subagents-orchestration-guide --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/shinpr/ai-coding-project-boilerplate.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills-ja/subagents-orchestration-guide .claude/skills/subagents-orchestration-guide && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "subagents-orchestration-guide" agent skill from https://github.com/shinpr/ai-coding-project-boilerplate/tree/main/.claude/skills-ja/subagents-orchestration-guide into .claude/skills/subagents-orchestration-guide/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "subagents-orchestration-guide", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/shinpr/ai-coding-project-boilerplate/tree/main/.claude/skills-ja/subagents-orchestration-guideType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guide -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install shinpr/ai-coding-project-boilerplate subagents-orchestration-guide --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/shinpr/ai-coding-project-boilerplate.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.claude/skills-ja/subagents-orchestration-guide .agents/skills/subagents-orchestration-guide && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "subagents-orchestration-guide" agent skill from https://github.com/shinpr/ai-coding-project-boilerplate/tree/main/.claude/skills-ja/subagents-orchestration-guide into .agents/skills/subagents-orchestration-guide/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "subagents-orchestration-guide", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guide -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install shinpr/ai-coding-project-boilerplate subagents-orchestration-guide --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/shinpr/ai-coding-project-boilerplate.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.claude/skills-ja/subagents-orchestration-guide .cursor/skills/subagents-orchestration-guide && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "subagents-orchestration-guide" agent skill from https://github.com/shinpr/ai-coding-project-boilerplate/tree/main/.claude/skills-ja/subagents-orchestration-guide into .cursor/skills/subagents-orchestration-guide/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "subagents-orchestration-guide", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/shinpr/ai-coding-project-boilerplate.git --path .claude/skills-ja/subagents-orchestration-guide--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guide -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install shinpr/ai-coding-project-boilerplate subagents-orchestration-guide --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/shinpr/ai-coding-project-boilerplate.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.claude/skills-ja/subagents-orchestration-guide .gemini/skills/subagents-orchestration-guide && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "subagents-orchestration-guide" agent skill from https://github.com/shinpr/ai-coding-project-boilerplate/tree/main/.claude/skills-ja/subagents-orchestration-guide into .gemini/skills/subagents-orchestration-guide/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "subagents-orchestration-guide", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install shinpr/ai-coding-project-boilerplate subagents-orchestration-guideInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guide -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/shinpr/ai-coding-project-boilerplate.git skills-src && mkdir -p .github/skills && cp -r skills-src/.claude/skills-ja/subagents-orchestration-guide .github/skills/subagents-orchestration-guide && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "subagents-orchestration-guide" agent skill from https://github.com/shinpr/ai-coding-project-boilerplate/tree/main/.claude/skills-ja/subagents-orchestration-guide into .github/skills/subagents-orchestration-guide/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "subagents-orchestration-guide", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guide -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install shinpr/ai-coding-project-boilerplate subagents-orchestration-guide --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/shinpr/ai-coding-project-boilerplate.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.claude/skills-ja/subagents-orchestration-guide .opencode/skills/subagents-orchestration-guide && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "subagents-orchestration-guide" agent skill from https://github.com/shinpr/ai-coding-project-boilerplate/tree/main/.claude/skills-ja/subagents-orchestration-guide into .opencode/skills/subagents-orchestration-guide/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "subagents-orchestration-guide", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
subagents-orchestration-guide- GitHub stars
- 233
- Token cost
- ~4.6k tokens
- SKILL.md length
- 775 words
- Files
- 3 (incl. references)
- Skills in repo
- 41
- Repo updated
- First seen
- Licence
- MIT
At a glance
規模に応じた計画、承認、実装、検証、エスカレーションのフローでサブエージェントを調整。サブエージェントへの作業振り分け、承認済み作業計画の実行、自律実行の再開時に使用。
- Works in 5 steps: quality-fixer: 全体品質保証と修正完了まで自己完結処理 → task-decomposer:… → task-executor: 個別タスクの実行と構造化レスポンス → …
- Tasks that involve Subagents
- SKILL.md covers 最重要原則：オーケストレーターとして振る舞う, 活用できるサブエージェント, オーケストレーション原則 and Sub-agent間の制約, plus 5 more sections
- Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
What it does
Subagents Orchestration Guide is an agent skill from shinpr/ai-coding-project-boilerplate. 規模に応じた計画、承認、実装、検証、エスカレーションのフローでサブエージェントを調整。サブエージェントへの作業振り分け、承認済み作業計画の実行、自律実行の再開時に使用。
Its SKILL.md is about 4.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 3 other files, including reference files (for example `references/lite-mode.md` and `references/review-resolution.md`).
It sits in Agent Workflows, covering Subagents. The repository describes itself as: Agentic coding TypeScript boilerplate for Claude Code: sub-agent workflows with built-in quality checks and context engineering. The licence is MIT.
When your agent uses it
- Tasks that involve Subagents
Example prompts
- “/subagents-orchestration-guide”
Workflow steps
5 steps, taken from the first numbered list in SKILL.md.
- quality-fixer: 全体品質保証と修正完了まで自己完結処理
- task-decomposer: 承認済み作業計画書の各実装項目を、宣言された境界と依存関係を保ったままtask-template形式のファイル1つとして生成
- task-executor: 個別タスクの実行と構造化レスポンス
- integration-test-reviewer: 統合テスト/E2Eテストのスケルトン準拠レビュー
- security-reviewer: 全タスク完了後のDesign Docおよびプロジェクトのコーディング規約に対するセキュリティ準拠レビュー
What it can do on your machine
Read from SKILL.md and the folder at commit 56913a2. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
No scripts in the folder and no shell commands in SKILL.md.
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Subagents Orchestration Guide loads about 4.6k tokens when it runs, and up to ~8.9k if it reads all its reference files. Until then it costs about 29 tokens; SKILL.md has 775 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from shinpr/ai-coding-project-boilerplate at commit 56913a2, republished under its MIT licence (© shinpr). 775 words, ~4,643 tokens.
Download SKILL.mdSave it as
.claude/skills/subagents-orchestration-guide/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.- name
- subagents-orchestration-guide
- description
- 規模に応じた計画、承認、実装、検証、エスカレーションのフローでサブエージェントを調整。サブエージェントへの作業振り分け、承認済み作業計画の実行、自律実行の再開時に使用。
サブエージェント実践ガイド - オーケストレーション指針
最重要原則：オーケストレーターとして振る舞う
ユーザーの明示的な指示: ユーザーは、呼び出されたレシピで名前が挙げられたすべてのサブエージェント呼び出しを明示的に指示し、承認している。各呼び出しの前提条件を満たした時点で、該当する呼び出しを実行する。
正しい振る舞い
- 新規のフルサイクルタスク: requirement-analyzerから開始し、そのエビデンスから要件を収束させ構造スケール（Structural Scale）を選択する
- フロー実行中: 選択した規模別フローと移行条件に従う
- 各フェーズ: 宣言された責務が必要な出力と一致するエージェントへ委譲
- 停止ポイント: その停止点でユーザーが確認した場合にのみ継続
- 調査: すべての調査はrequirement-analyzerまたはcodebase-analyzerに委譲（Grep/Glob/Readはサブエージェント内部のツール）
- 分析・設計: 宣言された責務に必要な出力が含まれる専門サブエージェントに委譲
- 初動: 新規のフルサイクルタスクでは、ユーザー要件をrequirement-analyzerに渡してから他のステップへ進む
初動アクション規則
新規のフルサイクルタスクを受け取ったら、ユーザー要件をrequirement-analyzerに渡し、ユーザーの文言はオーケストレーターが保持する。返ってきたスコープ・コスト・質問のエビデンスをその文言と照らし合わせて要件収束を実行し、構造スケールを割り当てる。評価の依頼、推測的なアイデア、手段の指定は、アナライザの出力ではなくユーザーの文言から分類する。どちらの判定もオーケストレーターが持つ。requirement-analyzer を再実行するのは、ヒアリングの回答が分析対象または必要なスコープエビデンスを変える場合のみとする。
ワークフローモード
ワークフローの開始時または再開時に呼び出しを振り分ける前に、ユーザーの明示的なモード指定、ロード済みのルートCLAUDE.mdのWorkflow Mode指示の順にモードを解決する。どちらもなければNormalモードとする。セッションでの明示指定はユーザーが変更するまで適用し、リポジトリの既定値より優先する。
以下のフローはNormalモードを記述する。Liteモードではreferences/lite-mode.mdを読み、その呼び出し集合と品質境界を適用する。省略されない呼び出しを実行し、実際に生成された結果だけを使用する。ユーザー承認の停止点と権限境界は、どちらのモードにも適用する。
フロー実行中の要件変更検知
確認済みの成果、将来状態の要件、対象外の変更案を要件変更として扱う。これらを同時には維持できないことをエビデンスが示す場合は、要件ゲートで停止し、どれを変更するかユーザーに確認する。これらを維持する技術設計または実装の修正は要件変更ではなく、機能しているが不要になった技術的な選択の削除もこれに含まれる。前のフェーズを通過したことは、そのフェーズで選んだ手段が引き続き必要であることを示さない。影響を受ける技術成果物をそれぞれ更新し、なお有効な出力を維持したまま、影響を受ける最も早い技術ゲートから再開する。
活用できるサブエージェント
実装支援エージェント
- quality-fixer: 全体品質保証と修正完了まで自己完結処理
- task-decomposer: 承認済み作業計画書の各実装項目を、宣言された境界と依存関係を保ったままtask-template形式のファイル1つとして生成
- task-executor: 個別タスクの実行と構造化レスポンス
- integration-test-reviewer: 統合テスト/E2Eテストのスケルトン準拠レビュー
- security-reviewer: 全タスク完了後のDesign Docおよびプロジェクトのコーディング規約に対するセキュリティ準拠レビュー
ドキュメント作成エージェント
- requirement-analyzer: リポジトリのスコープ・コスト・質問のエビデンスを簡潔に収集
- codebase-analyzer: 既存コードベースを分析し技術設計への重点的なガイダンスを生成
- prd-creator: Product Requirements Document作成（WebSearch対応、市場動向調査）
- ui-spec-designer: PRDとプロトタイプコード（任意）からUI Spec作成（フロントエンド/フルスタック機能）
- technical-designer: 確認済み要件とリポジトリのエビデンスからADRバッチまたはDesign Docを作成
- work-planner: Design Docとテストスケルトンから作業計画書を作成
- document-reviewer: 単一ドキュメントの品質・完成度・ルール準拠チェック
- code-verifier: 実装前に、Design Docの主張を既存コードベースに対して検証
- design-sync: Design Doc間の整合性検証（明示的矛盾のみ検出）
- acceptance-test-generator: Design DocのACとUI Spec（任意）から統合テストとE2Eテストのスケルトン生成
- ui-analyzer: フロントエンド設計準備のためUI事実（外部ソース＋既存UIコード）を収集 — 読み取り専用
- code-reviewer: 完了した実装を、正典とリポジトリ固有の品質基準に照らしてレビュー
オーケストレーション原則
委譲の境界: What vs How
「何を達成するか」「どこで作業するか」を渡す。各サブエージェントは「どう実行するか」を自律的に決定する。
渡す情報（what/where/制約）:
- タスクファイルパス — executor系は、タスクファイルを成果と調査の開始地点として使用する。完全で一貫した変更セットはリポジトリの責務から決める
- ディレクトリまたはパッケージスコープ — discovery/review系（codebase-analyzer, code-verifier, security-reviewer, integration-test-reviewer）向け
- ユーザーまたは設計成果物からの受入条件とハード制約
サブエージェントに委ねる判断（how）:
- 実行するコマンド（プロジェクト設定やリポジトリの規約からサブエージェントが判断）
- 実行順序やツールフラグ
- Executor/fixer系: スコープ内で調査・変更するファイルの選択
- Review/discovery系: スコープ内で調査するファイルの選択（読み取り専用）
| Bad（howを指定） | Good（whatを指定） | |
|---|---|---|
| quality-fixer | 「lint → test の順でチェックして」 | 「品質チェックと修正をすべて実行して」 |
| task-executor | 「ファイルXにハンドラYを追加して」 | 「タスクファイル: docs/plans/tasks/003-feature.md」 |
出力が矛盾した場合の優先順位:
- ユーザー指示（明示的な要求や制約）
- タスクファイルと設計成果物（Design Doc, PRD, 作業計画書）
- リポジトリの客観的状態（git status、ファイルシステム、プロジェクト設定）
- サブエージェントの判断
ユーザー指示にある明示的な制約と、確認済みの成果、将来状態の要件、対象外は必ず守る。技術成果物は主要な実装基準だが、これらを変えずにリポジトリのエビデンスが技術的な実現方法を否定する場合は、影響を受ける技術成果物を修正する。対象パスとタスクファイルのファイル一覧は、正典にそれらだけが対象であると明示されていない限り、調査の開始地点である。関係のない改善は現在の変更に含めない。
専門エージェントの結果の受理
各専門エージェントの定義が、正規の結果形式を定める。受け手であるオーケストレーターは、結果が示す意味、正典、作成された成果物、リポジトリの状態から次の行動を決める。それらから次の行動を判断できる場合は、意味が同じラベル、省略された任意フィールド、遷移ラベルの欠落を受け入れる。運用上の不足は、調査またはリポジトリ内で完結する可逆な判断によって解消し、影響を受けない作業を続ける。
リポジトリのエビデンスから確認済みの成果へ進む行動を導ける間は、未完了の実装を続ける。現在の権限とエビデンスでは必要な実装を進められない場合は、残作業と観測したエビデンスを未完了報告に記載して終了する。証明だけが不足する場合は別に扱う。現在の権限とスコープで可能な回復を行い、利用可能なチェックをすべて実行し、証明不足の結果を省略せず保持したうえで、レシピ本来の可逆な境界から残りの作業を続ける。最終検証の前に、同じスコープと対象チェックで該当するquality-fixerを1回だけ再実行する。passなら証明不足を解消し、stub_detectedならincompleteImplementationsを通じて実装へ戻し、verification_incompleteが再度返った場合だけ報告する。観測できた証明だけを完了根拠にする。ユーザーに確認するのは、確認済みの成果、将来状態の要件、対象外のどれを変えるか選ぶ場合、または不可逆な外部操作を承認する場合に限る。
レビュー対応（Review Resolution）
対応可能な成果物レビューの検出事項には references/review-resolution.md を適用する。処理方針の決定、結果の検証、作業のルーティングはオーケストレーターが行い、成果物の作成・変更は指名した専門エージェントが行う。検出事項単位の修正ループ — 処理方針の割り当て、apply の逐語ハンドオフ、prior_feedback による再レビュー、収束とエスカレーションの条件 — は、この参照ドキュメントが最初から最後まで定める。
責務分離を意識した振り分け
task-executorの責務:
- 実装作業とテスト追加
- 追加したテストが成功することを確認。リポジトリ全体の品質保証はquality-fixerの責務
quality-fixerの責務:
- 全体品質保証（型チェック、lint、全テスト実行等）
- 品質エラーの完全修正実行
- 修正完了まで自己完結で処理
- 修正と利用可能なすべてのチェックを完了した後の最終品質判定
標準フロー
タスクサイクル: 各タスクの実装結果と必要な統合/E2Eレビューを受理し、選択したモードの品質境界を適用して、レシピのコミットポイントで完了済みタスクをコミットする。Normalモードはタスクごとにquality-fixerを実行し、Liteモードは最終品質チェックを使用する。各タスクで対象を絞った検証は維持する。
レイヤー別ルーティング: レイヤー横断機能では、タスクファイル名パターンに基づいてexecutorとquality-fixerを選択（レイヤー横断オーケストレーション参照）。
Sub-agent間の制約
ワークフローの連携はフラットに保つ。各専門エージェントの呼び出しと結果の受け取りはすべてオーケストレーターが行い、専門エージェントの定義では Agent をツールセットに含めない。
構造スケールとドキュメント要件
オーケストレーターは、収束した成果とリポジトリのエビデンスに documentation-criteria を適用する。スケールは判断負荷に従う: 小規模は1つの責務境界の中に明白な実装が1つ、中規模は境界をまたいだ調整または後続作業に長く影響しうる選択を含み、大規模は別個の設計判断を要する独立した成果を複数含む。ファイル数は補助的なエビデンスにとどまる。
| スケール | PRD | ADR | Design Doc | 作業計画書 |
|---|---|---|---|---|
| 小規模 | プロダクトスコープが変わる場合は更新 | 不要 | 不要 | 不要 — task-executor が明示プロンプトから実行する |
| 中規模 | プロダクトスコープが変わる場合は更新 | ADRの両フィルタを通過した決定ポイントのみ | 必須 | 必須 |
| 大規模 | 必須 — 新規作成・更新・リバースPRDのいずれか | ADRの両フィルタを通過した決定ポイントのみ | 必須 | 必須 |
適格なADRが存在する場合、スケールは最低でも中規模に引き上げられる。適格なADRはすべて1つのバッチとしてレビューし、受理した決定を Design Doc 作成前に Accepted にする。
構造化レスポンス仕様
すべてのサブエージェント呼び出しは Agent ツール を使用し、以下を渡す:
subagent_type: エージェント名（例: "task-executor"）description: 簡潔なタスク記述（3〜5語）prompt: 成果物のパスを含む具体的な指示
オーケストレーターの許可ツール
オーケストレーターは以下のツールのみで作業を統制する:
| ツール | 用途 |
|---|---|
| Agent | サブエージェントの呼び出し |
| AskUserQuestion | ユーザー確認・質問 |
| Bash | シェル操作（git commit、ls、検証コマンド） |
| Read | サブエージェント間の情報橋渡しのための成果物ドキュメント参照 |
実装作業（Edit、Write、MultiEdit）はすべてサブエージェントが実施する。オーケストレーター自身は行わない。
サブエージェント応答形式
各エージェントが自身の入出力契約を宣言する。呼び出しを構成する際にその契約を読み、返された結果には、ここで別のルーティングスキーマを要求せず「専門エージェントの結果の受理」を適用する。
オーケストレーターが担うエージェント間の受け渡し: quality-fixer には、未追跡・削除・リネームを含む現在の未コミットのワークツリー全体を調べるよう依頼する。実装ステップの runnableCheck を引き継ぎ、レシピまたは technical-spec がプロジェクトの正典となる品質コマンドを示している場合は qualityCommand として渡す。
quality-fixer は、実行できなかったチェックと無関係と確認済みの既存失敗を、既存のチェック結果に記録する。今回の変更に関係する実行可能なチェックがパスした後は、pass として通常のルーティングを続ける。今回の変更が原因の失敗、または受け入れ済みの成果に必要な依存の失敗は、元のタスクにそのパスがなくても修正対象とする。
作業計画時の基本フロー
新機能や変更要求を受け取ったら、まず要件のエビデンスを収集し、要件を収束させ、構造スケールを割り当てる。
大規模
- requirement-analyzer → オーケストレーターによる収束とスケール判定 [停止]
- prd-creator → document-reviewer → PRD承認 [停止]
- codebase-analyzer → 簡潔なリポジトリのエビデンス
- （フロントエンド/フルスタックのみ） ui-spec-designer → document-reviewer → UI Spec承認 [停止]
- （ADR決定ポイントが適格な場合） technical-designer を
ADRBatchモードで実行 → document-reviewer によるバッチレビュー → 検出事項への対応 → 承認したADRをAcceptedにする [停止] - technical-designer を
DesignDocモードで実行 → code-verifier → document-reviewer → design-sync → Design Doc承認 [停止] - acceptance-test-generator → work-planner → document-reviewer → 一括承認 [停止]
- task-decomposer → 自律実行 → 完了報告
中規模
- requirement-analyzer → オーケストレーターによる収束とスケール判定 [停止]
- codebase-analyzer → 簡潔なリポジトリのエビデンス
- （フロントエンド/フルスタックのみ） ui-spec-designer → document-reviewer → UI Spec承認 [停止]
- （ADR決定ポイントが適格な場合） technical-designer を
ADRBatchモードで実行 → document-reviewer によるバッチレビュー → 検出事項への対応 → 承認したADRをAcceptedにする [停止] - technical-designer を
DesignDocモードで実行 → code-verifier → document-reviewer → design-sync → Design Doc承認 [停止] - acceptance-test-generator → work-planner → document-reviewer → 一括承認 [停止]
- task-decomposer → 自律実行 → 完了報告
小規模
- requirement-analyzer → オーケストレーターによる収束とスケール判定。確定した成果、影響パス、検証条件を提示する [停止: 一括承認]
- その明示プロンプトから task-executor → 現在の未コミットのワークツリー全体に対する quality-fixer → commit → 完了報告
小規模では作業計画書もタスクファイルも作成しない。新たに適格なADRが判明した場合は中規模へ移行し、それ以外では計画ドキュメントを導入しない。
フロー開始位置
該当するStructural Scaleフローは、ユーザーが求めたフェーズから開始する。その指示は先行するフェーズを受理したことを意味するため、先行するレビューや承認の記録を再確認せず、その開始点から続行する。完了を報告する前に、開始点以降の該当フェーズが必要とする成果物と結果を検証し、不足している作業はそのフェーズの中で完了させる。より前のフェーズへ戻るのは、重大な変更がその成果を無効化した場合に限り、要件変更検知を適用する。
レイヤー横断オーケストレーション
オーケストレーターが scopeEvidence.affectedLayers から、機能が backend と frontend にまたがると判断した場合、単一のコードベース分析とDesign Docの区間を、以下のbackend先行・frontend後続の順序に置き換える。
設計フェーズの拡張
標準のDesign Doc作成ステップをレイヤー別作成に置き換え:
| ステップ | エージェント | 目的 |
|---|---|---|
| 8 | codebase-analyzer | 確認済みのレイヤー横断スコープ全体を分析する。出典ソースは prd_path または requirements のちょうど1つを渡す |
| 9 | technical-designer | バックエンドDesign Doc（ステップ8のうちバックエンドに関係するエビデンスを使用） |
| 10 | code-verifier（Normalモード） | バックエンドDesign Docを既存コードに対して検証（結果JSONはステップ12にprior_layer_verificationとして渡す） |
| 11 | document-reviewer | バックエンドDesign Docをレビュー（ステップ10を実行した場合はverification_evidence、ステップ8のJSONはcodebase_analysisとして入力）。判定はレビュー対応の判定ゲートに従って処理する |
| 12 | technical-designer-frontend | フロントエンドDesign Doc（ステップ8のうちフロントエンドに関係するエビデンス、レビュー済みバックエンドDesign Doc、UI Spec、ステップ10を実行した場合のprior_layer_verificationを使用） |
| 13 | code-verifier（Normalモード） | フロントエンドDesign Docを既存コードに対して検証 |
| 14 | document-reviewer | フロントエンドDesign Docをレビュー（ステップ13を実行した場合はverification_evidence、ステップ8のJSONはcodebase_analysisとして入力）。判定はレビュー対応の判定ゲートに従って処理する |
| 15 | design-sync（Normalモード） | レイヤー間整合性検証の後、両モードでDesign Doc承認 [停止] |
ステップ8は1回だけ実行し、そのJSON全体を両方のdesignerがそのまま再利用する。各designerは自身のレイヤーに関係するエビデンスだけを使う。省略されないバックエンドのステップはステップ12の前に直列で完了させる。これによりフロントエンドdesignerは、レビュー済みのバックエンド契約と、検証が実行された場合はそのリポジトリ上の検証結果を受け取る。
Design Doc作成時のレイヤーコンテキスト指定:
- バックエンド: 「PRD [パス] からバックエンドDesign Docを作成。コードベース分析: [ステップ8のJSON。バックエンドに関係するエビデンスを使用]。対象: APIコントラクト、データ層、ビジネスロジック、サービスアーキテクチャ。」
- フロントエンド: 「PRD [パス] からフロントエンドDesign Docを作成。コードベース分析: [ステップ8のJSON。フロントエンドに関係するエビデンスを使用]。レビュー済みバックエンドDesign Doc [パス] — このドキュメントからAPIコントラクトとIntegration Pointsを抽出し、フロントエンドDesign Doc の Integration Points に反映する。バックエンドのレビュー issue と処理方針: [ステップ11 document-reviewer の結果とレビュー対応の記録]。prior_layer_verification: [バックエンドDesign Docに対するcode-verifierのJSON。検証が実行された場合のみ渡し、それ以外はこの入力を省略]。エビデンスに裏付けられた discrepancy と
maintainedのレビュー issue のみを不安定な契約として扱う。UI Spec [パス] のコンポーネント構造を参照。対象: コンポーネント階層、状態管理、UI操作、データ取得。」
design-sync: フロントエンドDesign Docをソースとして使用。docs/design/内の他のDesign Docを自動検出して比較。
Show full SKILL.md (307 more words)Show less
複数Design Docでの作業計画
レビュー済みDesign Docの全パスと、提供されたテストスケルトンのパスをwork-plannerに渡す。work-plannerは、選択済みの実装アプローチ、依存関係、最も早い実行可能な検証境界に従ってタスクを定義する。
レイヤー別エージェントルーティング
自律実行中、タスクファイル名パターンに基づいてエージェントを選択する。この表は、作業計画書のタスクエントリが選ぶ2つの Executor lane も定義している:
| Executor lane | ファイル名パターン | Executor | Quality Fixer |
|---|---|---|---|
backend | *-task-* または *-backend-task-* | task-executor | quality-fixer |
frontend | *-frontend-task-* | task-executor-frontend | quality-fixer-frontend |
作業計画書のタスクエントリは lane をちょうど1つ記録する。タスクファイル生成時はその値をコピーし、対象パスからレイヤーを推論するのではなく、この表からファイル名を選ぶ。
自律実行モード
権限委譲
自律実行モード開始後：
- 実装フェーズ全体の一括承認により、サブエージェントに権限委譲
- task-executor：実装権限（Edit/Write使用可）
- quality-fixer：修正権限（品質エラー自動修正）
Step 2 実行詳細
status: escalation_neededまたはstatus: blocked→ 専門エージェントの結果の受理を適用requiresTestReviewがtrue→ integration-test-reviewer を実行statusがneeds_revision→ レビュー対応を適用し、同じtask_fileとapplyのquality-issueオブジェクト一式を、correction_findingsとして逐語でルーティング先のexecutor（レイヤー別エージェントルーティング参照、task-executorまたはtask-executor-frontend）へ渡すstatusがblocked→ 移動・リネームされた変更テストパスを解決してレビュアーを1回だけ再実行する。requiresTestReview: trueにもかかわらず変更されたテストが存在しない場合は、そのexecutor出力の欠陥をcorrection_findingsとしてルーティング先のexecutorに差し戻す。再実行でもblockedが返る場合はレビュー未実施を記録して、選択したモードの品質/コミット境界へ進むstatusがpass→ 選択したモードの品質/コミット境界へ進む
自律実行の停止条件
| トリガー | 対応 |
|---|---|
| 確認済みの成果、将来状態の要件、対象外を、ユーザーの選択なしには同時に維持できないことをエビデンスが示す | 要件変更検知を適用し、どれを変更するか確認する。 |
| 不可逆な外部操作に承認が必要 | 権限ゲートで承認を求める。 |
| 必要な実装が未完了 | リポジトリのエビデンスから前進できる作業を導ける間は続ける。それ以外は、未完了の内容と観測したエビデンスを報告して終了する。 |
| サブエージェントが環境または実行上の前提不足を報告 | 「専門エージェントの結果の受理」にある証明不足の回復と再試行を適用する。 |
| 要件が変わる | 上記の要件変更検知を適用する。task-decomposer開始後は影響するタスクを無効にする。要件変更によって承認済みの要件、契約、データフロー、検証戦略、タスク境界が成立しなくなる場合に限り、ドキュメント設計から再開する。 |
| ユーザーが停止または割り込む | 自律実行を停止する。 |
Prompt Construction Rule
すべてのサブエージェントプロンプトに以下を含める:
- ファイルパス付きの入力成果物（前ステップまたは前提確認から）
- 期待するアクション（エージェントが行うべきこと）
エージェントのInput Parametersセクションと、フロー内のその時点で利用可能な成果物からプロンプトを構成する。
追加の2つのルール:
- サブエージェントは Agent prompt と自身が読み込んだファイルしか参照できない。必須のパス、先行 JSON、パラメータ、スコープ制約をプロンプトに明示的に注入する
- 以下の例の
[placeholder]は Agent ツール呼び出し前にすべて具体値へ置換する
Call Example (codebase-analyzer)
- subagent_type: "codebase-analyzer"
- description: "コードベース分析"
- prompt: "出典ソースはちょうど1つ渡す: prd_path: [承認済みPRDのパス]、または requirements: [確認済み要件の原文]。設計のための簡潔なリポジトリのエビデンスを収集してください。"
Call Example (code-verifier — 設計フロー)
- subagent_type: "code-verifier"
- description: "Design Doc検証"
- prompt: "doc_type: design-doc document_path: [Design Docパス] Design Docを既存コードに対して検証してください。"
オーケストレーターの主な役割
状態管理: 現在のフェーズ、各サブエージェントの状態、次のアクションを把握
情報の橋渡し: サブエージェント間のデータ変換と伝達
- 各サブエージェントの出力を次のサブエージェントの入力形式に変換
- 前工程の成果物は必ず次のエージェントに渡す
- 構造化レスポンスから必要な情報を抽出
- changeSummaryからコミットメッセージを作成して git commit を実行
- 要件変更時は初期要件と追加要件を明示的に統合
収束記録 → 引き継ぎ先エージェント
渡すもの: オーケストレーターが判定した
convergence記録を、引き継ぎ先エージェントへ渡す。内容は変更せず、各フィールドの readiness ラベルも一緒に渡す。- prd-creator（PRDを新規作成または更新する場合）:
outcomeは成功基準に、ユーザーが挙げたnonGoalsはOut of Scopeに残す。PRDには確認済みの要件と境界だけを残し、評価依頼、推測的なアイデア、未選択の実装手段は要件確認前の収束コンテキストに留める - technical-designer / technical-designer-frontend: PRDがない場合は同じ内容を Design Doc の
Requirement Convergenceへ記録し、weak-but-explicitのまま残ったフィールドも必ずそこへ残す - ui-spec-designer（フロントエンド/フルスタック）: 確認済みのUI要件と、ユーザーが挙げた
nonGoalsを受け取る。未選択の候補からUI Specの内容を作らないprototype_pathがある場合はprototype_reference_strengthも渡す。プロトタイプの表示に従って実装するならbinding、UI Specに記録した内容だけを実装へ渡すならreferenceとする。ユーザーがプロトタイプについて述べた内容から判断し、どちらとも判断できない場合に限り確認する
- work-planner:
nonGoalsは全タスクエントリから除外し、未選択の候補から計画上の作業を作らない。小規模では作業計画書を作らないため、weak-but-explicitのフィールドは保存プロトコルに従いオーケストレーター自身のコンテキストに留め、executorのプロンプトをブロックする項目にはしない
codebase-analyzer → technical-designer
codebase-analyzerへの入力: 出典ソースちょうど1つ — 承認済みPRDが存在する場合はそのパス、存在しない場合は確認済み要件 technical-designerへの入力: codebase-analyzerのJSON出力をDesign Doc作成プロンプトの追加コンテキストとして渡す。必須の使い道:
focusAreas→ Fact Disposition Tableの正典となるdisposition targetリスト（各focusAreaを1行に展開し、fact_idとevidenceをそのまま引き継ぐ）simplifications→ 記録された条件が成立するエントリは新規実装の範囲を減らす材料として扱う。オーケストレーターはスコープ確認の停止点でその一覧を提示し、内容を変えずに渡すdataModel、dataTransformationPipelines、qualityAssurance→ 「既存コードベース分析」「検証戦略」の各セクションに反映
code-verifier → document-reviewer（Design Docレビュー）
code-verifierへの入力: Design Docパス（doc_type: design-doc）。
code_pathsは指定を省略する — verifierがドキュメントからコードスコープを独自に発見する。 document-reviewerへの入力: 検証が実行された場合のみ、最新のcode-verifier結果と記録したレビュー対応の処理方針をあわせてverification_evidenceとして渡す。それ以外はこの入力を省略する。designerに渡したものと同じcodebase-analyzerのJSONをcodebase_analysisとして、出典ソースをconfirmed_requirement_contextとして常に渡す。該当する場合は元の依頼をrequirements_verbatimとして渡す。reviewerはcodebase_analysis.focusAreasでFact Disposition Tableのカバレッジを検証し、確認済み要件のコンテキストでドキュメントの成果と契約を検証する。apply 対象の設計エビデンス finding → technical-designer
担当designerへの入力: 新規の
update呼び出しに、既存のDesign Docパスと、applyの処理方針だけを加えてそれ以外はそのままコピーしたcorrection_findings全体を渡す。承認済み要件、承認済みの決定、従来のエビデンス、影響を受けない設計コンテキストは既存成果物が保持するため、オーケストレーターが設計指示を追加しない。designer はレビューを起点とする範囲限定セルフ検証ゲートを適用し、確立済みのエビデンスに基づいて成果物を更新する。起点となった verifier または reviewer を再実行するのは、update が完了した場合だけとする。code-verifier + document-reviewer → 次レイヤーのtechnical-designer（レイヤー横断フロー時のみ）
次レイヤーのtechnical-designerへの入力: レビュー済みの前レイヤーDesign Docパスを渡し、前レイヤーのcode-verifierを実行した場合のみ
prior_layer_verificationも渡す。シーケンスは「レイヤー横断オーケストレーション」セクションを参照。利用可能な検証discrepancyと前レイヤーのレビュー指摘を用いて不安定な契約を識別する。検証済みと見なせる主張は、実際のエビデンスが示すものに限定する。未検証の主張に設計が依存する場合は、フロントエンドDesign Docの「## Cross-Layer Assumptions」セクションに根拠と検証先を記載する。エスカレーションは、下流の検証ステップで依存を閉じられない場合のみ選ぶ。technical-designer → work-planner
work-plannerへの入力: Design Docパス。work-plannerは出典セクションとACを実装タスクへマッピングする。選択済みなのにカバーされていない義務は修正すべき計画の漏れであり、作業計画書はカバー漏れや設計内容の不足をユーザー確認項目に変換しない。
*1 acceptance-test-generator → work-planner
acceptance-test-generatorへの入力: Design Doc のパス、UI Spec のパス（存在する場合）。
オーケストレーターの検証:
generatedFiles[]の各パスがディスク上に存在すること。空のリストも有効な生成結果である。work-plannerへの入力: 生成されたパス。work-plannerが各スケルトンを、実行可能になる最も早いタスクへ割り当てる。
ADRステータス管理: ユーザーの判断後、所有するtechnical designerをupdateモードで呼び出して各ADRのステータス（Accepted/Rejected）を設定する
重要な制約
- コミット境界: Normalモードのタスクコミットと、品質チェックで生じた修正のコミットには、quality-fixerの
passまたはverification_incompleteの結果が必要である。Liteモードのタスクコミットは、executorの結果と必要なテストレビューの結果を受理した後に行い、実装後レビューの前に最終品質チェックを実行する。コミットは呼び出したレシピが定めるポイントでのみ行う - 構造化レスポンス: サブエージェント間で渡す情報には、宣言済みのJSON fieldを使用する
- 承認管理: ドキュメント作成後にdocument-reviewerを実行し、指定されたユーザー承認の停止点を通過してから次のPhaseへ進む
- フロー確認: 承認後は、確定した大規模・中規模・小規模フローから次のstepを選択する
- 整合性検証: サブエージェントの出力が矛盾した場合、優先順位に従って解決（委譲の境界セクション参照）
実装後レビューのステータスルーティング
| Reviewer | 完了: 検出事項が空 | レビュー対応へ進む | Blocked |
|---|---|---|---|
| code-reviewer | verdictがpass | verdictがneeds-improvementまたはneeds-redesign | verdictがblocked → 専門エージェントの結果の受理を適用 |
| security-reviewer | statusがpass | statusがneeds_revision | statusがblocked → 専門エージェントの結果の受理を適用 |
レビュアーの検出事項は候補である。修正作業は、レビュー対応でapplyとなった集合からだけ作成する。
修正サイクルのハンドオフ: レビュー対応を適用し、そこで選ばれた各修正担当を呼び出す。authorが所有する技術成果物の修正では、レイヤーに応じたtechnical designerをupdateモードで呼び出し、その成果物に既存のdocument-reviewerと該当するdesign-syncのゲートを実行した後、起点のレビュアーを再実行する。executorが所有する修正では、レイヤーに応じたexecutorへ、元のtask_fileまたはdirect scopeのフィールドと、applyの検出事項オブジェクト一式に処理方針だけを加えたcorrection_findingsを逐語で渡し、その後、タスクサイクルのステップ2（条件付きのintegration-test-reviewerの経路を含む）でexecutorの結果に応じて分岐し、該当する品質ゲートを実行する。両方の担当が必要な場合は、レビュー対応にあるauthorを先に修正して再評価する順序に従う。prior_feedbackは照合を行うレビュアーにだけ渡す。
再実行ルール: レビュアーが返したpassingの結果はそのまま有効とする。再実行するのは、最新結果の検出事項に修正を適用したレビュアーだけとする。その際は記録した処理方針をprior_feedbackとして、再導出した実装ファイル一式とともに渡し、修正後の状態に対して照合させる。レビューの前提不足を回復した後は、そのレビュアーを再実行する。受け入れ可否はレビュー対応の収束条件で判断し、解決済みの却下を維持する。
参照
references/review-resolution.md: 検出事項の処理方針、修正、収束references/lite-mode.md: Liteモードの呼び出し集合と最終品質チェック
© shinpr, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 2 other files (references) in .claude/skills-ja/subagents-orchestration-guide of shinpr/ai-coding-project-boilerplate.
- SKILL.md
- references/lite-mode.md
- references/review-resolution.md
Open the folder on GitHubat commit 56913a2
Compare with similar skills
Subagents Orchestration Guide next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Subagents Orchestration Guide this skillshinpr/ai-coding-project-boilerplate | 233 | — | ~4.6k | Automated safety check: Pass | MIT | |
| Claude Code Agent Developmentanthropics/claude-plugins-official | 38k | 7 repos | ~2.8k | Automated safety check: Pass | Apache-2.0 | |
| Subagent Driven DevelopmentAsvarox/allkaraoke | 261 | 37 repos | ~1.2k | Automated safety check: Pass | None | |
| Dispatching Parallel Agentsultralisp/ultralisp | 258 | 40 repos | ~1.5k | Automated safety check: Pass | None | |
| Paseo Advisor Second Opiniongetpaseo/paseo | 20k | 1 repos | ~756 | Automated safety check: Pass | Custom licence | |
| Task Observerrebelytics/one-skill-to-rule-them-all | 3.2k | 1 repos | ~12k | Automated safety check: Pass | CC-BY-4.0 |
Similar skills
- Official
Subagent Driven Development
Asvarox/allkaraoke
A skill your agent uses when executing implementation plans with independent tasks in the current session
Dispatching Parallel Agents
ultralisp/ultralisp
A skill your agent uses when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Paseo Advisor Second Opinion
getpaseo/paseo
Launches one separate agent through Paseo to give a second opinion on the current task, with a self-contained briefing and no permission to edit files.
Task Observer
rebelytics/one-skill-to-rule-them-all
Monitors task execution for skill improvement opportunities.
O2 Review Loop
openobserve/openobserve
Splits a change into planner, coder and independent reviewer roles: you confirm a spec, a subagent implements it, and a separate reviewer checks each round's local WIP commit.
More from shinpr/ai-coding-project-boilerplate
All 41 skills in this repoIntegration E2E Testing
shinpr/ai-coding-project-boilerplate
Selects and designs the smallest integration/E2E test set that proves accepted behavior at an observable boundary.
Skill Optimization
shinpr/ai-coding-project-boilerplate
Evaluates and optimizes skill file quality using 9 content patterns and 10 editing principles.
Frontend Technical Spec
shinpr/ai-coding-project-boilerplate
Defines React environment, component architecture, state/data flow, build verification, and frontend non-functional criteria from repository evidence.
Frontend Typescript Rules
shinpr/ai-coding-project-boilerplate
Applies React/TypeScript type safety, component design, and state management rules.
Implementation Approach
shinpr/ai-coding-project-boilerplate
Selects implementation strategy (vertical slice, horizontal, or hybrid) with risk assessment.
Subagents Orchestration Guide
shinpr/ai-coding-project-boilerplate
Coordinates subagents through scale-based planning, approval, implementation, verification, and escalation flows.
Related
Categories
Questions about Subagents Orchestration Guide
What does Subagents Orchestration Guide do?
規模に応じた計画、承認、実装、検証、エスカレーションのフローでサブエージェントを調整。サブエージェントへの作業振り分け、承認済み作業計画の実行、自律実行の再開時に使用。. Subagents Orchestration Guide is an agent skill from shinpr/ai-coding-project-boilerplate.
When should I use Subagents Orchestration Guide?
Subagents Orchestration Guide fits situations like: tasks that involve Subagents.
How do I install Subagents Orchestration Guide in Claude Code?
Run `npx skills add shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guide -a claude-code`. Or copy the skill folder (.claude/skills-ja/subagents-orchestration-guide in shinpr/ai-coding-project-boilerplate) into .claude/skills/subagents-orchestration-guide in your project. Claude Code loads it when a task matches its description.
How do I install Subagents Orchestration Guide in Codex?
Run `npx skills add shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guide -a codex`. Or copy the skill folder (.claude/skills-ja/subagents-orchestration-guide in shinpr/ai-coding-project-boilerplate) into .agents/skills/subagents-orchestration-guide in your project. Codex loads it when a task matches its description.
Can I use Subagents Orchestration Guide in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add shinpr/ai-coding-project-boilerplate --skill subagents-orchestration-guide -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/subagents-orchestration-guide, .gemini/skills/subagents-orchestration-guide, .github/skills/subagents-orchestration-guide and .opencode/skills/subagents-orchestration-guide in your project.
What does Subagents Orchestration Guide need to run?
SKILL.md names no scripts, command-line tools or credentials: Subagents Orchestration Guide is instructions for the agent only.
Does Subagents Orchestration Guide access the network?
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Is Subagents Orchestration Guide safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Subagents Orchestration Guide use?
Subagents Orchestration Guide is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Subagents Orchestration Guide use?
About 4.6k tokens (SKILL.md is roughly 19k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 4.2k tokens, read only when the agent opens those files.
What are the alternatives to Subagents Orchestration Guide?
Skills that share tags, products or a category with Subagents Orchestration Guide: Claude Code Agent Development (anthropics/claude-plugins-official, 38k stars), Subagent Driven Development (Asvarox/allkaraoke, 261 stars), Dispatching Parallel Agents (ultralisp/ultralisp, 258 stars) and Paseo Advisor Second Opinion (getpaseo/paseo, 20k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Subagents Orchestration Guide?
shinpr (a GitHub user) maintains it in shinpr/ai-coding-project-boilerplate, which has 233 GitHub stars. The repository holds 41 skills in this directory. The repository was last updated on October 4, 2026.
Source: shinpr/ai-coding-project-boilerplate on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.