agentsclimarketplace
Sign in

Efficient fable

Skill anshmajumdar121/skill-x/skills/efficient-fable

Use when running an expensive frontier model on codebase-heavy or token-heavy work and the user wants that model to orchestrate, architect, synthesize, and final-judge while cheaper helper agents do bounded heavy lifting (large repo scans, long log reduction, narrow code patches, browser/test verification, etc.). Trigger on requests like "delegate this efficiently", "save tokens on this", "use cheap subagents for the heavy parts", or any task where the expensive model's judgment matters but its throughput does not. Treat subagent reports as leads, not facts — always vet before shipping. Do NOT trigger for trivial single-step work, for high-stakes single-source-of-truth tasks (medical, legal, financial advice), or when no cheap subagents are available.From its SKILL.md

Install
npx -y skills add anshmajumdar121/skill-x --skill efficient-fable

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

7.7 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it

Efficient Fable (retweaked)

Use a high-cost frontier model as the orchestrator, architect, synthesizer, and final judge. Use cheaper subagents for the bounded heavy lifting that does not require the orchestrator's full judgment. The orchestrator retains truth-judgment; the subagents retain signal-gathering.

This is the retweaked version adapted for the skill-x collection. The original lives at BuilderIO/skills; this version generalizes the orchestrator role beyond Claude Fable, adds an explicit when-NOT-to-use section, and cross-references the other skills in this collection.

When this skill shines

Reserve the orchestrator for:

  • Decomposing ambiguous work into clean parallel slices.
  • Architecture, product, and safety tradeoffs that need full judgment.
  • Reading conflicting subagent reports and deciding what matters.
  • Integrating partial implementations into one coherent plan.
  • Final review, risk assessment, and user-facing synthesis.

When NOT to use this skill

Skip the delegation pattern if any of these is true:

  • The work cannot be sliced into independent chunks (one tightly coupled piece of logic).
  • No cheap subagents are available (you ARE the orchestrator and the only worker).
  • The task is high-stakes single-source-of-truth (medical, legal, financial advice) — keep all reasoning with the orchestrator.
  • The validation requires reading the entire output carefully (a 30-page legal memo, a 100k-line refactor diff).
  • The task is trivial — overhead exceeds value.

For the above, run in single-agent mode.

The 5-step delegation pattern

  1. Name the expensive-token risk. Large repo search, long logs, broad docs, repetitive edits — anything where naive execution would burn orchestrator tokens.
  2. Split independent work into subagents BEFORE reading everything yourself. Parallel slices for independent work; keep blocking or highly coupled work local.
  3. Use cheap subagents for: research scans, inventory, search summaries, narrow bug hunts, browser/testing passes, test output reduction, bounded code edits.
  4. Ask subagents for concise evidence. Files, line references, commands run, diffs, failures, screenshots, uncertainties, stop conditions they hit. See handoff packet format (§below).
  5. Spend orchestrator tokens on the decision layer. Compare results, resolve conflicts, choose the implementation path, review the final patch.

Parallelize only independent actions. Do not run actions in parallel when one depends on the result, identifier, decision, or side effect of another.

The vetting protocol (CRITICAL)

Treat subagent reports as leads, not facts.

Before using a high-impact finding, opening a PR, or telling the user the work is done, the orchestrator should:

  1. Reopen the important cited files — confirm the subagent looked at the right thing.
  2. Confirm the relevant line refs or failures — line numbers and error messages must match the actual state.
  3. Review the final diff against the task — does the change actually solve the problem, not just something adjacent?
  4. Test the change if material — run the verification, don't trust the subagent's "it worked" report.
  5. Look for silent assumptions — subagents often invent defaults that the orchestrator wouldn't.

Let lighter agents gather signal; keep truth-judgment with the orchestrator. This is the line that, if dropped, makes delegation unsafe.

Handoff packet format

Write delegated prompts as if the subagent has no useful chat context. Include only the context it needs:

  • The repo path and exact objective. What does "done" look like?
  • The files, packages, or surfaces in scope and anything explicitly out of scope. Boundaries reduce drift.
  • The evidence format to return. Files, line refs, commands, diffs, failures, screenshots, uncertainty.
  • The verification commands or browser flows to run, plus what success should look like when knowable.
  • Stop conditions. If the code does not match the prompt, a command fails after a reasonable retry, or the task needs out-of-scope files, stop and report instead of improvising.

Soft scenario defaults

Treat these as defaults, not rigid rules. Adapt to the task.

Research

  • Ask lighter agents to scan docs, prior art, APIs, and repo surfaces.
  • Orchestrator decides what evidence changes the plan.
  • Subagent output: list of relevant files + 1-line summary each, or detailed answer to a narrow question.

Coding

  • Give cheaper agents bounded edits or candidate patches.
  • Orchestrator owns: shared-file coordination, integration, final review.
  • Subagent output: diff with before/after, line refs, test run results.

Testing

  • Orchestrator suggests validation direction and the scripts / browser checks that matter.
  • Lighter agents run targeted tests, browser flows, screenshots, log reduction.
  • Subagent output: exact commands, failures, likely causes, whether failures look flaky, environmental, or real.

Debugging

  • Use cheaper agents to cluster logs, reproduce issues, try small fixes.
  • Orchestrator decides which diagnosis is most trustworthy.
  • Subagent output: ranked list of likely root causes with evidence.

If a task is tiny or the validation itself needs delicate judgment, keep it with the orchestrator.

Diagram

See assets/fable-orchestrator.png for the orchestrator-helpers diagram.

Claims (workload-dependent estimates, not guarantees)

For codebase-heavy work, this pattern is "up to 3-5× more cost-efficient and 2-4× faster" when independent research, coding, or testing slices can run in parallel. Actual savings depend on: how parallelizable the work is, the cost ratio between the orchestrator and subagents, and the overhead of handoff packets + vetting.

How this fits the rest of the skill-x collection

  • Use think-like-gpt-5-6 when you need full auditable task-execution rigor (intake record, requirement IDs, risk register, validation report, completion note). Delegation is a cost optimization; rigor is a quality optimization. They are compatible.
  • Use super-skill when you want both: the GPT-5.6 Sol rigor framework as the outer loop, with the Efficient Fable delegation pattern as a fast lane when parallelizable.
  • Use skill-zero when your task is specifically about probing the hidden states of a coding agent (mechanistic interpretability via linear probes).

Pointers

What ships with it: 3 files

236.5 KB alongside SKILL.md

assets/

Gives 0 of the 12 instructions most architecture codebase skills give in ~1.6k tokens

Counted across 858 of the 1,304 authors here whose files we hold, read 2026-09-06

  • Apply the deletion test to identify shallow modulesin 32 of 858, across 31 files
  • Read domain glossary and ADRs before exploringin 22 of 858, across 19 files
  • Use Tailwind and Mermaid via CDN for reportsin 21 of 858, across 18 files
  • Document architecture decision recordsin 20 of 858, across 12 files
  • Offer to record ADRs for rejected candidatesin 17 of 858, across 14 files
  • Limit primary navigation to four to seven itemsin 17 of 858, across 7 files
  • Write HTML report to the system temp directoryin 17 of 858, across 14 files
  • Read product marketing context before asking questionsin 16 of 858, across 6 files
  • Use Mermaid graph TD for visual sitemapsin 15 of 858, across 5 files
  • Ensure every page has at least one internal linkin 15 of 858, across 5 files
  • Use ASCII tree format for page hierarchy draftsin 15 of 858, across 5 files
  • Enforce lowercase URLs with hyphensin 15 of 858, across 5 files

Said here and by no other author read

  • Split independent work into parallel subagent slices
  • use frontier models as orchestrators
  • use cheap subagents for bounded heavy lifting
  • vet all subagent reports before shipping
  • reopen cited files to confirm subagent findings
  • verify subagent line references and error messages

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.