fable-delegate
Skill6 starsChanged 3 months agoMITView on GitHub
Delegate independent subtasks to parallel workers or subagents with strict disjoint ownership, bounded scope, and explicit acceptance contracts. Use when coordinating multiple independent tasks, parallelizing multi-file work without merge conflicts, or managing subagent task assignments — even if the user does not explicitly say \"fable-delegate\" (e.g. \"split this work among workers\", \"delegate these subtasks\", \"run parallel agents\", \"assign independent pieces\"). Do NOT use for tightly coupled sequential tasks or when shared mutable state causes edit collisions.
- Reads credentials
In this repository55 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .codex/AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- skills/fable-tend/AGENTS.mdAGENTS.md
- skills/fable-wise/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- skills/fable-tend/CLAUDE.mdCLAUDE.md
- skills/fable-tend/site/CLAUDE.mdCLAUDE.md
- skills/fable-wise/CLAUDE.mdCLAUDE.md
- public/llms.txtllms.txt
- get-fableSkill
- typesafe-aiSkill
- get-fableSkill
- get-fableSkill
- fable-architectureSkill
- fable-artifactSkill
- fable-configSkill
- fable-context-thriftSkill
- fable-councilSkill
- fable-coworkSkill
- fable-datavizSkill
- fable-discoverSkill
- fable-domainSkill
- fable-ecoSkill
- fable-evalSkill
- fable-executeSkill
- fable-finish-your-turnSkill
- fable-handoffSkill
- fable-healSkill
- fable-judgeSkill
- fable-learningSkill
- fable-loopSkill
- fable-memorySkill
- fable-methodSkill
- fable-native-codeSkill
- fable-outcome-firstSkill
- fable-planSkill
- fable-prove-itSkill
- fable-recoverSkill
- fable-redteamSkill
- fable-releaseSkill
- fable-researchSkill
- fable-reviewSkill
- fable-runSkill
- fable-scope-disciplineSkill
- fable-securitySkill
- fable-simplifySkill
- fable-simulatorSkill
- fable-skill-creatorSkill
- fable-sparkSkill
- fable-tddSkill
- fable-tendSkill
- fable-verifySkill
- fable-wiseSkill
- get-fableSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 12 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 32
Use parallel workers when independence is real, not merely because there are multiple tasks.
- Distinctive: line 50
all workers depend on one unresolved architectural decision.
- Distinctive: line 77
If independence cannot be explained in one short paragraph, do not parallelize yet.
- Distinctive: line 90
Do not ask a worker to "handle X" with an entire repository and no boundary.
- Distinctive: line 93
Prefer one writer per semantic area.
- Distinctive: line 98
Do not micromanage every command.
- Distinctive: line 120
If workers produce competing approaches, keep them read-only until the parent chooses.
- Distinctive: line 121
If a worker needs to cross ownership boundaries, pause that worker and renegotiate the contract instead of silently expanding scope.
- Distinctive: line 126
Every mutable surface has clear ownership.
- Distinctive: line 149
No meaningful progress or repeated failure.
- Distinctive: line 163
All subagent delegation contracts and worker return packets MUST use TOON (Token-Oriented Object Notation).
- Distinctive: line 198
every worker contract had explicit ownership and acceptance.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Fable Delegate
Use parallel workers when independence is real, not merely because there are multiple tasks.
Mission
Delegation should reduce latency without multiplying ambiguity. The parent remains responsible for decomposition, contract stability, integration, and final proof.
A worker is not a place to dump context. It receives one bounded responsibility with enough evidence to act independently and a return contract that makes integration reviewable.
Activate When
- two or more cards can proceed without waiting for each other's decisions;
- specialist perspectives can investigate independent hypotheses in parallel;
- separate components have stable interfaces and independent acceptance checks;
- independent review/research can be parallelized without shared mutation.
Do Not Activate When
- workers would change the same unstable contract or invariant;
- one card's design result changes another card's requirements;
- a tiny task costs more to explain/integrate than to execute;
- the parent has not established enough context to write precise worker contracts;
- all workers depend on one unresolved architectural decision.
Independence Classification
For each candidate pair, classify coupling:
| Coupling | Parallel? | Why |
| Different files + different contracts | usually yes | low semantic overlap |
| Different files + shared unstable contract | no | semantic conflict despite path separation |
| Same integration file + separate components | maybe, but serialize integration | component work may parallelize; integration does not |
| Shared read-only evidence | yes | no ownership conflict |
| Same database schema/invariant | usually no | one worker can invalidate another's assumptions |
| Independent research hypotheses | yes | merge conclusions, not source edits |
| Parent decision required by both | no | resolve decision first |
Delegation Protocol
Stage 1 — Prove independence
Check:
- write ownership;
- shared contracts/invariants;
- dependency order;
- generated artifacts;
- migration/state coupling;
- integration hotspot;
- whether one worker failure changes another worker's assumptions.
If independence cannot be explained in one short paragraph, do not parallelize yet.
Stage 2 — Write a worker contract
Each contract includes:
- objective;
- context/evidence already established;
- owned paths or semantic area;
- forbidden scope;
- dependencies assumed stable;
- acceptance evidence to produce;
- expected return packet;
- stop/escalation conditions.
Do not ask a worker to "handle X" with an entire repository and no boundary.
Stage 3 — Decide mutation ownership
Prefer one writer per semantic area. Multiple read-only investigators may inspect overlapping files; multiple writers should not independently redefine the same contract.
For a shared integration file, assign integration to the parent or one named worker after component work converges.
Stage 4 — Dispatch and supervise by exception
Do not micromanage every command. Intervene when:
- worker discovers a load-bearing unknown;
- owned scope must expand;
- acceptance cannot be satisfied;
- contract assumption is false;
- worker stalls/repeats failure.
Stage 5 — Inspect returns, not summaries alone
Require concrete artifacts: diff/paths, commands/results, evidence, unresolved risk. A prose "done" is not integration evidence.
Stage 6 — Integrate centrally
The parent checks:
- combined diff;
- contract compatibility;
- cross-worker behavior;
- generated artifacts;
- integration tests;
- whether worker-local evidence is still fresh after merge/integration mutations.
Decision Rules
- Different files are neither necessary nor sufficient for independence.
- Stable contract + isolated implementation can parallelize; unstable contract + separate files should not.
- If workers produce competing approaches, keep them read-only until the parent chooses; do not merge both experiments blindly.
- If a worker needs to cross ownership boundaries, pause that worker and renegotiate the contract instead of silently expanding scope.
- A failed/hung worker does not automatically justify rerunning the same prompt; classify failure and route the card to
fable-recoveror execute locally. - Parent integration verification is mandatory whenever delegated work affects one user-visible behavior.
Invariants
- Every mutable surface has clear ownership.
- Workers receive only the context needed to make their bounded decisions.
- Worker completion never equals global completion.
- Shared contract changes have one integration owner.
- Combined workspace is verified after all integration mutations.
Failure Taxonomy
Ownership collision
Two workers need the same mutable contract/file. Stop parallel mutation and replan ownership.
Semantic collision
Files differ but both change one invariant/schema. Treat as coupled work.
Context starvation
Worker repeatedly asks questions the parent should have resolved. Improve contract or route back to discovery/plan.
Scope escape
Worker finds necessary work outside ownership. Pause, evaluate, then expand/replan explicitly.
Worker-local green / integration red
Local checks pass but combined behavior fails. Parent owns diagnosis; do not bounce workers blindly.
Worker stall
No meaningful progress or repeated failure. Terminate/recover rather than consuming unbounded budget.
Anti-Patterns
- "two tasks = two agents";
- path-disjointness as the only parallelism test;
- giving every worker the entire broad task;
- allowing each worker to update shared manifests/routes independently;
- accepting prose summaries without diffs/evidence;
- merging worker outputs before inspecting assumptions;
- assuming subagents transfer responsibility away from the parent;
- delegating a decision the parent has not made simply to avoid making it.
Mandatory TOON Delegation Protocol
All subagent delegation contracts and worker return packets MUST use TOON (Token-Oriented Object Notation). This guarantees:
- Token efficiency: 35-70% fewer tokens compared to verbose markdown/JSON.
- Deterministic parsing: Explicit length tags
[N]allow the parent agent to instantly detect truncated or dropped tasks. - Structured schema: Field headers
{fields}enforce contract compliance.
Boss → Worker Delegation Contract (TOON)
contract:
workerId: worker-1
targetCard: CARD-101
objective: "Implement JWT authentication guard"
ownedPaths[2]: src/auth/guard.ts,test/auth/guard.test.ts
forbiddenPaths[2]: src/config/keys.ts,.env
acceptanceChecks[2]: "bun test test/auth/guard.test.ts","bun run typecheck"
rules[2]: "Do not touch files outside ownedPaths","Use TOON format for the return packet"Worker → Boss Return Packet (TOON)
result:
workerId: worker-1
targetCard: CARD-101
status: complete
allChecksPassed: true
mutations[2]{path,action}:
src/auth/guard.ts,modified
test/auth/guard.test.ts,created
verifications[2]{command,result,durationMs}:
"bun test test/auth/guard.test.ts",pass,120
"bun run typecheck",pass,340
notes[1]: Successfully implemented guard with full test coverageCompletion Criteria
Delegation is complete when:
- every worker contract had explicit ownership and acceptance;
- returned artifacts/evidence were inspected;
- ownership/contract conflicts are resolved;
- combined diff passes integration verification on the current workspace;
- residual failures are routed explicitly rather than hidden in worker summaries.
Progressive Resources
- Deep guide:
references/parallelism-and-integration.md - Existing contract guide:
references/subagent-contracts.md - Template:
templates/delegation-contract.template.md - Example:
examples/parallel-workers-walkthrough.md
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

