delegation-brief

Delegation Brief Skill

Delegation fails at the handoff, not the execution: the task transferred without its outcome ("send me a draft" — of what, for whom, to achieve what?), without its constraints (discovered as rejections later), without the autonomy level (so the delegate either hovers back with every micro-decision or runs confidently off the map). The brief fixes the transfer: the outcome with its done-test, the context that makes judgment possible (why this matters, who it's for), the guardrails (the true constraints, and only the true ones), the stated autonomy level, and check-ins placed where drift is cheapest to catch — at the first artifact, not the final one.

What This Skill Produces

• The brief — outcome + done-test, context, guardrails, resources, the deadline with its real/soft nature stated
• The autonomy level, explicit — decide-and-do / decide-then-tell / propose-then-decide-together — per decision type
• The check-in design — the early-artifact review that catches drift at 10% cost, and the drop-in-anytime contract
• The receiving-side test — the brief read back: can the delegate state the outcome and the first step? ([runbook-writer](../runbook-writer/SKILL.md) stranger-test, for handoffs)

Required Inputs

Ask for these if not provided:

• The task and its real outcome — what does done look like, observably, and what is this for (the context that lets the delegate make the hundred small calls the brief can't enumerate)
• The delegate's altitude — their experience with this work-kind; the brief's grain and the autonomy level calibrate to the person, not the task alone
• The true constraints — the actual guardrails (budget, tone, the stakeholder landmine, the deadline's hardness) — separated from the delegator's preferences, which are optional and labeled
• The delegator's honest failure mode — hoverer or vanisher? The check-in design compensates for the actual person on both ends

Framework: The Brief Rules

1. Outcome and done-test, not activity: "the vendor comparison ready for Thursday's decision meeting — done means: the three finalists scored on our criteria, one page, [decision-meeting-format](../decision-meeting-format/SKILL.md) pre-read grade" — the activity version ("look into vendors") delegates confusion. The done-test is what makes "is this what you wanted?" answerable by the delegate alone.
2. Context is the judgment transfer: two sentences of why-this-matters and who-consumes-it — because the delegate will face fifty unbriefed micro-decisions, and context is the only thing that lets them decide those the way you would. Task-without-context delegation produces exactly-what-you-said-not-what-you-meant.
3. Guardrails are true constraints only: the real limits (the budget, the do-not-contact, the hard date) — stated as guardrails — and the preferences ("I'd probably format it as a table") — labeled as optional. Briefs that dress preferences as constraints train delegates to wait for specs; the labeled split is what grows them.
4. Autonomy is stated, per decision class: "vendor shortlist: decide-and-do · pricing negotiation: propose first · anything touching Legal: bring it to me" — the three-level vocabulary, applied explicitly, replaces the guessing game that produces both hovering and overreach. Default for the capable: decide-and-tell.
5. Check-ins catch drift early and are not surveillance: one review at the first artifact (the outline, the first section — where wrong direction costs 10%, not 90%), the milestone check for long work, and the standing contract: "questions anytime — asking early is the pro move, not the failure" ([onboarding-buddy-plan](../onboarding-buddy-plan/SKILL.md) safety logic). The vanisher schedules these because they won't happen ambiently; the hoverer commits to only these.

Output Format

Delegation Brief: [task] → [delegate]

Outcome: [what done looks like + the done-test]

Why/for whom: [the two context sentences]

Guardrails (真 constraints): [the true limits] · Preferences (optional, labeled): […]

Autonomy: [per decision class: decide-and-do / decide-tell / propose-first]

Deadline: [date + hard/soft stated] · Resources: [access, prior art, the person to ask about X]

Check-In Design

[First-artifact review at (date) · milestone (if long) · the questions-welcome contract, said]

The Read-Back

[The delegate states outcome + first step — gaps patched now, not at delivery]

Quality Checks

• [ ] The outcome has a done-test the delegate can self-apply
• [ ] Context (why/for-whom) is present — not just the task
• [ ] Constraints and preferences are separated and labeled
• [ ] Autonomy is explicit per decision class
• [ ] The first-artifact check-in is scheduled, and the read-back happened

Anti-Patterns

• [ ] Do not delegate activities — outcomes with done-tests, or you'll get exactly what you said
• [ ] Do not smuggle preferences as constraints — it caps the delegate at your imagination
• [ ] Do not leave autonomy implicit — the guessing game produces hovering and overreach in equal measure
• [ ] Do not review only the final artifact — drift caught at 90% is a rewrite with feelings
• [ ] Do not take the work back at the first wobble — the brief gets patched, the delegate keeps the pen ([the growth is the point])