---
name: delegation-brief
description: Turn a rough request into a precise AI assignment with outcome, evidence, authority, review, and stop conditions. Use when delegating consequential or multi-step work to an agent.
license: All-Rights-Reserved
metadata:
  author: Zain Haseeb
  version: 1.0.0
  category: ai-delegation
  tags: [delegation, agents, approvals, verification]
---

# Delegation Brief

Convert an ambitious request into an assignment an AI agent can execute without guessing at the mission, quietly expanding its authority, or declaring success without proof.

## Critical behavior

1. Define the result in observable terms before describing activity.
2. Separate reversible preparation from external, destructive, costly, private, or reputation-sensitive action.
3. Make source hierarchy, evidence needs, and human decisions explicit.
4. Ask only the question that could materially change the assignment.
5. Define a real stop condition. Do not use "until perfect" or "do your best."
6. Require demonstration through a test, source check, render, or end-to-end run.

## When to use

Use this skill before asking an agent to research, build, change files, coordinate tools, prepare a launch, or run a long task. It is especially useful when the request includes "finish it," "do not stop," "handle everything," or access to sensitive systems.

Do not use it to add ceremony to a trivial, reversible, one-step request.

## Build the brief

### 1. Find the real outcome

Rewrite the request as one sentence naming:

- who benefits;
- what will be different;
- the artifact or state that proves it;
- why it matters now.

Reject activity-only goals such as "research competitors" or "improve the site." Replace them with a decision, artifact, or verified state.

### 2. Define the completion bar

List binary or measurable acceptance checks. Include content completeness, quality threshold, source verification, technical tests, rendered inspection, and the exact environment where success must be demonstrated.

If quality is subjective, name contrasting examples or failure patterns instead of saying "polished" or "first class."

### 3. Bound the assignment

Write four scopes:

- In scope: systems, files, people, and time range the agent may inspect or change.
- Out of scope: adjacent systems and tempting expansions.
- Allowed without approval: read-only checks and safe reversible preparation.
- Requires approval: publishing, sending, deploying to production, purchasing, deleting, changing permissions, exposing private data, or any other consequential edge.

Never interpret positive feedback as approval for an external action.

### 4. Set the evidence contract

Name governing sources, supporting sources, freshness requirements, and conflict rules. Specify what the agent must label as sourced, derived, inferred, or guessed. Require the weakest load-bearing claim to set the confidence of the result.

### 5. Design checkpoints

Create ordered checkpoints only where later work depends on earlier judgment. Each checkpoint must have:

- expected state;
- verification;
- evidence recorded;
- recovery action if it fails.

Parallelize only independent work. Preserve settled decisions unless evidence or the objective changes.

### 6. Write the stop condition

Stop when every acceptance check passes and the deliverable exists in the named location. Stop early and report a blocker when progress requires new authority, inaccessible evidence, unresolved rights, or a materially different objective.

## Output format

Return a copy-ready assignment with these sections:

1. Objective
2. Deliverable
3. Audience
4. In scope
5. Out of scope
6. Source hierarchy
7. Acceptance checks
8. Allowed actions
9. Approval gates
10. Checkpoints
11. Stop condition
12. Brief-back questions

End with three brief-back questions the receiving agent must be able to answer: What outcome are you producing? What may you do without approval? What evidence will prove completion?

## Example

Input: "Make the resource hub great and put it online."

Output: a bounded goal naming audience, content thresholds, protected preview rather than production, attribution requirements, tests, browser sizes, rights exclusions, deployment protection, and a stop before public promotion or domain changes.

## Troubleshooting

- If the brief becomes longer than the work, remove fields that do not change execution or risk.
- If the agent still asks many questions, inspect ambiguous authority, source hierarchy, or acceptance checks.
- If work drifts, restate the mission and compare the next action against the deliverable.
- If the user changes the objective, replace the contract explicitly rather than stacking contradictory goals.

## What not to do

- Do not grant permissions the user did not grant.
- Do not treat a checklist as proof that the work passed.
- Do not hide missing evidence behind a confidence label.
- Do not create open-ended persistence without a verifiable end state.
- Do not reopen settled decisions because a new direction is more interesting.