agent-brieflisted

# Agent Brief ## Overview A good brief describes the **destination and how you'll know it's reached**, then hands over the driving. Method-specification creeps in only when you don't trust the agent to find a good route — the fix is a sharper target and clearer fences, not more steps. Spend your words on the goal and the boundaries; leave the method box near-empty. ## The skeleton Fill these in order. `METHOD` is usually the smallest box — often empty. | Field | The question it answers | |-------|-------------------------| | **GOAL** | What end-state, in observable terms? (Not "improve X" — "X does Y when Z".) | | **WHY** | What problem does this solve / who's hurting? The agent generalizes from intent when reality deviates from the plan. | | **DONE WHEN** | How will *you* check it? Concrete inputs → expected results. If you can't state the check, the agent can't aim at it. | | **DON'T** | Non-goals, out-of-scope, hard constraints. The negative space is where most misfires live. | | **AUTONOMY** | Proceed freely, but stop and ask if: … (calibrate to reversibility — tighter fences on auth, migrations, deletions, anything outward-facing). | | **PROVE IT** | What evidence back? "Ran it against the three broken inputs, pasted the output" — not "should work". | | **METHOD** | Usually empty. If you must constrain the route, say *why*, so the reason travels to cases the rule doesn't cover. | ## Worked example **Weak (method-shaped, uncheckable):** > Improve the error handling