# Brief From Pain > Use when turning a validated customer pain and a first-pass IA into a design brief, before any prototype prompt. Triggers on a named pain plus a request for a brief or "what should we build." Will not write a brief until success is defined in advance; an unvalidated pain proceeds only as an explicit owned bet, and the bar is never excused. - **Type:** Skill - **Install:** `agentstack add skill-royvergara-design-team-os-brief-from-pain` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [royvergara](https://agentstack.voostack.com/s/royvergara) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [royvergara](https://github.com/royvergara) - **Source:** https://github.com/royvergara/design-team-os/tree/main/skills/brief-from-pain ## Install ```sh agentstack add skill-royvergara-design-team-os-brief-from-pain ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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](https://github.com/royvergara) - **Source:** [royvergara/design-team-os](https://github.com/royvergara/design-team-os) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-royvergara-design-team-os-brief-from-pain - Seller: https://agentstack.voostack.com/s/royvergara - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.