Feature Presentation

[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set in_progress when step starts, set completed when step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.

Quick Summary

Goal: Synthesize every session-generated idea, Feature Spec, PBI, user story, design-spec, and mockup into ONE standalone HTML slide deck for PO/BA/Dev/QC — project-faithful styling, an interactive MVP demo of every main user journey, vanilla-JS slide engine — so the whole team reviews the feature from a single offline file before build.

Summary:

• Purpose / altitude: a SYNTHESIS deck at a higher altitude than pbi-mockup — accumulates many artifacts (ideas + specs + PBIs + stories + design-specs + mockups) into ONE stakeholder presentation, not one PBI's UI preview.
• Main steps (read-this-if-nothing-else): (1) resolve scope on activePlan created→now range → (2) gap-fill missing PBIs/mockups via SUB-AGENT → (3) load project design context → (4) [BLOCKING] inventory existing UI + map flows → (5) accumulate + extract main-story journeys (one todo each) → (6) assemble ONE standalone HTML deck → (7) save → (8) [BLOCKING] fidelity gate (incl. demo integrity) + (8b) Demo-Quality review → (9) report.
• Output: exactly ONE self-contained HTML file at team-artifacts/presentations/{YYMMDD}-presentation-{slug}.html — inline CSS/JS, Google Fonts only, NO CDN (no reveal.js); a ~60-line vanilla-JS slide engine (keyboard ←/→/Home/End, nav dots, counter, light/dark toggle).
• Interactive demo + mockup reuse: every in-scope main user story is an interactive MVP demo slide ("click X → see Y → move to Z") with a plain-language narration strip + a "How to drive this demo" guide slide near the top; existing team-artifacts/pbis/*-mockup.html are REUSED (never regenerated), embedded via <iframe srcdoc="…entity-escaped…"> (escaping rule in references/deck-template.md) — the mock-up is self-driving, the deck adds only narration; journeys are planned as an ordered list (Step 5, one todo each) and signed off by the final Demo-Quality review (Step 8b).
• Full-flow mock-app requirement: every reused or gap-filled PBI mockup MUST already demonstrate the PBI's releasable outcome through all required pages/views, navigation, common/domain/page components, applicable states, and the visible/persisted result. A one-screen or disconnected mockup is not accepted as a complete demo; delegate back to pbi-mockup for correction.
• Large-idea synthesis requirement: evaluate the shared isLargeIdea rule from the owning idea/spec/PBI. When any signal is true, ingest the complete large_idea_decomposition block, retain stable slice IDs, and add a Decomposition & boundaries section alongside the all-PBI backlog and all-PBI presentation showing slices, dependency order, non-goals, risks/evidence owners, and deferred-work owners. Missing or conflicting fields are a blocking deck-quality finding; the presentation never creates docs/product-roadmap.md.
• Spec-only branch: idea-to-spec degrades to design-spec visuals (ASCII wireframes + inventory/states/tokens tables) + a narrated step-through of ASCII frames — NO HTML mockups, NO pbi-mockup invocation — preserving the spec-only contract; full HTML mockups appear only in idea-to-pbi.

Workflow:

1. Resolve scope — anchor on activePlan, accumulate its full artifact set across the plan's created→now date range (every {YYMMDD} in range, NOT just today); custom prompt widens; standalone + no prompt → AskUserQuestion.
2. Gap-fill (smart routing — sub-agent) — spec lacks PBIs → workflow-spec-to-pbi AS A SUB-AGENT; PBIs lack mockups (mockup-bearing workflow) → pbi-mockup. Spec-only idea-to-spec → SKIP mockup generation.
3. Load project design context — baseline + matched per-app design-system docs via project-config.json.
4. [BLOCKING] Inventory existing UI + map connected flows — SYNC:existing-ui-research.
5. Accumulate + structure content (incl. journey extraction) — parse each artifact into stakeholder sections; extract the main-story flows into an ordered journey list + TaskCreate one todo per journey; REAL domain data, never Lorem (references/artifact-accumulation.md).
6. Assemble ONE standalone HTML deck — inline CSS (design tokens, BEM) + vanilla-JS engine + a "How to drive this demo" guide slide + one interactive demo-flow slide per journey (embedded mockup + narration strip) + <iframe srcdoc> mockup embeds; spec-only path renders ASCII/tables + narrated ASCII frames; empty-state slide when no visual exists (references/deck-template.md).
7. Save → team-artifacts/presentations/{YYMMDD}-presentation-{slug}.html.
8. [BLOCKING] Fidelity gate (incl. demo integrity) — validate deck visuals + every journey clicks through vs Step 4 inventory; record Fidelity vs existing UI: PASS|FAIL (references/deck-template.md). 8b. [BLOCKING] Demo-Quality review — final stakeholder-comprehension pass; record Demo quality: PASS|FAIL.
9. Report — path, artifact count synthesized, demo journeys, stakeholder sections, fidelity + demo-quality verdicts.

Key Rules:

• Emit exactly ONE self-contained HTML file; inline CSS/JS; no external <script src> / <link rel=stylesheet> except Google Fonts; no CDN reveal.js — vanilla-JS engine only.
• Present every in-scope main user story as an interactive MVP demo slide (embedded interactive mockup + narration strip); plan journeys first (Step 5, one todo each), sign off with the Demo-Quality review (Step 8b).
• Embed existing -mockup.html via <iframe srcdoc> — never regenerate a mockup that already exists; the mock-up is self-driving, the deck adds only narration.
• Spec-only idea-to-spec → design-spec ASCII wireframes + inventory/states/tokens tables + narrated ASCII-frame step-through ONLY; never generate HTML mockups, never invoke pbi-mockup.
• Use REAL domain entity field names + realistic sample data — never Lorem ipsum or "Item 1, Item 2".
• Empty-state slide when an in-scope feature has no mockup AND no design-spec — never a broken/blank iframe.
• Run gap-fill multi-step workflows as SUB-AGENTS (summary returned + findings written to plans/reports/) per CLAUDE.md "Workflow Step Advancement §3".
• Keep accompanying prose/captions tech-agnostic (business/observable terms, not framework/CSS class names); the rendered HTML may use real class names internally.

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

Feature Presentation — Stakeholder HTML Slide Deck

Synthesize all session-generated specs, PBIs, ideas, and mockups into one standalone HTML slide presentation for PO/BA/Dev/QC.

When to Use

• Near the end of workflow-idea-to-pbi and workflow-idea-to-spec, to present the whole feature set to stakeholders.
• Standalone, when a PO/BA/Dev/QC needs one offline deck synthesizing a feature's ideas, specs, PBIs, stories, and mockups.

NOT for: Generating a single PBI's UI preview (use /pbi-mockup), authoring a Feature Spec (use /spec), or producing a design spec (use /design-spec).

Quick Reference

Input

Output

Related

• Input from: /spec, /refine, /story, /pbi-mockup, /design-spec
• Command: /feature-presentation
• Detail: references/deck-template.md (HTML scaffold + slide engine + iframe-srcdoc escaping + fidelity gate); references/artifact-accumulation.md (scope resolution + per-type parse map + gap-fill + branches)

Detailed Workflow

Step 1: Resolve Scope

Determine which artifacts the deck synthesizes. See references/artifact-accumulation.md → "Scope Resolution" for the full algorithm.

1. Default (active-plan anchor): Read activePlan from /tmp/ck-session-{id}.json (set by .claude/scripts/set-active-plan.cjs). Accumulate the plan's FULL artifact set across the plan's created→now date range — glob team-artifacts/{ideas,pbis,pbis/stories,design-specs} and *-mockup.html for EVERY {YYMMDD} in that range, plus the plan's docs/specs outputs.
   • Multi-day rule: a workflow that spans midnight authors specs on day 1 and PBIs on day 2 — a single-day {YYMMDD} glob silently drops day-1 artifacts. Glob over the whole created→now range, never just today.
2. Custom prompt: If the user names specs/features, widen scope to those named artifacts (plus their dependents).
3. Standalone + no prompt: Use AskUserQuestion to ask which specs/ideas to present — never silently guess scope.

Step 2: Gap-Fill (Smart Routing — Sub-Agent)

Fill missing downstream artifacts so the deck is complete. See references/artifact-accumulation.md → "Gap-Fill Routing".

1. Spec lacks PBIs: Invoke workflow-spec-to-pbi AS A SUB-AGENT (Agent tool) — per CLAUDE.md "Workflow Step Advancement §3", a step that activates a multi-step workflow MUST run as a sub-agent: it returns only a summary and writes full findings to plans/reports/. This keeps the deck-build context bounded.
2. PBIs lack -mockup.html AND the workflow is mockup-bearing (idea-to-pbi): Invoke pbi-mockup per PBI to generate the missing mockup. Require its Releasable Full-Flow gate to PASS before embedding.
3. Spec-only idea-to-spec context: SKIP all mockup generation — never invoke pbi-mockup. The deck will use design-spec visuals only (Step 6 spec-only path). This preserves the idea-to-spec no-mockup contract.

Step 3: Load Project Design Context

The deck CSS must use the project's design tokens (same discovery as pbi-mockup):

1. Mandatory baseline: Read docs/project-reference/design-system/README.md and docs/project-reference/design-system/design-system-canonical.md.
2. Primary: Read top-level designSystem in docs/project-config.json — use designSystem.docsPath + designSystem.canonicalDoc, then match the presented feature/app context against designSystem.appMappings[] to select the per-app doc.
3. Fallback: Glob("docs/project-reference/design-system/*.md") → case-insensitive substring match on app/feature name. Default: README.md.
4. Extract colors, typography, spacing, border-radius, shadows → these become the deck's CSS variables.

Step 4: [BLOCKING] Inventory Existing UI + Map Connected Flows

[BLOCKING] Do NOT assemble the deck until this inventory + connected-flow map is done (canonical: SYNC:existing-ui-research). The deck must faithfully match the current UI system, not generic HTML.

1. Read docs/project-reference/frontend-patterns-reference.md (first 200 lines) — base component classes, form/table/dialog patterns.
2. Sample 2-3 real shared/module components for layout patterns and CSS class naming.
3. Map the connected feature flows the presented features link to/from, so the deck's embedded visuals fit the surrounding navigation.

Step 5: Accumulate + Structure Content (incl. journey extraction — think → plan → many todos)

Parse each in-scope artifact into stakeholder-oriented slide sections (see Slide Taxonomy). See references/artifact-accumulation.md → "Per-Artifact-Type Parse Map" for which artifact maps to which section.

• Use REAL domain entity field names + realistic sample data from docs/project-reference/domain-entities-reference.md — never Lorem ipsum or "Item 1, Item 2".
• Keep accompanying prose/captions tech-agnostic (business/observable terms, not framework/CSS class names).
• Extract each PBI's priority/rank — read the priority label + numeric rank from each PBI's frontmatter (and the ranked-order backlog artifact team-artifacts/backlog/*-backlog.md when present). The Scope & backlog slide MUST display PBIs in ranked order with a priority label per PBI card — the deck carries the same priority info the backlog and mockups do. If PBIs lack priority, note it explicitly rather than dropping the field.
• Extract the decomposition context — locate the owning idea/spec/PBI block, validate all five fields (outcome_slices, dependencies_order, non_goals, risks_evidence, deferred_work_owner) when any large-idea signal is true, and preserve each slice ID through every PBI/story/mockup. Add a Decomposition & boundaries slide (or an equivalent section in Scope & backlog) with dependency order, non-goals, evidence owners, and deferred-work ownership. If all signals are false, record Decomposition: N/A — ordinary isolated scope and do not invent a roadmap section.
• Extract the main-story / MVP flows into an ordered journey list — from PBI ## Acceptance Criteria GIVEN/WHEN/THEN + story "As a / I want / So that" + each mock-up's flow-specs (references/artifact-accumulation.md §6 Journey-Extraction Map). One journey per main user story (MVP happy path), each an ordered sequence: entry → click steps ("click X → see Y → move to Z") → end state + one plain-language explanation per step. When a -mockup.html exists, reuse its flow-specs verbatim so the deck demo == the per-PBI prototype.
• TaskCreate one todo per journey slide — so each journey is assembled (Step 6) and later verified (Step 8 demo integrity / final demo-quality review) individually. (The "think → plan → many todos before do".)

Step 6: Assemble ONE Standalone HTML Deck

Build the single self-contained HTML file from the scaffold in references/deck-template.md:

• Inline <style> — design tokens as CSS variables, BEM class names, light/dark themes.
• Vanilla-JS slide engine — keyboard ←/→/Home/End, nav dots, slide counter, theme toggle (no CDN reveal.js). Don't hijack arrow keys while a demo iframe is focused; OPTIONAL postMessage('play') to auto-start a journey degrades gracefully (references/deck-template.md §3b engine-coexistence note).
• "How to drive this demo" guide slide near the top — teach the viewer how to click hotspots and use each demo's own ▶ Play / ⏮ ⏭ / ↺ Reset controls (inside the mock-up) to walk a journey, and ←/→ to change slides, so a non-technical stakeholder is never lost (references/deck-template.md §3b).
• Demo-flow slides (one per journey from Step 5): each embeds the interactive pbi-mockup HTML scoped to that flow via <iframe srcdoc="…escaped…"> and overlays a deck-level narration/explanation strip (current step + plain-language explanation, text only + "⚠ Simulated" note). The journey's ▶/⏮/⏭/↺ controls live INSIDE the embedded mock-up — it is self-driving; the deck adds only narration and does NOT re-implement or duplicate those controls (references/deck-template.md §3b).
• Mockup-bearing path (idea-to-pbi): embed each existing -mockup.html via <iframe srcdoc="…escaped…"> — the entity-escaping rule (&-first, escape-once-unconditionally) is in references/deck-template.md. Never regenerate a mockup that already exists.
• Decomposition integrity: the deck is an aggregation surface, not a new product-scope decision maker. It must not split, merge, rename, or reinterpret slice IDs; flag conflicts back to the owning PBI/spec/refine step and stop the fidelity gate until resolved.
• Spec-only path (idea-to-spec): render the design-spec ASCII wireframes + Component Inventory / States / Design-Tokens tables instead of HTML mockups; the journey demo is a narrated step-through of design-spec ASCII frames advanced by Next, each with its step explanation. NO <iframe srcdoc> mockup embed, NEVER invoke pbi-mockup.
• Empty-state (F3): when an in-scope feature has NO -mockup.html AND NO design-spec, render an explicit empty-state slide ("No mockup/design-spec available for {feature}") — never a broken/blank iframe.

Step 7: Save

• Path: team-artifacts/presentations/{YYMMDD}-presentation-{slug}.html (create the presentations/ dir if absent).
• {slug} = the presented feature(s) or plan slug.

Step 8: [BLOCKING] Fidelity Validation — Deck Matches Existing UI

[BLOCKING] After the deck is assembled, validate its visuals faithfully match the existing UI inventoried in Step 4 before handoff. Do NOT report the deck as done until this validation records a result. Full procedure: references/deck-template.md → "[BLOCKING] Fidelity Gate".

The fidelity gate also covers demo integrity — every journey/demo slide clicks through end-to-end inside its iframe (each step reaches its end state via real hotspots); no dead controls; the narration strip names the current step + explanation and stays tech-agnostic (M1/M2); the "⚠ Simulated" note is visible; spec-only journeys advance their narrated ASCII frames.

Record the outcome in the Step 9 report:

Fidelity vs existing UI: PASS | FAIL — tokens / components / layout / flows / embeds / demos matched? If FAIL: what diverged + the fix.

If FAIL, revise the deck to match the existing UI and re-validate before handoff.

Step 8b: [BLOCKING] Demo-Quality Review (final review todo)

[BLOCKING] Final review before the report (the per-journey todos and this gate were created in Step 5). First confirm the deck SATISFIES the intent: every in-scope main user story is presented as a journey (coverage — no main story missing) AND each journey faithfully conveys that story's intended behavior, not merely that slides render. Then run a stakeholder-comprehension pass: could a PO with no prior context follow each journey end-to-end? Confirm every demo-flow slide clicks through, narration explains each step in plain language, the "⚠ Simulated" note is present, and the spec-only path degrades to narrated ASCII frames (never an HTML mockup). Record Demo quality: PASS | FAIL — FAIL if any main story is unrepresented or misrepresented, regardless of polish.

If FAIL, fix the journey slides (re-extract from the §6 journey map / re-embed the flow-scoped mockup) and re-review before handoff.

Step 9: Report to User

After assembly, output:

Deck generated: team-artifacts/presentations/{YYMMDD}-presentation-{slug}.html
- Artifacts synthesized: {count} ({ideas}/{specs}/{pbis}/{stories}/{mockups}/{design-specs})
- Backlog priority: {ranked | not prioritized} — Scope & backlog slide shows {N} PBIs in ranked order with priority labels
- Demo journeys: {count} ({journey titles})
- Stakeholder sections: {title, how-to-demo, business-context, scope-backlog, behavior-rules, demo-flows, ui-mockups, qc-view, summary}
- Fidelity vs existing UI: PASS | FAIL
- Demo quality: PASS | FAIL

Open in browser to preview. Click highlighted hotspots or press ▶ Play to walk a journey; use ←/→ or nav dots to move between slides; theme toggle for light/dark.

Slide Taxonomy (stakeholder-oriented)

Every slide section must serve the four stakeholder audiences (PO/BA/Dev/QC):

UI Layout

The deck is itself a UI artifact. ASCII of a slide frame:

┌────────────────────────────────────────────────┐
│ ◀  Feature Presentation — {Feature}     3 / 12  │  ← top bar: title + counter
├────────────────────────────────────────────────┤
│  ## Business Context                            │
│  • Problem  • Value  • Epics                     │  ← slide body (design-system tokens)
│  ┌──────────────────────────────────────────┐   │
│  │  <iframe srcdoc> embedded mockup / wire   │   │  ← embedded visual (or empty-state)
│  └──────────────────────────────────────────┘   │
├────────────────────────────────────────────────┤
│  ● ● ● ○ ○ ○ ○ ○ ○ ○ ○ ○        ◀ Prev  Next ▶  │  ← nav dots + buttons (vanilla JS)
└────────────────────────────────────────────────┘

Component tiers: common (slide shell, nav) — domain-shared (mockup/wireframe embed block) — page-app (per-artifact content slides). Keyboard ←/→, Home/End; theme toggle (light/dark) reusing design-system tokens.

Edge Cases

Anti-Patterns

Alternatives Considered

1. Extend pbi-mockup with a --deck mode (rejected) — pbi-mockup is per-PBI and mockup-scoped; a multi-artifact synthesis deck has a different input set and audience. Overloading one skill raises change cost and blurs the spec-only contract. Separate skill keeps each single-responsibility.
2. CDN reveal.js / impress.js slide framework (rejected) — violates the self-contained/no-external-deps contract (offline-break, supply-chain surface, new dependency). Vanilla-JS engine is ~60 lines, matches pbi-mockup's zero-dep posture.
3. Link to mockup files instead of inlining (rejected) — breaks the "ONE standalone html file" mandate; a moved/un-co-located deck renders broken. <iframe srcdoc> keeps everything in one file.
4. Chosen: standalone skill + inline single-file deck + iframe-srcdoc mockup embed. Con: deck file size grows with embedded mockups — acceptable (HTML is text, gzips well; offline portability outweighs size).

Design Rationale

A synthesis deck is a different artifact at a different altitude than a per-PBI mockup, so it earns its own skill — but it must NOT duplicate the mockup engine (reuse/embed). <iframe srcdoc> is the one mechanism satisfying BOTH "single standalone file" AND "reuse existing mockups" without re-rendering. Carrying SYNC:existing-ui-research + the fidelity gate is what makes the deck project-faithful rather than generic. The spec-only branch + empty-state slide preserve the idea-to-spec no-mockup contract while still giving stakeholders a visual. Running gap-fill sub-workflows as sub-agents keeps the deck-build context bounded — the deck skill consumes a summary, not the full workflow transcript.

Security Considerations

<iframe srcdoc> embeds first-party generated mockup HTML only — no remote content, no user-supplied script. Entity-escaping the embedded mockup into srcdoc is also a safety boundary: it prevents an unescaped </iframe>/<script> in a mockup from breaking out of the embed. The deck opens offline (no network except the Google Fonts CSS). No secrets in artifacts.

Workflow Recommendation

MANDATORY IMPORTANT MUST ATTENTION — NO EXCEPTIONS: If you are NOT already in a workflow, you MUST ATTENTION use AskUserQuestion to ask the user. Do NOT judge task complexity or decide this is "simple enough to skip" — the user decides whether to use a workflow, not you:

1. Activate workflow-idea-to-pbi workflow (Recommended) — includes the presentation deck as a late step.
2. Activate workflow-idea-to-spec workflow — spec-only path; deck degrades to design-spec visuals.
3. Execute /feature-presentation directly — run this skill standalone on existing artifacts.

Next Steps

MANDATORY IMPORTANT MUST ATTENTION — NO EXCEPTIONS after completing this skill, you MUST ATTENTION use AskUserQuestion to present these options. Do NOT skip because the task seems "simple" or "obvious" — the user decides:

• "Open the deck" — open the standalone HTML in a browser to review with stakeholders
• "/prioritize" — prioritize the synthesized PBIs in the backlog
• "/plan" — start implementation planning
• "Skip, continue manually" — user decides

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting.

Evidence Gate: MANDATORY IMPORTANT MUST ATTENTION — every claim, finding, and recommendation requires file:line proof or traced evidence with confidence percentage (>80% to act, <80% must verify first).

[BLOCKING] Understand the existing UI before you design or spec a new/updated screen. Before producing any wireframe, mockup, screen design, or UI spec:

1. Inventory existing related UI — search the project for screens, pages, and components already serving this feature or its domain (consult design-system docs + the real component inventory).
2. Map connected flows — identify every feature that links to, embeds, includes, or navigates to/from the new screen; trace its entry and exit flows so the new screen fits them.
3. Reuse before invent — prefer existing components, patterns, and layout conventions; justify any new component against what already exists.
4. Record findings — note the matched existing screens/components + connected flows in the artifact so downstream design faithfully matches the current UI system.

Skip ONLY when the feature is backend-only (no UI) — state that explicitly.

AI Mistake Prevention — Failure modes to avoid on every task:

Re-read files after context changes. Context compaction, resume, or long-running work can make memory stale; verify current files before acting. Verify generated content against source evidence. AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing. Check downstream references before deleting or renaming. Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first. Trace the full impact chain after edits. Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done. Verify ALL affected outputs, not just the first. One green check is not all green checks; validate every output surface the change can affect. Assume existing values are intentional — ask WHY before changing OR flagging one as a defect. Before changing or reporting a constant, limit, flag, cutoff, wording, or pattern, read nearby context and history, the CALLER's ordering, and 2+ sibling call sites of the same convention. A doc stating WHAT without WHY is missing rationale, not proof of a missing guard. Surface ambiguity before acting — don't pick silently. Multiple valid interpretations require an explicit question or stated assumption with risk. Assert the outcome your system owns, not the intermediate state your infrastructure owns. When verifying async work, assert the final business state — never the delivery/retry bookkeeping held in shared infrastructure that any co-running process can write. Such a check passes when run alone and flakes the moment anything else shares that infrastructure. Keep shared guidance role-relevant. Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols.

Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

[BLOCKING] Design distinctiveness gate (DD-1–DD-8) — binds on ANY task that designs, plans, mocks up, implements, or reviews a user-facing visual surface. Deep catalog: .claude/docs/design-knowledge.md. Cite findings as DD-<clause> + file:line.

Precedence (resolve in this order, never silently): the brief's own stated visual direction WINS outright — including when it asks for one of the DD-4 tells. Then the project's design-system / SCSS / frontend-pattern docs and accepted ADRs — a house style IS an intentional identity, and re-deciding it per feature is the incoherence this gate prevents. Then these clauses. A genuine conflict is SURFACED to the user with both sides, NEVER resolved silently.

Relationship to UI-1.1–UI-9.4: a different question, no overlap — the 40 clauses ask "is this usable, accessible, consistent?" (a measurable floor); this gate asks "is this THIS product's interface, or the one any generator would emit for any brief?". A surface can pass all 40 clauses and still be a template. BOTH bind; where they touch (type scale, colour, motion timing) the clause sets the floor and this gate picks the value.

• DD-1 Ground it in the subject matter. Before designing, name the concrete subject, the audience, and the design's primary job — and CONFIRM with the user when the brief is silent. Distinctive choices come FROM the subject's industry, materials and vernacular; they are never taste applied on top. Test: if the palette, type and layout would fit a different product unchanged, there is no identity yet.
• DD-2 Every choice carries a WHY. "It's common", "it's clean", "users expect it" are not reasons. A decision with no articulable reason is a default that arrived unnoticed. Defaults hide in what feels like infrastructure — typography, navigation, data display, and TOKEN NAMES. Token-name test: someone reading only your CSS variables should be able to guess what product this is (--ink/--parchment evoke a world; --gray-700/--surface-2 evoke a template).
• DD-3 Two passes, and the review pass is mandatory. (1a) Write a compact design plan — Colour (4–6 named hex values) · Type (families + roles + scale) · Layout (one-sentence prose + ASCII wireframes to compare alternatives, including alignment: left/centre/justified) · Principles (what makes THIS page unique). (1b) BLOCKING generic test — before any code: work through a similar prompt and see whether you arrive somewhere similar; any part that reads like the generic default for any comparable page rather than a choice for THIS brief gets REVISED, and you state what you changed and why. Then (2a) build the REVISED plan, (2b) critique. — why: writing a plan and going straight to code reproduces the default, because the plan came from the same patterns the code will.
• DD-4 Audit every FREE axis against the generated-design tell catalog ([model-knowledge], calibration not prohibition — each trait is legitimate for SOME brief): T1 cream #F4F1EA + high-contrast serif + terracotta near #D97757 (Anthropic's own interaction accent — on a user's brief it reads specifically as a tell) · T2 near-black + one acid-green/vermilion accent · T3 broadsheet hairline-rule pastiche, zero radius, dense columns · T4 the SaaS-card kit: identical rounded cards, ONE radius regardless of hierarchy, the same rgba(0,0,0,.1) shadow under each, gradient washes as decoration · T5 template chrome whatever the subject: tracked-out ALL-CAPS eyebrow above every heading, meta strings joined with middle dots (A · B · C), WORD — fragment labels with a spaced em dash, tinted near-black (#0B0B0B/#111) standing in for black, monospace for small data labels, → appended to link/button text. A match is a HYPOTHESIS about a missed decision, never a defect — promote it only by naming the axis, that the brief left it free, and what the subject suggested instead.
• DD-5 Typography carries the personality. One family, or two CLEARLY distinct ones — you do NOT need separate display and body faces. Choose deliberately, not the default you would reach for on any project. Set a real scale with intentional weights, widths and spacing. When type is a headline it is an ACTIVE part of the design, not a neutral delivery vehicle. Measure under ~80 characters; serifs tolerate slightly longer lines and want slightly more line-height than sans at the same size. Hierarchy needs weight/tracking/opacity, not size alone. Avoid the three commonest tells: accenting a single word in a headline (italic/bold/colour) · ALL CAPS labels · an eyebrow label that names the section the heading already names.
• DD-6 Structure is information, not decoration. Outlines, borders, numbering, eyebrows, dividers and labels must encode something about the content. Before adding numbered markers (01 / 02 / 03), check the content really IS a sequence — a stepped process, timeline or ranking. For every device ask: what does this tell the reader that whitespace would not? Nothing → cut it. Hero: open with the most characteristic thing in the subject's world, in whatever form fits (headline, image, animation, live demo, interactive moment) — big-number-plus-small-label-plus-gradient is the DEFAULT treatment, so use it only when it is genuinely best here. Composition: rhythm over monotone (same card size, same gap, same density everywhere is the sound of no one deciding); proportions must say something you can articulate; one dominant focal point.
• DD-7 Motion sparingly and deliberately. Non-user-triggered motion draws attention ONLY. One orchestrated moment — a single page-load sequence or one reveal — lands better than scattered effects; fade-and-slide-up entrances on each section and hover transitions on every card are the generic default and read as generated. Motion that ANSWERS a person's action (opening, expanding, confirming) is welcome when it shows what changed. Honour prefers-reduced-motion.
• DD-8 Spend boldness once, then remove one accessory. Let ONE element be the memorable thing and keep everything around it quiet and disciplined; cut any decoration that does not serve the brief. Critique the BUILT page, not just the plan — composition, craft (density is a decision, not a constant), content coherence, and CSS honesty (negative margins undoing a parent's padding, calc() values that exist only as workarounds, absolute positioning to escape layout flow are lies; the correct answer is always simpler than the hack). Take screenshots to review where the environment supports it — a picture is worth 1000 tokens. Then ask "if they said this lacks craft, what would they point to?" and fix that. Build the quality floor in silently — responsive, visible keyboard focus, reduced-motion respected, measured contrast, tokens never raw hex or magic numbers — and watch CSS selector specificity, where a type-based selector (.section) and an element-based one (.cta) most often cancel each other's padding/margin.

Memory: vary between briefs — light and dark, families, direction. NEVER converge on the same choice across generations (Space Grotesk, for example). Where the project already has a design system, tokens, or an interface-system.md, ADOPT and record it rather than re-deciding; write back any pattern used 2+ times with measurements worth rememberi

…(truncated)