task-brief

Task Brief

Thin requests are the biggest cause of mediocre agent output: the agent guesses the deliverable, the audience and the guardrails, and the user only discovers the misreading after the work is done. This skill moves that discovery to the cheapest possible point — before the work starts — by having the agent compile a short task brief, show it, and only then execute. The user never has to write a better prompt; the agent does the structuring.

When to run it — and when not to

Run it when:

• the user explicitly asks ("brief this first", "make sure you understand before starting"); or
• the task is substantial — multi-step, multi-document, or a deliverable someone else will read (a memo, a report, a dashboard, a document batch) — and the request is thin or ambiguous enough that two reasonable readings would produce different work.

Skip it (just do the task) for quick factual questions, single-step edits, and requests already crisp enough to act on. A brief on a trivial ask is friction, not quality — proportionality is part of the skill. When in doubt, a one-line restatement of the goal ("I'll read this as X — say if not") beats a full brief.

The brief

Compile and show this exact shape — short, in plain business language:

**Task brief — [short task name]**
- **Goal** — what "done" looks like: the deliverable, its format, its audience,
  and the test it must pass.
- **Context** — everything known that bears on the task: the inputs/files
  provided, relevant background from the conversation or memory, the entities /
  period / parties involved, what already exists.
- **Constraints** — what to avoid and the guardrails: task-specific limits
  (scope, exclusions, deadline, tone) plus whichever standing rules materially
  bite this task (see below).
- **Assumptions** — anything filled in without asking, flagged so the user can
  correct it with one word.
- **Tooling** — the installed skill(s) or tool(s) that will do the work.