delegation-brief
GitHub用于生成高质量委托简报，明确任务成果、背景约束及自主权等级。通过预设检查点防止偏差，确保接收方准确理解意图并独立执行，解决委托中因信息缺失或边界不清导致的结果不符问题。
触发场景
安装
npx skills add mohitagw15856/pm-claude-skills --skill delegation-brief -g -y
SKILL.md
Frontmatter
{
"name": "delegation-brief",
"description": "Delegate so the work comes back right the first time — the brief that transfers outcome, context, and constraints (not just the task), the autonomy level stated explicitly, and the check-in design that catches drift without hovering. Use when asked hand this off properly, my delegations come back wrong, write a brief for this task I'm giving away, or how much detail do I give. Produces the delegation brief with the outcome and guardrails, the autonomy level, the check-in points, and the questions-welcome contract."
}
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 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
- 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 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.
- 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.
- 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.
- 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.
- 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 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])
版本历史
- 471c606 当前 2026-07-22 14:02
