{
  "markdown": "<p align=\"center\">\n  <a href=\"https://flowwweb.com/swarm\">\n    <img src=\"skills/swarm/assets/swarm-wordmark.png\" alt=\"SWARM\" width=\"560\">\n  </a>\n</p>\n\n<p align=\"center\">\n  <strong>One objective. Clear ownership. A coordinated Codex team.</strong>\n</p>\n\n<p align=\"center\">\n  <a href=\"https://github.com/flowwweb/swarm/blob/main/LICENSE\"><img alt=\"MIT License\" src=\"https://img.shields.io/badge/license-MIT-11dff3\"></a>\n  <a href=\"https://flowwweb.com/swarm\"><img alt=\"Built for Codex\" src=\"https://img.shields.io/badge/built_for-Codex-ff5b45\"></a>\n  <a href=\"https://github.com/flowwweb/swarm\"><img alt=\"Open source on GitHub\" src=\"https://img.shields.io/badge/open_source-GitHub-ffffff\"></a>\n</p>\n\nSWARM is an open-source Codex plugin for work that benefits from more than one agent. You direct a single CTRL task. CTRL divides the objective into clear lanes, LEADs own the outcome of each lane, and DOERs complete focused work inside them.\n\nThe hierarchy keeps parallel work understandable: one place to steer, one owner for every lane, and one integrated result to review.\n\n[Explore SWARM](https://flowwweb.com/swarm) · [View the repository](https://github.com/flowwweb/swarm)\n\n## How the hierarchy works\n\nThis example shows a full three-lane swarm. The professions change with the objective; the hierarchy does not.\n\n```mermaid\n%%{init: {\"theme\":\"base\",\"themeVariables\":{\"lineColor\":\"#36aeca\"},\"flowchart\":{\"nodeSpacing\":42,\"rankSpacing\":152,\"curve\":\"basis\",\"padding\":24}}}%%\nflowchart TB\n  C(\"🐙<br/>CTRL<br/>gpt-5.6-sol · high<br/>Owns the objective\")\n\n  C --> P(\"🧭<br/>MANAGER LEAD<br/>gpt-5.6-terra<br/>Direction\")\n  C --> E(\"🧭<br/>ARCHITECT LEAD<br/>gpt-5.6-terra<br/>Build\")\n  C --> Q(\"🧭<br/>REVIEWER LEAD<br/>gpt-5.6-terra<br/>Proof\")\n\n  P --> P1(\"📚<br/>RESEARCHER DOER<br/>gpt-5.6-luna\")\n  P --> P2(\"🧠<br/>STRATEGIST DOER<br/>gpt-5.6-luna\")\n  P --> P3(\"✏️<br/>WRITER DOER<br/>gpt-5.6-luna\")\n\n  E --> E1(\"💻<br/>DEV DOER<br/>gpt-5.6-luna\")\n  E --> E2(\"🎨<br/>DESIGNER DOER<br/>gpt-5.6-luna\")\n  E --> E3(\"🚀<br/>OPERATOR DOER<br/>gpt-5.6-luna\")\n\n  Q --> Q1(\"🧪<br/>TESTER DOER<br/>gpt-5.6-luna\")\n  Q --> Q2(\"🛡️<br/>SECURITY DOER<br/>gpt-5.6-luna\")\n  Q --> Q3(\"✅<br/>AUDITOR DOER<br/>gpt-5.6-luna\")\n\n  classDef ctrl fill:#fff1ed,stroke:#ff5b45,color:#172033,stroke-width:3px;\n  classDef lead fill:#e9fbff,stroke:#0ea5c6,color:#172033,stroke-width:2px;\n  classDef doer fill:#ffffff,stroke:#78cddd,color:#172033,stroke-width:1px;\n  class C ctrl;\n  class P,E,Q lead;\n  class P1,P2,P3,E1,E2,E3,Q1,Q2,Q3 doer;\n  linkStyle default stroke:#36aeca,stroke-width:1.5px;\n```\n\nThe icons match SWARM task titles. Every visible task says both what expertise it brings and whether it is a LEAD or DOER; bare structural titles are rejected before creation.\n\n- **CTRL** is the sole control point. It understands your objective, chooses the lanes, resolves cross-lane decisions, and returns the combined result.\n- **LEADs** own distinct outcomes. They coordinate their DOERs, integrate the work, and bring back evidence instead of activity reports.\n- **DOERs** complete bounded assignments. They can be developers, researchers, designers, testers, writers, or any other specialist the objective needs.\n\nThe model labels are role defaults for this example, not proof of execution. The\nCodex host owns model, service-tier, and reasoning selection; SWARM reports the\nhost-observed values when that metadata is available.\n\n## Small work stays small\n\nSWARM does not turn every request into a fleet.\n\n- A small or medium assignment on one surface can stay inside the current task and use bounded subagents.\n- A large, parallel, resumable, isolated, or independently accepted outcome earns a visible task lane.\n- A task lane can use its own subagents when that reduces overhead without hiding ownership.\n- Small `CTRL_DIRECT` work remains available for one low-risk atomic general outcome; design, mockup, and image-generation work goes to a DESIGNER lane even when it is small.\n- Usage limits constrain the available route; they do not decide the structure when normal capacity is available.\n\nThis keeps quick work quick while giving larger objectives durable lanes that can progress in parallel.\n\n## Intake and domain graphs\n\nAt the start of every new task, CTRL captures two answers: the goal and the\nmost efficient safe way to reach it. Durable goal persistence is on by default\nand can be disabled with `goals.use_goals = false`; disabling persistence does\nnot disable intake, graph selection, ownership, or proof.\n\nCTRL then selects the most efficient and smallest graph that can complete the\nobjective durably, reliably, and confidently. Game projects use\nthe registered game-studio flow: design, engineering, art, and audio can run\nas independent production lanes, followed by integrated playtest/QA and\nrelease gates. The graph is an ownership and dependency contract, not a flat\nagent roster. See [graph engineering](skills/swarm/references/graph-engineering.md)\nfor the invariants and profile.\n\nEvery agent may request an approved role skill with an exact source/version or\ndigest and task-local scope by default. The host owns installation and audit;\nskills improve execution but never grant authority or turn CTRL into a producer.\n\n## What you get back\n\n- **A quiet control stream.** CTRL surfaces decisions, blockers, proof, and completed outcomes—not routine agent chatter.\n- **Visible ownership.** Every lane has a named outcome, an accountable LEAD, and bounded work beneath it.\n- **Focused proof.** SWARM selects the smallest sufficient checks for the changed surface and expands them when risk or uncertainty requires it.\n- **Independent acceptance.** Work is not complete because an agent says it is; the required evidence and review must close.\n- **Human authority.** A swarm has one CTRL. Creating or replacing another CTRL requires an explicit user request.\n\n## Install in Codex\n\nAdd the Flowwweb marketplace:\n\n```text\ncodex plugin marketplace add flowwweb/swarm --ref main\n```\n\nRun `/plugins`, open **Flowwweb**, install **SWARM**, and start a new Codex task so the plugin loads into fresh context.\n\nThen ask Codex to use it:\n\n```text\nUse SWARM to ship the next release of this project.\n```\n\nThat task becomes `🐙CTRL - <objective>`: the one place where you direct the work and review what the swarm returns.\n\nTo update an existing installation:\n\n```text\ncodex plugin marketplace upgrade flowwweb\ncodex plugin add swarm@flowwweb\n```\n\nStart a new task after reinstalling.\n\n## Configure SWARM\n\nSWARM uses one global TOML file: `~/.agents/swarm/config.toml`. Initialize it\nfrom the maintained template, edit only the settings you need, then validate\nthe result:\n\n```text\npython skills/swarm/scripts/swarm_config.py init\npython skills/swarm/scripts/swarm_config.py validate\npython skills/swarm/scripts/swarm_config.py show\n```\n\nThe common controls are deliberately small:\n\n```toml\n[execution]\nfast_mode = true       # the only Fast-mode switch\n\n[automation]\nmode = \"standard\"      # or \"manual\"\n\n[console]\nopen_on_start = false\n```\n\nChanges apply at the next safe scheduling boundary; start a new task after a\nplugin update. Fast mode requests the host's faster service tier but is reported\nactive only when host response metadata confirms it. Config never overrides an\nexplicit user choice or grants task, Git, release, provider, or user-state\nauthority. See the [configuration reference](skills/swarm/references/config.md)\nfor every supported key and its claim limits.\n\n## Local console\n\nSWARM includes an optional loopback-only console for seeing the live hierarchy, task state, requested and observed models, reasoning levels, lightweight logs, evidence, and blockers.\n\n```text\npython skills/swarm/scripts/swarm_console.py --start\n```\n\nPython 3.11 or newer is required. Docker is optional:\n\n```text\npython console/docker.py up\n```\n\nThe console shows what SWARM knows; it does not invent host activity or passing proof. Settings writes are validated and loopback-only in both native and Docker modes. Docker keeps Codex task metadata read-only, writes only the bounded SWARM proof directory, and stores console history in its named volume.\n\n## Codex-native scope\n\nSWARM is a Codex plugin and workflow: Codex is the only agent host whose task,\ntool, model, and execution behavior this repository describes or routes. The\n`plugins/swarm` tree is the generated Codex marketplace mirror of the canonical\n`skills/swarm` source. SWARM does not ship, install, or claim compatibility with\nClaude Code, Anthropic, Gemini, Copilot, Cursor, OpenCode, or another agent host.\n\nThe word `provider` may still appear in proof contracts for a real external\nservice boundary such as authentication, payments, deployment, or browser\nevidence. That proof category is not a model-host adapter and does not create a\nsecond execution authority. Host installation, activation, task behavior, and\nserved-tier claims require their own direct receipts.\n\n## Reference\n\n- [Hierarchy and role contracts](skills/swarm/references/hierarchy.md)\n- [Configuration and model profiles](skills/swarm/references/config.md)\n- [Review and acceptance](skills/swarm/references/review-contract.md)\n- [Console guide](console/README.md)\n- [Contributing](CONTRIBUTING.md)\n- [Security](SECURITY.md)\n- [MIT License](LICENSE)\n",
  "bytes": 9288,
  "sha": "354d2ef3928ba462312d373bac0976151ce0a91bb9891ace43c9c781d9213e4e",
  "repo_slug": "flowwweb/swarm",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_flowwweb_swarm_4e13aa56/readme"
}