Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/s977043/plangate/codex-multi-agentnpx skills add s977043/PlanGate --skill codex-multi-agentgit clone --depth 1 https://github.com/s977043/PlanGateWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/s977043/plangate/codex-multi-agent)<a href="https://agentmods.dev/skills/s977043/plangate/codex-multi-agent"><img src="https://agentmods.dev/badge/skills/s977043/plangate/codex-multi-agent.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00128 | $0.02943 |
| Opus 5 | $0.00064 | $0.01471 |
| Sonnet 5 | $0.00026 | $0.00589 |
| Haiku 4.5 | $0.00013 | $0.00294 |
Grade A, and why
codex-multi-agent scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 290 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Multi-Agent Operating Guide
複数 agent を使って作業するときの共通運用ルール。
このスキルの中心はツール依存の操作手順ではなく、次の判断基準にある。
- いつ委譲するか
- どう分割するか
- 何を並列化してよいか
- 主担当がどう統合するか
Iron Law
今すぐ主担当が自分でやるべき作業は委譲しない
- 直後の意思決定に必要な調査や編集は主担当が自分で行う
- サブエージェントには、独立して進められる具体的なタスクだけを渡す
- 委譲は目的ではなく手段である。分割すると遅くなるなら分割しない
使う場面
- 実装と調査を並列で進めたい
- フロントエンド / バックエンド / テストを役割分担したい
- 読み取り専用の影響調査を別 agent に切り出したい
- レビューや検証を独立した agent に任せたい
- 大きなタスクを分割して、最後に主担当が統合したい
使わない場面
- 単純な 1 ファイル修正
- すぐに主担当が判断すべき設計変更
- 強く結合した変更で、分割すると手戻りが増える場合
- 「とりあえず並列化したい」だけで、独立タスクがない場合
Step 1: 主担当が先に決める
委譲前に、主担当が以下を自分で確定する。
- ユーザー要求の要約
- クリティカルパスの特定
- 並列化できる独立タスクの抽出
- 自分が今すぐ着手する作業の決定
ここが曖昧なまま委譲しない。
Step 2: タスクを分解する
サブエージェントに渡すタスクは、次の条件を満たすものだけにする。
- 入力が明確
- 完了条件が明確
- 変更範囲または責務が明確
- 主担当の直後の作業をブロックしない
良い例:
- 「
<対象ディレクトリ>配下でこの UI に関係する既存パターンを 3 点探して報告する」 - 「Laravel 側の既存 API とテスト配置を調査し、変更候補ファイルを列挙する」
- 「この 2 ファイルだけを担当して型エラーを直す」
悪い例:
- 「いい感じに全部進めて」
- 「必要そうなものを全部見て実装して」
- 「まず調べて、必要なら設計して、実装して、レビューして」
Step 3: 役割を選ぶ
まず役割で考え、ツールごとの agent 名は後で割り当てる。
| 役割 | 使いどころ |
|---|---|
| planner | 要件整理、タスク分解、依存関係整理 |
| researcher | 既存コード調査、影響範囲調査、読み取り専用分析 |
| frontend-dev | UI / コンポーネント実装 |
| backend-dev | API / ドメイン / リポジトリ実装 |
| database | DB スキーマ、マイグレーション設計 |
| tester | テスト設計、テスト追加、検証観点整理 |
| debugger | 不具合原因調査、再現条件の切り分け |
| reviewer | セキュリティ、性能、品質レビュー |
| docs | ドキュメント整備 |
| ops | Docker / CI / インフラ運用作業 |
迷ったら:
- 調査は
researcher - 実装は該当ドメインの
*-dev - テストは
tester - 計画は
planner
Step 4: チーム規模を決める
必要最小人数で始める。人数を増やす基準は「仕事量」ではなく、独立した責務があるかどうか。
ここでの人数は、主担当 を含む総人数の目安を指す。
reviewer は抽象ロールであり、必要に応じて 1 agent でも複数 agent でもよい。ツール別の実体への割り当ては末尾の Tool Mapping を使う。
- 小規模（2-3 agent）: 調査 + 実装、単機能修正、局所的なレビュー
- 中規模（3-4 agent）:
frontend-dev/backend-dev/testerの並列、または調査 + 実装 + レビュー - 大規模（4-5 agent）:
plannerを含めた設計整理、複数レイヤーの実装、独立レビューの同時進行
増やしすぎの兆候:
- 各 agent の担当範囲を 1 行で説明できない
- 同じファイルや同じ意思決定を複数 agent が共有している
- 主担当が統合よりも調整に時間を取られている
迷ったら、1 段階小さい規模から始める。
Step 5: 並列化の判断
並列化してよいのは、互いに独立していて、成果物の衝突が小さいタスクだけ。
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 290 lines · 128 tokens per session scan A 1a8208af1177
codex-multi-agent is a skill published in the GitHub repository s977043/PlanGate (2 stars, last pushed 3d ago), licensed MIT. It adds 128 tokens to every session and 2,943 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
skill-maintenance
Automated skill maintenance tool (v6 — Unified Registry + Snapshots). Full scan: [Orphan] migrate misplaced skills from category dirs OR standalone skills/<name>/ to auto-generated/, [Sync] auto-generated/ vs registry lifecycle diff (new/deleted/revived + description auto-sync via lifecycle field), [Reg]…
watch
File sentinel that monitors the working directory for changes and marker comments, then auto-triggers appropriate skills. Poll-based via git diff against the last scan commit. Writes intake items for batch processing and routes marker actions through /do. Use for automatic reactions to file changes; do NOT use for…
review
5-pass structured code review — correctness, security, performance, readability, consistency.
live-preview
Mid-build visual verification loop. Takes screenshots of components during construction, not just after. Catches visual regressions and invisible features before they compound. Requires Playwright or similar screenshot tool.
marshal
Meta-orchestrator that takes any direction — broad, specific, or vague — and autonomously chains skills and context into actionable work. Gathers context from codebase, docs, and memory. Only asks the user when it genuinely cannot proceed. Single-session orchestrator.
wiki
Markdown-first knowledge base where the LLM acts as librarian. Ingests raw sources, compiles and interlinks topic files, self-maintains an index. No vector DB or embeddings required -- uses LLM-native navigation over structured markdown up to 400K words.