## TL;DR
A good brief has the goal, the constraints, the resources, the definition of done, and explicit stop conditions; everything else is context the agent can look up. Write the brief so the agent never has to ask you a question, because mid-task questions mean the brief failed. The test: could a smart stranger do the task from the brief alone.

```text
how to brief a subagent so it doesn't need you
```

## Use this when
- You are delegating a task to a subagent
- Subagents keep asking clarifying questions mid-task
- A delegated task came back wrong and you are not sure why
- You are building a fleet and need a briefing standard
- You want delegation to be fire-and-forget

## Not for this skill when
- The task needs your judgment at multiple steps (do not delegate what needs you)
- You are coordinating many agents on one complex goal (orchestration, different skill)
- The task is a five-minute job (briefing overhead exceeds the work)
- You are writing prompts for end users (different audience)

## Steps
1. State the goal as an outcome, not an activity. "Publish 40 skills, each verified live" beats "work on the publishing queue". The agent optimizes for what you name; name the done state.
   ```text
   goal: [observable outcome]
   done looks like: [concrete evidence]
   ```
   Expected output: a goal line. Success check: you could verify completion without asking the agent anything.

2. List the constraints that actually bind: what not to touch, what not to spend, what needs approval, where the boundaries are. Agents default to maximum latitude; constraints are how you lend judgment in advance.
   ```text
   hard constraints: [do not touch X, do not spend Y, stop on Z]
   ```
   Expected output: explicit constraints. Success check: the scariest plausible misbehavior is named and forbidden.

3. Point at resources instead of pasting them. File paths, doc links, prior briefs; the agent can read. Paste only what cannot be read (a decision, a preference). Briefs that paste everything go stale; briefs that point stay current.
   ```text
   read first: [paths], then: [paths]
   ```
   Expected output: a reading list. Success check: the brief is under a page; the resources carry the weight.

4. Define stop conditions explicitly. Halt signals, error thresholds, "do not retry more than N times", and what to do when stuck (report back with X, do not improvise). Stop conditions are the difference between a failed task and a runaway one.
   ```text
   stop and report if: [conditions]
   on stop: [what to deliver back]
   ```
   Expected output: written stop conditions. Success check: you can name the exact situation where the agent must not continue alone.

5. Specify the report-back format. What the final message must contain: counts, ids, failures with reasons, open questions. A good brief ends with "your final report should include..." so the handoff back is as structured as the handoff out.
   ```text
   report back: [counts, failures with reasons, open questions]
   ```
   Expected output: a report contract. Success check: the returned report needs no follow-up questions.

## Variant phrasings
### How to prompt a subagent effectively
Prompting phrasing. Steps 1 through 5 are the prompt structure: goal, constraints, resources, stops, report.

### Delegating to AI agents without micromanaging
Management phrasing. The brief is the management: invest in it upfront, then stay out of the way.

### Subagent brief template
Template phrasing. The five sections as a copy-paste template.

### Why do subagents keep asking me questions
Diagnostic phrasing. The brief missed something; find which of the five sections was thin and thicken it next time.

## Why it happens
Subagents have no shared context with you beyond the brief; every assumption you leave unstated becomes a guess, and guesses compound over a long task. Questions mid-task are the symptom: the agent hit an unstated assumption and correctly refused to guess. The brief works when it transfers your judgment (constraints, stop conditions, done criteria) instead of just your instructions.

## Edge cases / pitfalls
- Over-briefing is real. A ten-page brief for a one-hour task wastes more than it saves; match brief depth to task size and irreversibility.
- Briefs go stale. If the task recurs, the brief needs the same maintenance as code; a stale brief briefs the agent into last quarter's world.
- Do not delegate your judgment calls disguised as tasks. "Decide the strategy and execute it" is not a brief; it is abdication with extra steps.
- The agent cannot know what you forgot to say. After a bad delegation, the fix is usually in your brief, not in the agent; update the template, not just the instance.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_l7G3bd2Q0qaZ_TcRo96GhA