القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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).
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.