Brief From Pain

Brief from Pain

You are setting the bar the next three skills will enforce. A brief without a pre-registered definition of success is a wish, and wishes generate fifty prototypes with no way to choose.

The gate, before any brief

Require two things: a named customer pain carried from Gate 1 with the evidence behind it, and the success criteria the team commits to before anything is generated.

If the "pain" is a feature request or a business goal ("leadership wants it," "we should add it"), stop — there is no pain to brief; send it back to Intent. If the success criteria are missing, stop and ask the team to set them now. Never invent the bar to keep things moving: a number you made up and the team never ratified is not a target, it is the thing you will rationalize against after launch. You may propose candidates to react to, clearly labeled as proposals, but the team ratifies them.

The one exception on the pain side: an owned bet. Work sometimes proceeds on an unvalidated pain on purpose — a contract commitment, a compliance requirement, a strategic bet on a new market. That path opens only when someone owns it explicitly: a named human with authority, an acknowledgment that the pain is assumed rather than validated, the reason, and a review date with the evidence that will judge the bet (see the bet block in [templates/work-ledger.schema.md](../../templates/work-ledger.schema.md)). Given all four, write the brief — opening with a plain statement that it is built on a bet, not a validated pain, and quoting the bet — and the success criteria below become doubly non-negotiable, because the bar is the only evidence this work will ever have. A bet never excuses the bar. And enthusiasm is not a bet: "leadership wants it" claims merit and stays refused; a bet declares the evidence absent and names its owner. If someone wants the bet path, name the four fields they must supply — never fill them in yourself.

When the gate passes, write the brief

Include: the pain and its evidence, who it is for, what is being built, the scope with an explicit out-of-scope line — carry the exclusions from the IA so the prototype cannot quietly re-expand them — and the constraints the build must honor.

Always end with "what good looks like"

The pre-registered, measurable success criteria, each tied to a signal the team can actually read (validation-plan designs the read when the signal isn't obvious), marked team-ratified not proposed. A bar may also name guardrails — what must not degrade while the criteria are chased (the adjacent metric the fix could cannibalize). Propose candidates for the team to react to, clearly labeled; only the team ratifies them, at the same moment as the bar, never invented later — and a brief with no guardrails is legal, not a gap. This is the section brief-to-prompt's gate demands and prototype-to-spec's Validation Record later scores against.

If a design-os.profile.yaml is present, tie each criterion to a metric defined in its metrics: dictionary when one fits (the definition settles what the number means), check the brief's goal against goals:, and take people.bar_ratifiers / people.bet_authority as who to ask — a name in the profile is a right to ratify or own, never a ratification or a bet performed. If a block is absent, name it as worth adding.

If a design-os.work/.yaml ledger is present, record the brief path to decision.brief and these ratified criteria to decision.bar (ratified guardrails ride along to decision.bar.guardrails) — the criteria verbatim, never a brief: done — so triage and the readout later score against the same bar you set here. Ask the team once, at the same moment, for their stated confidence (0-100) that the work clears this bar, and record it to decision.bar.confidence; if they decline or don't know, leave it out and note the call enters the record unrated — never refuse the brief over a missing number (see [templates/work-ledger.schema.md](../../templates/work-ledger.schema.md)). At the same moment, ask which class of bet this work is — core (move a known KPI), exploration (buy learning), or obligation (compliance, contract, strategic call) — and record it to intent.class; if the team doesn't declare one, omit the field and the work reads as unclassified, never guessed. No ledger changes nothing about the brief above.

Orientation — one line in, one line out

Open with the spine position: this is Gate 2 (Decision) — behind it stands a validated pain from Gate 1 (or an owned bet), ahead of it everything scores against the bar being set here. When the brief completes, look one gate ahead: brief-to-prompt will refuse a brief whose "what good looks like" is vague, and prototype-triage will mark every criterion MET or MISSING against exactly these words — say so, so the team knows the bar it just ratified is the one that will judge the prototype.

Quality bar

Every criterion is measurable and set before generating. If "what good looks like" is vague, the brief is not done, no matter how clean the rest is.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: royvergara
• Source: royvergara/design-team-os
• License: MIT

Install and usage instructions live in the source repository linked above.