--- name: brandbook namespace: process description: 'Use WHEN starting a new product, rebrand, or major design-system reset BEFORE prototype work to materialize an approved, machine-readable design system at .supervibe/artifacts/prototypes/_design-system/. Triggers: ''нужен бренд'', ''разработай бренд'', ''фирстиль'', ''брендбук'', ''rebrand'', ''design system'', ''дизайн-система''.' allowed-tools: - Read - Grep - Glob - Bash - Write - Edit phase: brainstorm prerequisites: [] emits-artifact: design-system confidence-rubric: confidence-rubrics/brandbook.yaml gate-on-exit: true version: 2.2 last-verified: 2026-05-14T00:00:00.000Z --- # Brandbook ## Overview This skill owns the design-system lifecycle. It turns an approved creative direction into durable tokens, components, motion, voice, accessibility policy, styleboard evidence, section approvals, and unlock metadata for prototypes. Keep this file as the workflow contract. Long examples, JSON/CSS templates, component catalog prompts, approval marker samples, and producer commands live one hop away in `/skills/brandbook/references/brandbook-examples.md`. ## Local Design Expert Reference Read `/docs/references/design-expert-knowledge.md` before design-facing output. Use `supervibe:design-intelligence`, `designContextPreflight()`, or `searchDesignIntelligence()` before external lookup. Start with Design Pass Triage from the `Eight-Pass Expert Routine` and classify evidence as `required | reuse | delegated | skipped | N/A`. External references are supplemental; local project memory, approved tokens, accessibility, and code evidence win. ## When to Use Use this skill for: - A new product with no approved design system. - A rebrand, repositioning, rename, or material visual shift. - Token drift discovered in prototypes or implementation. - A candidate design system that needs section review or approval. - A narrow extension to an approved design system: token, component variant, motion recipe, copy pattern, asset treatment, or target override. Do not use it for pure moodboarding without operational tokens, one-off prototype styling, or production implementation work. ## Expert Operating Standard Follow `/docs/references/skill-expert-operating-standard.md`: start from source of truth, preserve context evidence, apply scope safety, use real producers with runtime receipts for durable delegated outputs, verify before completion claims, and keep confidence below gate when evidence is partial. ## Swarm-First Durable Work Gate Follow `/docs/references/swarm-first-skill-contract.md`. Named durable worker, reviewer, producer, validator, verifier, or specialist work requires real specialist dispatch through the host/runtime path with selected skill ids, resolved `SKILL.md` paths, runtime receipts or receipt-ready host invocation evidence, and scoped verification evidence. Inline or controller-authored work is diagnostic or trivial-only; it cannot satisfy durable proof, reviewer proof, producer proof, validator proof, verification proof, task closure, or graph task closure. ## Swarm-First Durable Design Gate Durable brand direction and design-system artifacts require specialist producers and receipt-backed proof. Before writing, approving, or handing off a brandbook, token set, styleboard, component catalog, or downstream unlock: - Bind the work to a named brand-direction or art-direction owner before candidate tokens, styleboards, or variants are produced. Variants without selected direction evidence are diagnostic only. - Route durable artifact creation through the owning specialist producer or executable producer and record runtime-issued producer receipts. Controller-authored or inline drafts may inform the brief but must not become durable design implementation. - Run a screenshot critique loop for every visual surface that claims approval, prototype unlock, or handoff readiness. Record critique receipts with viewport list, artifact hash, required fixes, approval or blocker state, and reviewer owner. - Serialize final polish under one named owner after divergent directions or variants converge. Parallel critique may produce findings, but the final polish owner alone records the accepted changes and receipt linkage. - Enforce the no-inline rule: do not inline durable design implementation or proof. If producer, screenshot critique, approval, or polish receipts are missing, mark the output diagnostic-only or `BLOCKED` and name the missing receipt path. ## CodeGraph + Memory pre-flight Before scoring, approving, producing, reviewing, or handing off design artifacts, run project memory, code search, and CodeGraph/design-intelligence lookup for product workflow, existing UI patterns, component states, trust claims, accessibility constraints, and runtime proof needs. Record the source evidence in the artifact report before any score or handoff claim. Record structure history, macrostructure-first reasoning, and section order before visual polish so the artifact is not just a new paint layer on the same shell. ## Anti-AI-Slop Contract Design-facing outputs must also consult `/docs/references/anti-ai-slop-contract.md`. Produce or require an artifact-bound `antiSlopReport.schema` report, cite failures with exact `gateTaxonomy` ids, and fail closed when evidence is missing, a gate id is unknown, any critical gate fails, or any major gate remains unresolved without an evidence-backed waiver. Any design review or handoff output must include the compact `Anti-AI-Slop:` stamp from the contract. P6 design-skill obligations: treat the contract as source of truth before producing, reviewing, approving, handing off, or claiming 10/10 for any design artifact. Skill outputs must require these `antiSlopReport.schema` fields: `antiSlopScore`, `failedGateIds`, `evidence`, `requiredFixes`, `handoffBlocked`, and `waivers`. `antiSlopScore` is invalid until `evidence` binds to the actual artifact through `artifactHash` and `activeScopeHash`; this is the evidence-before-score rule: no evidence, no score, no handoff. `failedGateIds`, `evidenceRequired`, `requiredFixes`, and `waivers` must use exact `gateTaxonomy` ids in taxonomy order; never collapse blockers into generic feedback. Reject generic hero/card/checklist defaults instead of polishing them. Centered 100vh hero, headline/subhead/two CTA/three-card shell, generic checklist output, same-shell-new-paint, generic AI aesthetic, invented credibility, reference clone, unearned decoration, default library look, and weak product specificity must either have artifact evidence clearing the exact gate ids or produce action-level `requiredFixes`. Required gateTaxonomy ids include `visual.same-shell-new-paint`, `visual.generic-ai-aesthetic`, `domain-trust.invented-credibility`, `visual.reference-clone`, `visual.unearned-decoration`, `component-state.default-library-look`, `copy.weak-product-specificity`, `motion.reduced-motion-missing`, `asset.render-proof-missing`, `component-state.coverage-missing`, `domain-trust.claims-substantiated`, and `typography.text-fit-unproven`. Fail-closed handoff: set `handoffBlocked=true` and stop approval/handoff when evidence is missing, a gate id is unknown, severity is weaker than taxonomy default, a critical gate fails or is waived, runtime proof is required but missing, or a major gate lacks an evidence-backed waiver. Waivers are allowed only for major/minor gates and must include `gateId`, `reason`, `owner`, `evidence`, `scope`, and `expiresAtOrRevisit`; waivers never replace missing artifact proof. Keep user-facing summaries compact: emit the `Anti-AI-Slop:` stamp plus failed gate ids, blockers, and required fixes. Put full rationale and evidence in the report, not in a long user-facing checklist. Preserve `claimCapReasons` whenever a score, approval, or handoff claim is capped; do not flatten cap reasons into generic caveats. Design anti-slop gate ids: Reject AI-slop patterns explicitly; do not soften them into preference notes. Required gateTaxonomy ids include `visual.same-shell-new-paint`, `visual.generic-ai-aesthetic`, `domain-trust.invented-credibility`, `visual.reference-clone`, `visual.unearned-decoration`, `component-state.default-library-look`, `copy.weak-product-specificity`, `motion.reduced-motion-missing`, `asset.render-proof-missing`, `component-state.coverage-missing`, `domain-trust.claims-substantiated`, and `typography.text-fit-unproven`. Record structure history, macrostructure-first reasoning, and section order before visual polish. Preserve `claimCapReasons` whenever a score, approval, or handoff claim is capped. ## Step 0 - Read source of truth Before writing candidate or approved design-system artifacts: 1. Read `.supervibe/artifacts/brandbook/direction.md` when present. 2. Read `.supervibe/artifacts/prototypes/_design-system/manifest.json`, `design-flow-state.json`, `tokens.css`, `motion.css`, `voice.md`, `accessibility.md`, `.approvals/*.json`, and `components/*.md` when present. 3. Read the active prototype `config.json` when a slug exists; it determines target, runtime, and viewport policy. 4. Run project memory, code search, CodeGraph/design-intelligence lookup for brand, style, palette, type, component, platform, and regulated-domain evidence. 5. Read `/docs/references/design-expert-knowledge.md`, `/docs/references/creative-reference-taxonomy.md`, and selected local creative packs when a new direction or material shift is required. 6. For `/supervibe-design`, consume the wizard/prewrite state from `node /scripts/design-agent-plan.mjs --brief "" --status --plan-writes --slug ` before durable writes. If the prewrite manifest blocks `durable-design-artifacts`, `review-styleboard`, or `prototype`, write only run state or diagnostic scratch and ask the single next wizard question. ## Decision tree - Existing system is `approved` and the user did not ask for a rebrand -> reuse mode; ask only for the missing extension required by the brief. - Existing system is `candidate` or `needs_revision` -> review/resume mode; do not unlock prototype work. - No system or explicit rebrand -> full-pass mode; complete preference coverage, selected direction, candidate files, styleboard, section review, and approval. - User asks for exploration without operational tokens -> route to creative-director first and return here after direction selection. - User asks for a prototype before approval -> stop and explain which design-system sections block prototype work. ## Procedure 1. Confirm target baseline before durable artifacts: `web`, `chrome-extension`, `electron`, `tauri`, `mobile-native`, or `mixed`. 2. Determine mode: full pass, review/resume, reuse, or narrow extension. 3. Complete the Preference Coverage Matrix Gate for new/rebrand runs using source=`user` or source=`explicit-default`; never source=`inferred`. 4. For referenced old prototypes, sites, screenshots, PDFs, or Figma files, ask the single reference-scope question before reading or using them. 5. Require `.supervibe/artifacts/brandbook/direction.md` with `creative_direction.status = selected` before candidate tokens for new or rebrand work. 6. Prepare candidate material in `.candidates//` or `.scratch//` and archive stale candidates with `node /scripts/design-system-candidate-manager.mjs --archive-stale`. 7. Draft required sections as candidate files: palette, typography, spacing-density, radius-elevation, motion, component-set, copy-language, and accessibility-platform. 8. Build or show `styleboard.html` only after required axes are recorded: target, viewport policy, creative alternatives, anti-generic guardrail, reference scope, visual direction, density, palette mood, type personality, component feel, and motion intensity. 9. Use `node /scripts/brandbook-producer.mjs run ...` to promote prepared design system files. Do not hand-write durable producer outputs for `/supervibe-design`. 10. Ask explicit review/approval for every required section before setting `design_system.status = approved`. 11. Persist global master tokens/components separately from page override records. `master-tokens.json` is the global baseline; `page-overrides.json` may only narrow approved master tokens/components for an explicit page or surface. Each record requires precedence, `sha256:` checksum evidence, current drift evidence, and an approval link (`approvalId`, approval path, or approved timestamp). 12. Keep override paths under `.supervibe/artifacts/prototypes/_design-system/`. Do not point approved override records at project-root-relative Supervibe-owned folders such as `/skills/`, `/scripts/`, `/commands/`, `/rules/`, `/docs/`, `/references/`, or `/templates/`. 13. After approval, recompute status with `evaluatePrototypeTransition` and surface the next visible choice: build prototype, revise design system, or stop at design-system-only boundary. 1. Read the source artifact, owned file paths, graph/task scope, and current project convention; record the evidence path, command, receipt, or runtime state that proves the starting point. 2. If required source, owner, dependency, runtime boundary, or approval is missing, stop and return BLOCKED with the missing field, impacted artifact, and next action instead of guessing. 3. After edits or reviewer findings, repair the smallest changed slice, rerun the same scoped command, and record command, exit code, pass/fail status, artifact path, confidence, and remaining blocker before completion. ## Direction Workshop Packet Before candidate tokens, styleboard output, design-system generation, or section approval for new/rebrand work, produce or require a Direction Workshop Packet. The user-facing summary must stay compact and link to the full skill-owned packet artifact rather than pasting the entire packet inline. The packet must include: - `productWorkflowSummary` - user outcome, audience, target surface or platform, primary workflow, scope boundary, trust/risk posture, named non-goals, constraints, current design-system state, domain evidence, layout archetype, and success/edge/error states that the brand system must support. - `specialistLenses` - product strategy, UX architecture, visual system, accessibility, frontend implementation, brand voice, QA, and any regulated evidence lens used; do not imply runtime invocation without receipt evidence. - `candidateDirections` - two or three materially different brand/system directions. Each direction names workflow, information architecture, interaction model, evidence strategy, implementation risk, palette, typography, density, product character, motion stance, component implications, borrow/avoid references, forbidden styles, anti-generic gate risks, and the artifact it unlocks. - `recommendedDirection` - the recommended option with the tradeoff it accepts, rejected direction tradeoffs, and the reason it fits the user outcome. - `decisionQuestion` - one visible `Step N/M` question with three to five choices, recommended first, each with a one-line tradeoff, plus free-form, pause, and stop paths. - `defaultHandling` - if the user says "use defaults", show `Accept default`, `Compare alternatives`, `Customize`, and `Stop here`; record defaults as explicit-default, never inferred. - `proofPlan` - evidence-packet citation, approved memory/code/design evidence, anti-generic report, direction diversity evidence, viewport policy, component-state matrix, section approval proof, and handoff blockers. Reject a default hero/card shell, same-shell-new-paint, style-only direction, bare pick-one answer, premium/generic recommendation, reference clone, invented credibility, and unsourced market claim before writing durable design-system files. Alternatives with tradeoffs and named non-goals are required even when deadline pressure asks for "just pick something safe." The proof plan must be visible before brandbook output can unlock prototype or implementation work. ## Design readiness contract - Visual approval is section-scoped: each candidate section must be shown before it can count as approved. - `approved_sections` is the machine-readable unlock list for prototypes; prose approval is not enough. - `feedback_hash` records the visible review packet that produced approval and prevents stale candidate reuse. - Master token/component state and page override state are separate approval records. Page overrides have lower precedence than the global master only until an explicit page-scoped override record links to the master id, records checksum/drift evidence, and carries approved linkage. - Candidate markers are not user approval; only explicit section approval plus flow-state metadata can unlock prototype work. ## Reference Quality Gate Use a candidate sandbox for new direction work: write exploratory systems under `.candidates/run-id`, mark exactly one active candidate, and archive rejected candidate folders with rejection rationale. Do not let candidate tokens unlock implementation or approval. Every reference packet must include reference role, quality tier, borrow, avoid, captured date when relevant, and fit rationale. The packet also records reference quality evidence, because platform standards are not creative benchmarks and cannot authorize a visual direction by themselves. Use `/docs/references/creative-reference-taxonomy.md` for creative pack selection, and use `/scripts/design-system-candidate-manager.mjs` or the owning workflow producer when candidate state must be durable. Creative pack references must be explicit through `creativePacks.path` or an equivalent Creative pack references list. ## Capability And Library Bridge QA Every approved design system must be ready for a Prototype Capability Plan. Reject a library default theme is not a design system failure before prototype unlock. Capability review covers native-static, enhanced-native, bundled-dependency, framework-sandbox, remote-sandbox, and handoff-only modes. Remote-sandbox evidence is draft-only until a local bundle or handoff owner records license, security, fallback, and proof status. ## Continuation Contract Full-pass mode can draft all required sections before the review packet, but approval still happens through the visible review packet and styleboard. reuse/extension mode must not force a full design-system restart when an approved system only needs a narrow extension. Candidate markers are not user approval. This gate cannot be satisfied by delegated approval markers. Only the visual approval/finalize step is a chat-level gate. ## Feedback prompt After presenting candidate design-system sections or a styleboard, show exactly one lifecycle prompt and wait: - ✅ Approve - mark the reviewed section approved with signer and timestamp. - ✎ Revise - collect one focused change request for the current section. - 🔀 Alternative - create a meaningfully different direction with named tradeoffs. - 📊 Run reviews - dispatch accessibility, polish, and design-system checks. - 🛑 Stop - archive the candidate without unlocking prototype work. ## Design Diversity Benchmark Before approving alternatives, require a Design Diversity Benchmark note with palette, type, rationale, motion, imagery, hierarchy, density, composition, and interaction tradeoffs. Reject same shell, new paint candidates even when colors or type tokens changed; a brandbook alternative must explain why the system would create a different first-screen experience. Run creative-diversity QA and record token diversity across palette, type, spacing density, radius/elevation, motion, and component expression. Creative QA records distinctiveness, emotional fit, user empathy, category fit, trend awareness, and future-proof constraints before a direction can be called ready. ## Design System QA Lanes Component coverage must include at least one dense state family such as data table, command palette, chart shell, skeleton, pagination, or settings shell when the product category needs it. Token leakage checks reject raw hex, magic px, library default styling, off-token values, and inline cubic-beziers in durable artifacts. Visual gates cover styleboard quality, contrast, overflow, focus-visible, text overlap, and reduced motion before prototype unlock. ## Memory And Effectiveness Design memory writeback uses `design-memory-writer` to store accepted and rejected decisions, rejected alternatives, and rationale. Effectiveness tracking records first-pass acceptance, revision rounds, token drift, prototype-to-production drift, and design effectiveness signals so future design work learns from real outcomes instead of repeating generic patterns. ## Preference Coverage Matrix Gate Before durable brandbook writes, complete the Preference Coverage Matrix Gate for visual direction and tone, audience/trust posture, information density, typography personality, palette mood, motion intensity, component feel, and reference borrow/avoid. Persist the matrix at `.supervibe/artifacts/brandbook/preferences.json`. Record `first_user_design_gate_ack=true`; source=`inferred` is forbidden for required preferences, while explicit defaults must be marked separately. Use `.scratch/` for diagnostic scratch decisions. Reference source scope must separate project memory, code/design-intelligence evidence, local references, and external references. `.supervibe/artifacts/brandbook/direction.md` must exist before prototypes unlock, and new visual direction work must compare 3 candidate directions. Do not accept blanket approval for all sections before the review packet/styleboard evidence is available. ## Guided Defaults Checklist For design-system wizard flows, maintain the guided defaults checklist before durable writes. Each axis must offer exactly these user-facing actions: Accept default / Compare alternatives / Customize. Keep the active `questionQueue` synchronized with runtime state, and do not promote design-system files when `writeGate.durableWritesAllowed` is false. Use `styleboard.html` only after wizard state and diagnostic scratch evidence agree on target, viewport, reference scope, and visual direction. ## Anti-patterns - `asking-multiple-questions-at-once` - bundling palette, type, motion, components, and approval into one prompt. - `advancing-without-feedback-prompt` - promoting a design-system section or unlocking prototypes without the explicit lifecycle choice above. - `random-regen-instead-of-tradeoff-alternatives` - creating another direction without named axis changes, tradeoffs, and reuse implications. ## Examples - New SaaS dashboard: run full pass, record guided defaults or user preferences, select a creative direction, produce candidate tokens/components, show the styleboard, then collect section approvals before prototype unlock. - Approved system, new settings page: read current components, identify the missing settings-shell or form-row variant, ask one extension question, and update only that extension after approval. - Candidate system with missing typography approval: resume review for that section; do not proceed to prototype until required approvals and `design-flow-state.json` agree. - Good example: a brandbook run loads `references/practice-pack.md`, applies the token and component approval cycle, runs `scripts/self-check.mjs --check`, and records palette, typography, component evidence, blockers, confidence, and nextAction before prototype unlock. - Bad example: a brandbook run chooses attractive colors from taste, skips the practice pack and self-check, ignores approval state, and presents tokens as ready without evidence or rollback notes. See `/skills/brandbook/references/brandbook-examples.md` for concrete file layouts, candidate JSON, approval markers, producer command shapes, section templates, and component catalog prompts. ## When not to use - Do not use this skill to bypass `/supervibe-design` or its durable write gates. - Do not promote scratch or candidate material before preference coverage, selected direction, and write gates allow it. - Do not treat broad user approval as section approval unless the full review packet/styleboard was visible in the current run. - Do not replace required producer, worker, reviewer, validator, or receipt paths with controller-authored inline outputs. ## Common rationalizations - "The user said use defaults." Reject silent defaults; show the guided defaults checklist so each axis can be accepted, compared, or customized. - "The design looks good enough." Reject without section approvals, styleboard evidence, and machine-readable tokens. - "The prototype can define the missing color." Reject; design-system extension comes before prototype styling. - "Candidate markers prove approval." Reject; candidates are progress evidence, not user approval. ## Red flags - `design_system.status = approved` appears without manifest, flow state, per-section approvals, `approved_by`, `approved_at`, approved sections, feedback evidence, master token checksum/drift proof, and page override approval linkage. - Root `_design-system/` contains multiple current token sets or rejected alternatives. - Page override paths point at project-root Supervibe source folders such as `/skills/` or `/scripts/` instead of approved `_design-system/` artifacts. - Raw hex, magic spacing, ad-hoc radius, or local keyframes appear in prototype files because the design system was incomplete. - A styleboard exists before target, viewport policy, reference scope, direction, density, palette, typography, component feel, and motion axes are recorded. - A candidate or needs-revision system is used to unlock prototype work. ## Checklist - Target baseline resolved before durable design artifacts. - Prior memory, local references, CodeGraph, and CodeGraph/design evidence checked or caveated. - Preference Coverage Matrix complete for new/rebrand work. - Creative direction selected before candidate tokens. - Candidate sandbox isolated; stale candidates inspected. - Styleboard evidence shown before approval. - Producer promotion and workflow receipt path used where required. - Required sections explicitly approved before prototype unlock. - Final handoff metadata deferred until an approved prototype exists. ## Failure modes - The skill becomes a long brand tutorial and hides required gates. - Defaults become hidden agent assumptions instead of user-editable decisions. - Candidate files leak into root source-of-truth paths. - A one-off prototype style bypasses tokens and creates drift. - Review status, wizard state, and runtime status disagree on the next action. ## Output contract Return these fields: - `location`: `.supervibe/artifacts/prototypes/_design-system/`. - `mode`: full pass, review/resume, reuse, or extension. - `target`: target baseline and viewport policy. - `sections`: palette, typography, spacing-density, radius-elevation, motion, component-set, copy-language, accessibility-platform. - `artifacts`: manifest, design-flow-state, tokens, motion, voice, accessibility, components, styleboard, approvals, and extensions. - `approval`: candidate, needs_revision, approved design system, or final handoff metadata after prototype approval. - `verification`: commands run, producer receipt status, and blockers. - `antiSlopReport`: produced report or required upstream report path following `antiSlopReport.schema`, with `gateTaxonomy` failed ids visible. - `antiSlopStamp`: compact `Anti-AI-Slop:` stamp for review or handoff output. - `confidence`: numeric score, override flag, and `brandbook` rubric. ## Guard rails - Ask one user-facing question at a time. - Do not write candidate tokens for new/rebrand work before selected creative direction exists. - Do not create durable full styleboards before required axes are recorded. - Do not unlock prototype work from candidate or needs-revision status. - Do not inline raw design values in downstream prototypes. - Do not delete rejected alternatives; archive them with rationale. - Do not claim final handoff until an approved prototype exists. - Do not approve sections, unlock prototypes, or claim handoff readiness when Anti-AI-Slop evidence is missing, a gate id is unknown, a critical gate fails, or a major gate remains unresolved without an evidence-backed waiver. ## Verification - `_design-system/manifest.json` and `design-flow-state.json` parse as JSON and block prototypes until required sections are approved. - `tokens.css` and `motion.css` parse and contain no unresolved placeholders. - Every component spec has anatomy, states, variants, tokens, and accessibility. - Contrast pairs satisfy the project WCAG target. - Reduced-motion strategy is documented. - `node /scripts/design-system-candidate-manager.mjs --archive-stale` reports the candidate/archive plan without moving active work unless `--apply` is intended. - `npm run validate:design-diversity-benchmark` passes when alternatives are produced. - Producer or workflow receipt evidence is present when durable design-system outputs are claimed. ## Supporting references - `/skills/brandbook/references/brandbook-examples.md` - `/docs/references/accessibility-reference-pack.md` - `/skills/effect-performance-budget/references/performance-reference-pack.md` - `/skills/using-supervibe-skills/references/skill-anatomy-baseline.md` ## Related - `legacy-role:_design/creative-director` produces selected creative direction before full design-system materialization. - `legacy-role:_design/design-system-architect` reviews token/component/styleboard coverage before prototype unlock. - `supervibe:interaction-design-patterns` supplies motion recipes; brandbook declares which ones are approved vocabulary. - `supervibe:prototype` consumes the approved design system. - `supervibe:tokens-export` exports approved tokens to implementation stacks. - `/commands/supervibe-design.md` orchestrates brand, prototype, review, and handoff lifecycle. ## Supporting references ### Resource tree hardening - `references/practice-pack.md` - Read when brandbook needs deeper load rules, local evidence anchors, gotchas, or a final checklist. - `scripts/self-check.mjs` - Run with `--check` before claiming the brandbook resource tree is complete; add `--json` when machine-readable evidence is needed. - `evals/regression.json` - Use when tuning brandbook trigger boundaries or checking should-trigger and should-not-trigger prompts. - `examples/workflow.md` - Load when a concrete brandbook workflow example or anti-example would clarify the next action. - `templates/output-contract.md` - Use when emitting agent-output so status, evidence, blockers, confidence, and nextAction stay consistent. - `/skills/brandbook/schemas/design-brand-asset-audit.schema.json` - Use for owner-local brand asset audit packets emitted by brandbook and design-system evidence.