From a02a8d339df3a7066c09f835009aab878abb09a5 Mon Sep 17 00:00:00 2001 From: Oskar Date: Fri, 3 Jul 2026 15:24:13 +0700 Subject: [PATCH] docs(efficient-fable,efficient-frontier): add four delegation prompting practices Both skills tell an orchestrator how to write handoff packets and vet delegated work, but they were missing four practices that materially improve subagent output: - State the "why": one line of operational intent per handoff so the subagent makes correct micro-decisions instead of guessing. - Explicit negative scope ("don'ts"): keeps cheaper models from refactoring beyond the ask, adding features, or fixing unrelated code. - Act once you have enough info: don't loop on planning/re-delegating, and match effort/model tier to the task. - Make it prove it: require the command + its output, the diff, or file:line evidence before accepting "done". efficient-frontier mirrors efficient-fable, so both get the same edits to stay in parity. Prose-only; no frontmatter or structure changes. --- skills/efficient-fable/SKILL.md | 24 ++++++++++++++++++++---- skills/efficient-frontier/SKILL.md | 13 ++++++++++--- 2 files changed, 30 insertions(+), 7 deletions(-) diff --git a/skills/efficient-fable/SKILL.md b/skills/efficient-fable/SKILL.md index 5ae9cc8..40c7a14 100644 --- a/skills/efficient-fable/SKILL.md +++ b/skills/efficient-fable/SKILL.md @@ -35,25 +35,41 @@ Reserve Fable for: Prefer parallel subagents when the slices do not depend on each other. Keep blocking or highly coupled work local. +Once Fable has enough information to act, act. Do not loop on planning, +re-scanning, or re-delegating work that is already understood — orchestration +overhead is a cost like any other. Match the tier to the task: low +effort/cheapest models for mechanical scans and edits, higher effort only for +the hardest verify and judge steps, Fable itself only where its marginal +judgment matters. + ## Handoff Packets Write delegated prompts as if the subagent has no useful chat context. Include only the context it needs: - The repo path and exact objective. +- The why: one or two sentences of operational intent — what decision the + output feeds ("this scan determines whether the fix belongs in parser or + renderer"), not motivation ("to improve quality"). - The files, packages, or surfaces in scope and anything explicitly out of scope. +- Explicit don'ts: what the subagent must not do (refactor beyond the ask, add + features, fix unrelated issues, invent abstractions). Negative scope keeps + cheaper models focused. - The evidence format to return: files, line refs, commands, diffs, failures, screenshots, and uncertainty. - The verification commands or browser flows to run, plus what success should look like when that is 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. +- Stop conditions: if the code does not match the prompt, a command fails twice + after a reasonable fix or retry, or the task needs out-of-scope files, stop + and report instead of improvising. ## Vetting Delegated Work -Treat subagent reports as leads, not facts. Before using a high-impact finding, +Treat subagent reports as leads, not facts. Make subagents prove completion: +a "done" without the specific command run and its actual output, the diff, or +the file:line evidence is a claim, not a result — send it back or verify it +yourself. Before using a high-impact finding, opening a PR, or telling the user the work is done, Fable should reopen the important cited files, confirm the relevant line refs or failures, and review the final diff against the task. Let lighter agents gather signal; keep diff --git a/skills/efficient-frontier/SKILL.md b/skills/efficient-frontier/SKILL.md index 0d8266c..f3563bd 100644 --- a/skills/efficient-frontier/SKILL.md +++ b/skills/efficient-frontier/SKILL.md @@ -24,9 +24,11 @@ repeatable, bounded, or token-heavy work to cheaper/faster subagents. ## Handoff Packets Write delegated prompts as self-contained packets. Assume the receiving agent -has not seen the conversation. Include the repo path, objective, scope, -out-of-scope areas, relevant files or search targets, expected return format, -verification commands, and stop conditions. +has not seen the conversation. Include the repo path, objective, the why (one +or two sentences of operational intent — what decision the output feeds, not +motivation), scope, out-of-scope areas, explicit don'ts (no refactors beyond the ask, no new +features, no unrelated fixes), relevant files or search targets, expected +return format, verification commands, and stop conditions. Useful stop conditions: @@ -60,6 +62,11 @@ Use these as soft suggestions: ## Guardrails - Do not delegate the immediate blocker if your next step depends on it. +- Do not loop on planning or re-delegating once you have enough information to + act — orchestration overhead is a cost too. Match effort and model tier to + the task instead of defaulting to maximum machinery. +- Do not accept "done" without proof: require the specific command run and its + output, the diff, or file:line evidence backing the claim. - Do not ask multiple agents to edit the same files at the same time. - Do not trust subagent conclusions blindly when the risk is high; inspect the important evidence yourself.