القائمة
Produces a <DOMAIN>-BRIEF.md priming a pack's gates before a non-content, non-visual domain build. Use before that build; not for content (content-brief) or visuals (design-brief).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 | domain-brief |
| description | Produces a <DOMAIN>-BRIEF.md priming a pack's gates before a non-content, non-visual domain build. Use before that build; not for content (content-brief) or visuals (design-brief). |
The generic front-end of every domain pack — the systems-not-skills analogue of content-brief
(content) and design-brief (visual). Instead of one brief skill per domain, this ONE skill reads the
resolved domain pack as data (the same way the kernel does) and turns "what they're producing in this
domain" into a concrete domain contract (<DOMAIN>-BRIEF.md) before the executor produces a thing.
The deterministic scaffolder brief-emit.py pulls the pack's cross-cutting spec checks + the sub_target's
must-declares + the gates to prime; you (the skill) fill them with real values and push back on thin inputs.
Does: resolve the domain + sub_target from intake.json, run brief-emit.py --domain <id> --sub-target <st> to scaffold the pack's must-declares, fill them with concrete decisions (clarifying when thin), and
write <DOMAIN>-BRIEF.md that the pack's gates audit the deliverable against; write a domain-brief receipt.
Does not: produce the deliverable itself (the executor does, under this brief), run the verification
mode (the pack's gates do — this primes them), or override the two specialized briefs (content/visual).
content-brief (richer audience/voice/outline treatment).design-brief (DESIGN.md + DTCG tokens).specify + the software overlay already carry the contract; no separate brief.<DOMAIN>-BRIEF.md already fits and nothing changed — edit it; do not rewrite the contract the build depends on.| Situation | Reference |
|---|---|
| Scaffold the brief from a pack | ./brief-emit.py --domain <id> --sub-target <st> |
| The pack's checks · must-declares · gates | ../../../domains/<id>/acceptance/{overlay,sub-targets}.md · domain.yaml |
| Per-sub_target vocabulary | ../../../domains/<id>/vocabulary.md |
domain + sub_target (from state/intake.json), or establish them via clarification.library/domains/<id>/ (read as data — never hardcode a domain here).intake.json. If the domain is content/visual/software, defer per When NOT to use.python brief-emit.py --domain <id> --sub-target <st> --out <DOMAIN>-BRIEF.md. This pulls the pack's overlay checks + the sub_target's must-declares + the gates + the verification mode — all from pack data.<DOMAIN>-BRIEF.md at the product root — persistence Spec-Anchored (versions with the deliverable). Carries the filled spec inputs, the sub_target's must-declares, and the gates + verification mode it primes.<workspace>/receipts/domain-brief-receipt.json): base schema + domain, sub_target, checks_filled, gates_primed, verification_mode, brief_path. persistence: Spec-Anchored.brief-emit.py flags it as not-in-matrix — resolve to a real sub_target so the must-declares load.Done when: a <DOMAIN>-BRIEF.md exists with every pack check filled (or N/A + reason), the sub_target's must-declares present, and a domain-brief receipt records the domain + gates primed.
Not done if: any field is still a scaffold placeholder; the sub_target was guessed; it was run for content/visual/software (those have their own path).
Next step: the executor produces the deliverable under the brief; the pack's gates verify it against the filled contract.