product-brief

name	product-brief
description	Produces a product contract - PRODUCT-BRIEF.md (problem, persona, success metric, non-goals) - before any solution; primes the editorial + accessibility gates. Use before speccing or building a product.

product-brief

The front-end of the product domain — the product analogue of content-brief/design-brief. You turn "what we're building, for whom, and why now" into a one-page, decision-ready product contract (PRODUCT-BRIEF.md: problem, persona, success metric, non-goals) before any feature or solution is proposed. Solution-first is the failure mode; this skill forces the problem, the person, and the definition of success to be decided first, so the PRD (prd), the build, and the editorial / accessibility gates have a contract to be judged against. Verified by Attestation — a named human owner attests the call is sound and owns it (there is no test or measurement at decision time).

What this does / does not do

Does: resolve the product sub_target (product-brief), establish the problem + a specific persona + a falsifiable success metric + explicit non-goals (clarifying when the brief is thin), and write a PRODUCT-BRIEF.md that the editorial/accessibility gates and the downstream prd build against; write a product-brief receipt naming the attestation owner. Does not: write the PRD (prd does), design the solution or enumerate features (a brief is problem-space, not solution-space), run the gate verdict (the gates do — this primes them), or apply to a pure code/content task with no product decision to make.

When NOT to use

• There is no product decision — it is a pure code/content task. Use the software/content path.
• A current, committed PRODUCT-BRIEF.md already fits and nothing changed — re-running rewrites a contract the PRD and build are built against; edit the brief instead.
• The user wants requirements / user stories / acceptance criteria — that is prd, which builds on this brief.
• The user wants the brief judged/attested — that is the editorial/accessibility gates + the Attestation owner, not product-brief (this primes them).

Reference Routing

Situation	Reference
The PRODUCT-BRIEF.md contract template	references/product-brief-template.md
Per-sub_target must-declares · overlay · vocabulary	../acceptance/sub-targets.md · ../acceptance/overlay.md · ../vocabulary.md

Inputs

• The product need: the problem to solve, who for (persona), why now; the success metric and non-goals (or establish them via clarification).
• Mode B only: an existing pitch / doc / repo to extract an implicit brief from.
• The product domain pack (../vocabulary.md, ../acceptance/) + state/intake.json.

How to do it

Mode A — from intent

1. Resolve the sub_target (product-brief) from intake.json; load its must-declare row in ../acceptance/sub-targets.md and the overlay checks in ../acceptance/overlay.md.
2. State the problem before any solution (the ordering heuristic): the problem + the specific persona (a person + their context + the job they are trying to do, not "users") + why now. If thin, run the Clarification Protocol — do not write the brief on "users" + "make it better"; push for concrete words.
3. Define the success metric — a falsifiable definition of done the artifact is later attested against (a number or an observable outcome, not "delight").
4. Bound it with non-goals — what this is explicitly not, so scope is decided, not discovered.
5. Write PRODUCT-BRIEF.md from references/product-brief-template.md with the chosen values + the sub_target's must-declares + a named attestation owner; keep it to one decision-ready page.

Mode B — from existing

Read the existing pitch / doc / repo; extract the implicit problem, persona, success metric, and non-goals; flag where they are missing, vague, or solution-first; write the PRODUCT-BRIEF.md that should have governed it, recording gaps as flagged assumptions (record_type alert) for validation.

Gate (before marking complete)

• The problem is stated before any feature/solution (no solution-first).
• The persona is a specific person + context + job, not "users".
• The success metric is falsifiable (observable / measurable), not a vibe.
• Non-goals are explicit. - [ ] An attestation owner is named.
• Evidence and assumptions are separated (claims cited or flagged).
• The sub_target's must-declares are present (or N/A with a reason).

A gate failure is fixed before lock, not waived — these mirror the editorial/accessibility gates and the product overlay so the brief passes the audits it primes.

Output

• PRODUCT-BRIEF.md at the product root (or product/PRODUCT-BRIEF.md if that dir exists) — persistence: Spec-Anchored (versions with the product). Problem · persona · why-now · success metric · non-goals · evidence-vs-assumption · attestation owner · sub_target must-declares.
• receipt (<workspace>/receipts/product-brief-receipt-<ts>.json): base schema + sub_target, problem, persona, success_metric, non_goals, brief_path, attested_by, gate_checks. persistence: Spec-Anchored.

Proactive Triggers

• The persona is "users" / the goal is "make it better": push back for a specific person + a falsifiable success metric before writing the brief — solution-first and vague-success are the product failure modes.
• Features arrive before the problem: redirect to the problem and the job-to-be-done; the feature list belongs in prd, after the brief is attested.
• A market claim with no evidence: flag it as an assumption (record_type alert); do not state it as fact (the compliance / ai gates).

Completion Criteria

Done when: a PRODUCT-BRIEF.md exists with the problem stated before any solution, a specific persona, a falsifiable success metric, explicit non-goals, and a named attestation owner; the sub_target's must-declares are present; a product-brief receipt records the gate checks + who attested.

Not done if: the brief is solution-first; the persona is "users"; the success metric is not falsifiable; non-goals are missing; no owner is named; or it was run for a task with no product decision.

Next step: prd turns the attested brief into scoped requirements; the editorial/accessibility gates audit the artifacts against the brief; the named owner attests the decision (Attestation).

Related Skills

• prd: turns this brief into a scoped PRD (user stories + testable acceptance criteria). product-brief decides the problem/why; prd decides the what. Run product-brief first.
• content-brief / design-brief: the content + visual analogues of this front-end (BRIEF.md / DESIGN.md). product-brief is the decision contract; those are the prose + visual contracts.
• specify: writes the task card (the work's what/why for the pipeline); product-brief writes the product decision contract a PRD/build is judged against. Complementary, not a substitute.