# Show HN: Generate a Claude Code or Codex agent fleet from one HTML file > Source: > Published: 2026-09-03 22:45:49+00:00 A browser wizard that generates a working agent fleet for Claude Code or Codex. One HTML file, no install, no build step. Open it, answer some questions, download a zip. **Now with MOOTx01 integration:** an optional persistent-memory layer so a session can hand its own work to the next one. The output is a `.claude/` directory containing agent definitions, skills, hooks, settings, and an install script. Drop it in a repository and the agents are there next time you start a session. A single agent doing everything is the default, and it is the expensive way. It holds the whole task in one context, reasons about all of it at the top tier, and types every line itself. A fleet splits that into three roles: - an **orchestrator** decomposes the work and dispatches it **workers** implement one unit each, from a brief- a **reviewer** judges the orchestrator's output before it lands The split is not organisational tidiness. It is what makes the work cheaper and better at the same time: the units run on a smaller model, they run in parallel, and nothing merges without something that did not write it having looked. **The orchestrator writing the code itself is the failure of that job, not a shortcut to it.** Measured across live runs, orchestrators that dispatched their implementation work ran about 64% of tokens in subagents. Orchestrators that typed it themselves ran 0 to 32%, and cost three to four times as much for comparable work. Agents | Role definitions with tools, model, and skills, in the shape your target reads | Skills | The doctrine each role loads on demand, rather than carrying always | Hooks | Shell hooks for scope enforcement, push gating, and logging | Commands | Slash commands for the workflows you picked | Settings | `settings.json` wired to the hooks | Install script | Puts it all in place | Open `web/fleet-generator.html` in a browser. Nothing is uploaded; the whole thing runs locally. `web/GUIDE.html` walks the wizard end to end, including three install paths depending on how much you want to decide up front. `sample_out/` holds a full generated bundle if you would rather read the output before running anything. Claude Code reads a `.claude/` directory. Codex reads an `AGENTS.md` at the repository root. The doctrine is identical either way, so this is a packaging choice rather than a different fleet. Picking **Both** emits both entry points from one source, and the `AGENTS.md` states that the skill files are authoritative. Two descriptions of one fleet drift the moment either is edited, and saying which one wins is cheaper than reconciling them later. The generated fleet does not put every agent on one model. | Role | Tier | Why | |---|---|---| | Reviewer | top | One pass over a finished diff. Cheap, and the only thing between a plausible-looking change and your main branch. | | Orchestrator | top | Pays for itself if it dispatches. If it types the code itself, this is the most expensive possible arrangement. | | Workers | mid | They receive a brief containing everything they need, so capability buys less here than anywhere else. | **A model class implies an agent-file shape.** Keep two variants of the orchestrator: the full procedural file for the smaller model, and a lean one for the capable model. Measured on one identical task across eight configurations, the lean file halved the cost of the capable model and passed, while making every smaller model more expensive and no better. Running a capable model against the full procedural file is the most common setup error. It reads as the safe choice and it is not: the model spends context on scaffolding it does not need, has less left for the work, and starts doing the work itself rather than dispatching. Edit `MODEL_TIERS` near the top of the wizard's script block to change the defaults. A checkbox adds a compact ritual for [MOOTx01](https://github.com/codedaptive/mootx01-ce): `/prepare-for-compact` , `/start-clean` , and `/recover-from-compact` . The commands need MOOTx01 installed; leave the box unchecked if you are not running it. The agent writes its own handoff before context runs out, and the next session reads it back. The `handoff` and `plan-capture` skills ship regardless. They are written against "your memory system", so they work with any store and are better with a real one behind them. ``` fleet-generator/ ├── web/ │ ├── fleet-generator.html # the wizard: this is the product │ ├── GUIDE.html # how to use it, end to end │ ├── SPEC.md # how it is built, for editing it │ └── archive/ ├── sample_out/ # a full generated bundle, for reading └── README.md ``` Everything lives in `web/fleet-generator.html` as JavaScript constants: `ROLES` for the agents, `CLI_SKILLS` and `OPTIONAL_CLI_SKILLS` for skill bodies, `OPTIONAL_HOOKS` for hooks, `MODEL_TIERS` for the tiers. There is no separate source tree: the constants are the source. `web/SPEC.md` documents the structure and what has to agree with what when adding a skill or a hook. `sample_out/` is a snapshot rather than generated output, so it drifts when the wizard changes and needs a deliberate refresh.