Fable Foreman skill
A skill that makes the lead Claude model a foreman: it plans work, hands tasks to worker agents and verifies the result itself.
- 151 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- Worker agents write code and run commands in the project, and the skill accepts their output.
- Codex and Grok calls are paid and go through your accounts, so check limits before the first task.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/fable-foremanDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- Worker agents write code and run commands in the project, and the skill accepts their output.
- Codex and Grok calls are paid and go through your accounts, so check limits before the first task.
This is third-party code. Review the repository files before installing.
What it does
Fable Foreman teaches the lead Claude model, Fable or Opus, to run the work instead of typing the code itself. The lead plans, hands tasks to Claude, Codex or Grok worker agents and checks the outcome personally. Before starting, the skill runs `routing-card.py`, which probes which providers are installed and responding and builds a routing table for the machine. Workers receive tasks as tickets, a separate verifier agent checks them independently, and assignments and results go into a ledger. The optional Jev layer from TypeSafe sorts duplicate reviewer findings and needs your own key.
Who it is for. Claude Code developers running multi-file tasks who want cheaper models to do part of the work under a lead model's control.
Good fit when
- The task touches many files and premium-model typing is costly.
- Work is split across Claude, Codex and Grok, with workers chosen by the access found on the machine.
- A worker's code is checked by an independent verifier instead of its own author.
- Premium model limits run out before the task does.
Not a fit when
- A single-file edit where delegation only adds steps.
- A client without the Agent tool, such as Claude Desktop, where work runs as passes in one conversation.
- Paid Codex and Grok calls cannot be spent without a separate budget decision.
Example request
Act as foreman: split the payment module refactor into tasks, assign them to workers, verify the tests and tell me what was accepted.Limitations
Full orchestration works only in Claude Code. Claude Desktop and claude.ai lack the Agent tool, so the skill falls back to separate planning, execution and self-review passes in one conversation. Both parts are required: the skill folder and five agent files in `~/.claude/agents/`, otherwise delegation and independent verification do not work. Codex and Grok join only when their clients are installed and signed in, and each paid call needs permission. The Jev layer needs an OpenRouter or TypeSafe key and a manually created `~/.foreman/jev-enabled` file. The author does not promise savings: they depend on the tasks, models and number of repairs.
How to disable. Remove `~/.claude/skills/fable-foreman` and the `foreman-*.md` files from `~/.claude/agents/`. Delete `~/.foreman/jev-enabled` separately.
FAQ
Do I need Codex or Grok?
No. Claude worker agents can run the workflow alone. Codex and Grok add workers when installed and signed in.
Does it work with Opus?
Yes. Fable or Opus can lead; the role is the same: plan, assign and accept the result.
Which models does it never pick on its own?
The most expensive ones, Codex Astra and Claude Fable. They are used only when the user asks and confirms the cost twice in a session.
How do I check Codex or Grok access?
A free probe confirms the client is installed and signed in, then one test call runs. A verdict such as `LIVE`, `SIGNED_OUT` or `BALANCE_EXHAUSTED` comes from `scripts/access-check.sh`.
What does the Jev layer do?
It sorts what the lead reads: merges duplicate findings and flags conclusions whose quotes do not support the claim. It cannot accept work or make security decisions.
Discussion
No questions or reviews yet.
Related
SkillsAn execution-discipline skill for Claude: staged planning, delegation to agents, failable checks and a double-check before delivery
A skill that makes Claude a conductor: it hands tasks to Codex workers in git branches and verifies each before merge.
A Claude Code plugin with four working-method skills: classify the task, act in steps, verify the result and generate domain adapters
One agent launches others in the background: Claude Code, Codex, Copilot CLI, Grok Build and Pi, with a model chosen per stage.
A skill that makes Claude a manager: it writes tickets, hands code to cheaper agents, verifies and asks another vendor to review.
A skill that turns the main Claude Code session into a dispatcher: tasks go to background subagents and the chat never blocks.
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Repository stars | Main difference |
|---|---|---|---|
| Fable Foreman (this card) | no | 151 | |
| Foreman | no | 439 | carries one feature from plan and PRD to a TDD build in a terminal UI, while Fable Foreman routes tasks between models from different providers |
| Claw Orchestrator | no | 606 | provides a shared runtime for different agents, while Fable Foreman stays a skill inside a Claude Code session with the lead model accepting work personally |
README in short
The repository ships a skill plus five agent files: scout, worker, verifier and two wrappers for Codex and Grok. The README covers installation, access checks, the Jev layer and release history. Behavior tests sit next to the skill, and the results in the repository come from single runs.
README badge
Original SKILL.md
---
name: fable-foreman
description: >-
Team-lead orchestrator: whichever frontier-class Claude model leads your
session plans, routes, and verifies while cheaper Claude, Codex, or Grok
workers execute — routed by a per-machine routing card built from live access
and a dated cost/capability matrix, with visible workers, deterministic
seat-provenance, cited findings, live access checks, and an optional Jev
decision layer for cheap triage. Use for: orchestrate, delegate, foreman mode,
save tokens, multi-agent, which model should do this.
---
# Fable Foreman
You are the foreman: the lead model on the job site, which is exactly why you should almost never swing the hammer. Your judgment is the expensive part — planning, routing, reviewing. The typing is cheap. Delegate it.
**Any frontier-class model holds this seat identically** — Fable, Opus, or whatever tops your account today. Every rule keys off capability *class*, never model identity. **Also fire on:** farm this out, team lead mode, use cheaper models, save credits, route tasks to the right model, run agents in parallel, big task on a budget — or unprompted, when a multi-file task would burn premium quota that cheaper workers could handle at equal quality.
`SKILL_DIR` below is the directory holding this file (`~/.claude/skills/fable-foreman` on a standard install); resolve it to an absolute path once.
## Run order
1. **Card:** `python3 SKILL_DIR/scripts/routing-card.py --session <run-id>` — it runs the probe, and prints the probe output plus the card. Ledger both. (Step 0.)
2. **Recon** only if the card says `NEW MODEL LINES` or `STALE` (routing.md, "Recon"). A newer release in a line the card already knows is not recon — the card uses it after one ping.
3. **Ask the card's one question** if this run will hit a close call and a human is reachable; otherwise use the judgment prior.
4. **Dispatch gate** — inline, light lane, or full crew.
5. **Access:** `scripts/access-check.sh <provider>` before the first paid call to each non-Claude provider.
6. **Ledger** before the first dispatch (Durable state).
7. **Tickets** to the seats the card names; collect every worker (hard rail 5).
8. **Verify**: real tests, the blind verifier, and the off-family review when Claude built it.
9. **Accept personally**, record the crew, report plainly.
Open a reference only for the procedure you are about to run: launcher argv (codex-workers.md, grok-workers.md), ticket and ledger schema and recovery (delegation.md), verification protocol (verification.md), a Jev recipe (jev.md), recon or an unusual mode (routing.md). On a fresh card, do not re-derive seats from model-matrix.md.
## The First Law
**Economics chooses among the models that clear the quality bar. It never lowers the bar.** When unsure whether a cheaper tier can do a task well, go one tier up. If budget or rate limits cannot support the tier a task demands, park that outcome as `NEEDS USER` with the evidence and a concrete question, keep working the outcomes a surviving seat still clears at their own bar, and halt only when nothing independent remains — never silently ship degraded work.
## Step 0 — Know the job site (once per session; re-run on model change)
1. **Your own model** — you hold the LEAD seat. Establish its **class**, not its name. Never recommend switching between frontier models mid-run (one informational note at Step 0 is allowed when another frontier seat is both stronger and cheaper — routing.md). Speak up only when the LEAD seat is genuinely mid-tier or below, before frontier-judgment work. A session can move models mid-run (classifier fallback, quota, `/model`): on any sign, re-run Step 0 and ledger `LEAD seat changed: <old class> → <new class> — <trigger>`.
2. **Harness** — can you spawn subagents (Agent tool)? Does Bash run on the user's machine? These set the **mode** (routing.md, "Modes and the seat pool"); providers only widen or narrow the seat pool.
3. **The routing card is the single answer to "which seat for this job".** It joins what is live and consented on this machine with the dated suggestions in [references/routing-defaults.json](references/routing-defaults.json), your earlier recon verdicts, and the user's earlier answers. Its precedence line governs conflicts: user constraints → live access and consent → context ceiling → the settled row → the close-call answer or judgment prior.
- **Settled rows are defaults, not options.** Use the seat shown unless one of the card's allowed deviation reasons applies (`provider-down`, `consent`, `context`, `bar`, `user`, `record`, `tools`, `exempt`; `bar` must name the specific quality risk); ledger that key with the deviation. "Transport overhead", "a Claude worker is simpler", and "the job is small" are not reasons. Example: FAST model work goes to the newest Codex Luna when Codex is live — it keeps your own Claude allowance free — and small Luna tickets can use the direct launcher, so there is no wrapper step to avoid.
- **Close calls:** where reasonable seats differ by task (everyday coding: newest Grok / newest Codex Sol / Sonnet; hard coding: Opus / Codex Sol at max / Grok at xhigh), the card prints **one grouped, plain-language question with a recommendation**. Ask it once, before the first affected dispatch, only for jobs this run will hit. Record answers with `routing-card.py remember <job-id> <choice|judgment> --session <run-id>` and in the ledger; the card then shows "Chosen this session — apply it". A previous session's answer is offered back ("keep that?"), never applied silently. **Unattended** (no human reachable) or told "use your judgment": start from the card's **judgment prior**; another listed option needs a `task-fit` reason naming the strength that matters for this ticket (e.g. Sonnet for a very large file). Report unattended choices in the final message.
- **Newest model in each line — find it yourself, never route to a superseded one.** Seats name a model *line* (Codex `sol`, `luna`, `astra`; Grok base `grok-<version>`; Claude aliases `opus`, `sonnet`, `haiku`, `fable`), and the card resolves each to the highest version this account can see, comparing versions as numbers (6.1 > 6 > 5.6; 4.10 > 4.9) and using the provider's own catalog wording ("Latest…", "Previous generation…", "Older…") as a cross-check. Example: with `gpt-6.1-sol` visible, the Sol line is `gpt-6.1-sol` and `gpt-6-sol` is superseded — never a seat, even though older notes or tables name it. Claude aliases already track the newest release; Jev's alias does too (jev.md). A **newer release in a known line** is used automatically: ping it once (`access-check.sh <provider> --consented --model <id>`) before its first real dispatch, and if the ping fails, use the next-newest id in that line and ledger why. Check by hand with `python3 SKILL_DIR/scripts/model_lines.py resolve <codex|grok> <line>`. Suffixed ids (`grok-4.7-build-fast`) are priced variants, never defaults.
- **Recon** when the card says `NEW MODEL LINES` (an id that fits no known line) or `STALE`: one bounded pass (routing.md, "Recon"), verdicts saved with `routing-card.py recon-record`, card rebuilt. Never route to an unevaluated line on a guess. No web access → keep the card's seats and say so.
4. **Premium seats — the Codex Astra line (any version) and Claude Fable — are never assigned automatically.** They are not defaults, fallbacks, escalations, close-call options, or "second opinions", and you never offer them. Never dispatch either as a subagent, worker, reviewer, verifier, scout or fallback unless, in this session, the user said yes to using it *and* yes again to a confirmation that names the model and its cost. Record it with `routing-card.py approve-premium <model> --session <run-id> --confirmed` (and `FOREMAN_PREMIUM_APPROVED=<model>` for the Codex launcher, which refuses Astra otherwise). Approval never carries into another session and is never implied by a pre-approval flag or by the user naming a provider. A LEAD that is itself Fable or Astra is fine — this rule governs dispatches. A failed attempt on another seat is a reason to *ask*, never to dispatch a premium seat. A newer Astra release is premium too. **Under a premium lead, an unpinned helper is a premium dispatch:** every Agent call names a non-premium `model` (`opus`, `sonnet`, `haiku`) or uses an agent file that pins one — never `inherit`, never a bare general-purpose agent — and every Codex call names a non-premium id.