Feature brief

Turn a problem into one accepted bet: what we believe users need, how we will know, and what done means before anyone builds it. The brief exists to lower the costs that remain when building is cheap: building the wrong thing, building what cannot be undone, and validating under conditions kinder than production.

The brief owns only what no other skill owns: the problem and its evidence, triage, measurement, critical journeys, representative budgets, and rollout. For everything else it holds a pointer to another skill's accepted result.

Authority

The human decides the problem framing, the solution direction, the measurement profile, the success metric, the decision threshold, and every cut. Storage, public contracts, migrations, and other costly-to-reverse technical shapes belong to architect: record the human's preference about one as a constraint for architect, not as a settled design. Challenge the evidence you are given and label each claim observed, reported, or assumed, including your own: a guarantee you recommend without evidence is assumed.

Process

1. Frame the problem. Record who has the problem, what it costs them, how they cope today, and the evidence behind it. Settle with evidence everything evidence can settle before asking: inspect the repository, the deployment and where the affected system actually runs, and the available data; search the tracker for related and duplicate open issues; run research when an answer depends on outside facts, such as how reference products or the platform handle it. List the solution options, including an existing tool or package and doing nothing, before validating the one the issue prescribes. Ask the human only what remains theirs to decide. If no one can name who has the problem, return Not ready.
2. Triage. Rate three risks high or low: value uncertainty (do we know they need it?), visible surface (does it change what someone sees or does?), and irreversibility (data, public contracts, migrations, anything costly to undo). Implementation effort is not a criterion. All three low: write the minimal brief, only the sections marked minimal in the document contract, and run only the steps that produce them. Any high: write the full brief. High irreversibility names the question that makes it high; that question goes to architect in step 4 before the brief is accepted.
3. Set the measurement profile. Read the project's profile from its agent instructions (AGENTS.md or equivalent). If none exists, agree one with the human:
   • A, personal or no users: the author is the user. Success is sustained real use; quality is enforced by lab budgets in CI. No scheduled review after release: a failure in real use becomes an issue. Rollout is revert and release again.
   • B, few known users: evidence comes from observing and asking named people; adoption is counted per person; rollout goes person by person. Traffic is too small for A/B tests.
   • C, active users with traffic: cohort analytics, field percentiles, guardrail metrics, and percentage rollouts; experiments only when traffic supports them.