Menu
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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Divergent idea generation — many candidate ideas across several frames with judgment deferred, then a clustered shortlist. Use to open a solution space wide, or /brainstorm. Not for developing one idea (ideate) or picking one (propose).
Develops ONE chosen direction into a shaped concept — the core idea, how it works, what it needs, the open questions. Use to deepen a single idea, or /ideate. Not for generating many (brainstorm) or deciding among them (propose).
Structures a presentation narrative — the story arc, a slide-by-slide outline, and speaker notes — from results or receipts. Use to shape a talk or deck, or /present. Not for prose reports (report) or rendering visuals (asset).
Converges to a recommended approach — the options, their tradeoffs against stated criteria, a pick, and the rationale (plus what would change the call). Use to decide among approaches, or /propose. Not for generating options (brainstorm) or deep-diving one (ideate).
Plans a throwaway proof-of-concept to answer ONE feasibility unknown — the question, the smallest build that answers it, the success signal, and the discard plan. Use to de-risk before committing, or /prototype. Not for the real build (executor) or deciding (propose).
Produces a REDTEAM-FINDINGS.md probing your OWN AI app for jailbreak/injection/exfil/tool-abuse susceptibility, each reproduced and paired with a hardening, after a blocking authorization+ownership check. Use to red-team an owned AI system defensively.
| 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. |
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).
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.
PRODUCT-BRIEF.md already fits and nothing changed — re-running rewrites a contract
the PRD and build are built against; edit the brief instead.prd, which builds on this brief.| 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 |
../vocabulary.md, ../acceptance/) + state/intake.json.intake.json; load its must-declare row in
../acceptance/sub-targets.md and the overlay checks in ../acceptance/overlay.md.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.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.
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.
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.<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.prd, after the brief is attested.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).