Refresh the Impeccable product experience

Rework the landing page proof, steering demo, feature grid, slop catalog, detector coverage, theming, Live workflow, and responsive behavior.\n\nAI-assisted implementation by OpenAI Codex.

skill/reference/codex.md

@@ -1,105 +1,38 @@
-# Codex: Visual Direction & Asset Production
+# Codex: Surface Probes & Asset Production
 
-This file is loaded by `{{command_prefix}}impeccable craft` when the harness has native image generation (currently Codex via `image_gen`). Other harnesses skip it. It covers the two craft steps that depend on real image generation: landing the visual direction, and producing the raster assets the implementation will compose.
+Load this from [new-work.md](new-work.md) only when the harness has native image generation and a substantial, high-fidelity surface would benefit from seeing the shortlisted concept before code. PRODUCT.md and DESIGN.md are preconditions. Init has already established the visual world; this file must not reopen it.
 
-Read this *before* generating any images. The order matters, and the per-step user pauses are what keep generated imagery from drifting away from the brief.
+The purpose of a probe is to test composition, narrative, hierarchy, density, focal moment, signature use, and image requirements. It is not a second identity workshop. Keep DESIGN.md's palette, typography direction, material language, component character, imagery stance, and motion grammar fixed.
 
-### Four stop points before code
+## Generate the smallest useful probe set
 
-Steps A through D each end with the user. Do not advance past any of them on your own read of the situation.
+Generate one to three high-fidelity north-star comps using the native image-generation capability. Base them on the real content and the surface concepts already developed with the user.
 
-1. **STOP after Step A questions.** Wait for answers.
-2. **STOP after Step B palette generation.** Wait for "confirm palette."
-3. **STOP after Step C mocks.** Wait for direction approval or delegation.
-4. **Only after Step D approves a direction** do you return to the build (new-work.md's plan, then code).
+- When the user shortlisted multiple concepts, show one clear expression of each.
+- When one concept is already selected, vary only the structural uncertainty that the image can resolve: topology, sequence, density, hierarchy, focal composition, or interaction framing.
+- Show enough beyond the opening moment to prove the concept can govern the whole requested surface.
+- Do not generate a palette artifact, ask new atmosphere questions, introduce a different type voice, or invent a new motif. If the committed world cannot support the concept, return to the concept shortlist rather than changing the world.
 
-Prior shape approval does **not** satisfy any of these. Shape's "confirm or override" advances you into Step A; it is not a substitute for it.
+Treat each comp as a direction test, not a screenshot specification. Core UI text, responsive behavior, accessibility, semantics, and interaction states remain implementation responsibilities.
 
-## Step A: Explore Directions with the User
+## One approval point
 
-Before generating anything, run a brief direction conversation grounded in the shape brief.
+Show the probes together and ask what should carry forward, what feels false to the world, and whether the selected surface concept should be approved, combined, revised, or rejected. Then stop and wait. A structured simulated user counts as attended and receives the same question.
 
-**Step A is required even when shape just produced a confirmed brief.** The shape questions and Step A questions cover different ground: shape pins purpose, content, scope; Step A pins palette, atmosphere, and named visual references for the comps you're about to generate. The only time you can skip Step A is when the user has already answered these exact palette/atmosphere/reference questions in the same session.
+Do not begin code until the user approves a direction or explicitly delegates the choice. If they delegate, choose using the task brief, PRODUCT.md, and DESIGN.md, and state the evidence. Approval refines the task concept; it does not modify DESIGN.md.
 
-Ask **2-3 targeted questions** about visual lane, color strategy, atmosphere, and named anchor references. Don't enumerate generic menus; tie each question to the shape brief's answers. Example shape-grounded questions:
+After approval, summarize the composition and the parts of the comp that must not be literalized. Return to new-work.md and write the direction contract from the approved surface concept before code.
 
-- "Brief says 'specimen-page restraint.' Are we closer to a quiet typographic page or a wider editorial spread with hero imagery?"
-- "Palette strategy from shape was 'Committed.' Which one color carries the surface (a brand-driven pick rather than a default warm-or-cool framing)? (And no, the answer isn't a cream/sand body bg; that's the saturated AI default.)"
+## Inventory implementation fidelity
 
-**STOP and wait for answers.** These pin the palette before any pixel gets generated. Do not proceed to Step B until the user has responded.
+Before building, inventory the approved comp's major visible ingredients and choose an implementation medium for each: semantic HTML/CSS/SVG, existing project asset, generated raster, sourced raster, icon library, canvas/WebGL, or accepted omission.
 
-## Step B: Generate the Brand Palette First
+Pay special attention to the dominant composition, signature use, image-native content, second-fold system, and any interaction the still image only implies. If the concept depends on a photograph, architectural scene, product object, portrait, or other raster-native material, do not silently replace it with generic CSS scenery.
 
-Generate **one** palette artifact before any mocks. This is a small, focused image: typography pairing on the chosen background, primary + accent color swatches, one signature ornament or motif. Single image, single pass.
+Treat the comp as a north star, not something to trace. Do not rasterize core UI text or controls. Do not substitute a different visual driver after approval without asking.
 
-Why palette first: mocks generated against a vague color sense produce noise that drowns out the structural decisions. A confirmed palette is the first concrete contract for everything downstream.
+## Produce only the assets the build needs
 
-Show the palette to the user. Ask one question: "This is the palette I'm locking in for the mocks. Confirm, or call out what to shift?"
+When clean raster ingredients are required and a scoped subagent is available and authorized, use `impeccable_asset_producer`. Give it the approved comp, output paths, required dimensions and formats, transparency needs, crop notes, and what must remain semantic code. Otherwise produce the minimum required assets with the native image-generation capability in the current thread.
 
-**STOP and wait for confirmation.** Do not generate mocks against an unconfirmed palette. "Probably good enough" is the wrong call here; the palette is the contract for everything downstream.
-
-## Step C: Generate 1-3 Visual Mocks Against the Palette
-
-Once the palette is confirmed, generate **1 to 3** high-fidelity north-star comps. Each mock must use the confirmed palette and typography. Mocks differ in *structural* direction (hierarchy, topology, density, composition), not in color or motif.
-
-- Brand work: push visual identity, composition, mood, and signature motifs.
-- Product work: push hierarchy, topology, density, tone, grounded in realistic product structure.
-- Landing pages and long-form brand surfaces: show enough of the second fold to establish the system beyond the hero.
-
-Use the `image_gen` tool directly (or via the imagegen skill when available). Don't ask the user to install anything.
-
-## Step D: Approval Loop
-
-Show the comps. Ask what carries forward. Iterate until **one direction is approved** or the user explicitly delegates.
-
-**STOP and wait for the approval or the delegation.** Do not begin Step E or return to the build until a single direction is named. If the user delegates, pick the strongest direction and explain it from the brief, not personal taste.
-
-Before moving to assets, summarize what to carry into code and what *not* to literalize from the mock. This is the handoff between visual exploration and semantic implementation.
-
-## Step E: Mock Fidelity Inventory
-
-Inventory the approved mock's major visible ingredients. For each, decide implementation: semantic HTML/CSS/SVG, generated raster, sourced raster, icon library, canvas/WebGL, or accepted omission.
-
-Common ingredients to inventory:
-
-- Hero silhouette and dominant composition
-- Signature motifs (planets, devices, portraits, charts, route lines, insets, badges, etc.)
-- Nav and primary-action treatment (when the surface has one)
-- Section sequence, especially the second fold
-- Image-native content the concept depends on
-- Typography, density, color/material treatment, motion cues
-
-Treat the mock as a north star, not a screenshot to trace. Don't rasterize core UI text. But if the live result lacks the mock's major ingredients, the implementation is wrong.
-
-If a photographic, architectural, product, or place-led mock becomes generic CSS scenery, decorative diagrams, bullets, or copy, stop and fix it. That's a broken implementation, not a harmless interpretation.
-
-Don't substitute a different hero composition or visual driver post-approval without user sign-off.
-
-## Step F: Asset Slicing via the Asset Producer
-
-Raster ingredients identified in Step E need clean production assets. Use the bundled `impeccable_asset_producer` subagent rather than producing inline.
-
-Spawn it as a scoped subagent. If you do not have explicit permission to use agents, stop and ask:
-
-```text
-Asset production will work better as a scoped subagent job. Should I spawn the Impeccable asset producer subagent for this step?
-```
-
-Pass to the agent:
-
-- Approved mock path or screenshot reference
-- Crop paths or a contact sheet with crop ids
-- Output directory
-- Required dimensions, format, transparency needs
-- Avoid list
-- Notes on what should remain semantic HTML/CSS/SVG instead of raster
-
-Attach image generation capability to the spawned agent when the harness supports it. Do **not** load image-generation reference material into the parent thread.
-
-Inline asset production is allowed only if the user declines subagents, the harness cannot spawn the authorized agent, or the user explicitly asks for single-thread mode.
-
-Prefer HTML/CSS/SVG/canvas when they can credibly reproduce an ingredient; reach for real, generated, or stock imagery when the mock or subject matter calls for actual visual content.
-
-## After This File
-
-Once Steps A through F are complete, return to the build: implement per new-work.md and SKILL.md's craft floor. The implementation builds against the confirmed palette, approved mock, and the assets the producer wrote.
+Return to [new-work.md](new-work.md) for the direction contract, implementation, and finishing pass.

skill/reference/craft.md

@@ -1,3 +1,5 @@
-# Craft (deprecated alias)
+# Craft
 
-`craft` is a deprecated alias for the standard build flow. Builds route through SKILL.md's new-work gate; [new-work.md](new-work.md) carries the direction checkpoint ("Decide, then build"), the identity playbook, and the finishing pass. Invoking `craft` explicitly forces the attended checkpoints: pause at the stated direction for confirmation, and follow [codex.md](codex.md)'s mock flow when the harness generates images. Nothing else differs from a plain build request.
+`craft` is the standard discovery-to-build flow. Resolve SKILL.md's init gate first: PRODUCT.md and DESIGN.md must establish the durable product and visual world. Then follow [new-work.md](new-work.md) to discover the task, develop genuinely different surface concepts inside that world, get the user's direction, write the auditable contract, build, and finish.
+
+Invoking `craft` explicitly makes the task checkpoints attended whenever a human or structured simulated-user tool exists. It does not rerun the identity workshop for every section or feature, and it does not skip creative collaboration merely because DESIGN.md already exists.

skill/reference/document.md

@@ -71,9 +71,9 @@ If a `DESIGN.md` already exists, **do not silently overwrite it**. Show the user
 ## Two paths
 
 - **Scan mode** (default): the project has design tokens, components, or rendered output. Extract, then confirm descriptive language. Use when there's code to analyze.
-- **Seed mode**: the project is pre-implementation (fresh init, nothing built yet). Interview for five high-level answers, write a minimal DESIGN.md marked `<!-- SEED -->`. Re-run in scan mode once there's code.
+- **Seed mode**: the project is pre-implementation (fresh init, nothing built yet). Reuse init's visual-world workshop and write the chosen world as a minimal DESIGN.md marked `<!-- SEED -->`. Re-run in scan mode once there's code.
 
-Decide by scanning first (Scan mode Step 1). If the scan finds no tokens, no component files, and no rendered site, offer seed mode; don't silently switch. `/impeccable document --seed` forces seed mode regardless of code presence.
+Decide by scanning first (Scan mode Step 1). If the scan finds no tokens, no component files, and no rendered site, offer seed mode; don't silently switch. `/impeccable document --seed` requests init's seed workshop, but it does not authorize replacing coherent code: when an incumbent system exists, offer scan mode or route an explicit identity-replacement request through init.
 
 ## Scan mode (approach C: auto-extract, then confirm descriptive language)
 
@@ -112,7 +112,7 @@ Skip anything the project doesn't have. Empty scale keys or fabricated tokens po
 
 ### Step 3: Ask the user for qualitative language
 
-The following require creative input that cannot be auto-extracted. Group them into one `AskUserQuestion` interaction:
+The following require creative input that cannot be auto-extracted. Ask them in two structured rounds of no more than three questions each (or the harness's lower limit), waiting between rounds:
 
 - **Creative North Star**: a single named metaphor for the whole system ("The Editorial Sanctuary", "The Golden State Curator", "The Lab Notebook"). Offer 2-3 options that honor PRODUCT.md's brand personality.
 - **Overview voice**: mood adjectives, aesthetic philosophy in 2-3 sentences, anti-references (what the system should not feel like).
@@ -338,64 +338,38 @@ Your own write is the freshest source; subsequent commands in this session don't
 
 ## Seed mode
 
-For projects with no visual system to extract yet. Produces a minimal scaffold, not a full spec.
+For projects with no visual system to extract yet. Produces a user-chosen visual-world scaffold, not a fabricated token spec.
 
-### Step 1: Confirm seed mode
+### Step 1: Route through init's workshop
 
-Before interviewing: "There's no existing visual system to scan. I'll ask five quick questions to seed a starter DESIGN.md. You can re-run `/impeccable document` once there's code, to capture the real tokens and components. OK?"
+PRODUCT.md is the prerequisite. If it is missing, load [init.md](init.md) and complete its strategic interview first. Do not create a visual identity without durable product context.
 
-If the user prefers to skip, stop. No file.
+If PRODUCT.md exists, load **Step 5: Establish the visual world** from [init.md](init.md) and run that same workshop. Do not start a parallel questionnaire about colors, fonts, or references: init's proposals must already be rooted in the audience world, cultural context, pinned direction, personality, and anti-references. A structured simulated user counts as the user and must get the same choice.
 
-### Step 2: Five questions
+If an init invocation already completed the workshop in this session, use its chosen direction directly. Do not ask again.
 
-Group into one `AskUserQuestion` interaction. Options must be concrete.
+### Step 2: Write seed DESIGN.md
 
-1. **Color strategy.** Pick one:
-   - Restrained: tinted neutrals + one accent ≤10%
-   - Committed: one saturated color carries 30–60% of the surface
-   - Full palette: 3–4 named color roles, each deliberate
-   - Drenched: the surface IS the color
-   
-   Then: one hue family or anchor reference ("deep teal", "mustard", "Klim #ff4500 orange").
-
-2. **Typography direction.** Pick one (specific fonts come later):
-   - Serif display + sans body
-   - Single sans (warm / technical / geometric / humanist; pick a feel)
-   - Display + mono
-   - Mono-forward
-   - Editorial script + sans
-
-3. **Motion energy.** Pick one:
-   - Restrained: state changes only
-   - Responsive: feedback + transitions, no choreography
-   - Choreographed: orchestrated entrances, scroll-driven sequences
-
-4. **Three named references.** Brands, products, printed objects. Not adjectives.
-
-5. **One anti-reference.** What it should NOT feel like. Also named.
-
-### Step 3: Write seed DESIGN.md
-
-Use the six-section spec from Scan mode. Populate what the interview answers; leave the rest as honest placeholders. The seed is a scaffold, not a fabricated spec.
+Use the six-section spec from Scan mode. Populate the selected workshop direction and leave unresolved implementation facts as honest placeholders. The seed commits a world and its invariants; it does not pretend implementation tokens already exist.
 
 Lead the file with:
 
 ```markdown
-<!-- SEED: re-run /impeccable document once there's code to capture the actual tokens and components. -->
+<!-- SEED: established with the user before implementation; re-run /impeccable document once there's code to capture the actual tokens and components. -->
 ```
 
 Per-section guidance in seed mode:
 
-- **Overview**: Creative North Star and philosophy phrased from the answers (color strategy + motion energy + references). Reference the user's anti-reference directly.
-- **Colors**: Color strategy as a Named Rule (e.g. *"The Drenched Rule. The surface IS the color."*). Hue family or anchor reference. No hex values; mark as `[to be resolved during implementation]`.
-- **Typography**: the direction the user picked (e.g. "Serif display + sans body"). No font names yet: `[font pairing to be chosen at implementation]`.
-- **Elevation**: inferred from motion energy. Restrained/Responsive → flat by default; Choreographed → layered. One sentence.
+- **Overview**: the chosen design thesis, layout behavior, first-view or first-task idea, material character, imagery stance, motion, and signature. Reference the user's audience world, pinned direction, and anti-references where they actually constrain the design.
+- **Colors**: the selected palette strategy and roles. Include values only when the user, an existing asset, or init's palette exploration established them; otherwise mark them `[to be resolved during implementation]`.
+- **Typography**: the selected type character and role relationship. Include font names only when established; otherwise mark the pairing `[to be resolved during implementation]`.
+- **Elevation**: the selected material and depth behavior, stated as an invariant rather than inferred from a generic motion preset.
 - **Components**: omit entirely; no components exist yet.
 - **Do's and Don'ts**: carry PRODUCT.md's anti-references directly plus the anti-reference named in Q5.
 
 Seed mode writes a minimal frontmatter with `name` and `description` only; no colors, typography, rounded, spacing, or components yet. Real tokens land on the next Scan-mode run. Skip the `.impeccable/design.json` sidecar in seed mode for the same reason: nothing to render.
 
-### Step 4: Confirm
+### Step 3: Confirm
 
 1. Show the seed DESIGN.md. Call out that it is a seed (the marker is the literal commitment).
 2. Tell the user: "Re-run `/impeccable document` once you have some code. That pass will extract real tokens and generate the sidecar."

skill/reference/init.md

@@ -2,27 +2,28 @@
 
 The setup command for a project. One codebase crawl feeds everything it writes:
 
-- **PRODUCT.md** (strategic): root project file for register, target users, product purpose, brand personality, anti-references, strategic design principles. Answers "who/what/why".
-- **DESIGN.md** (visual): root project file for visual theme, color palette, typography, components, layout. Follows the [DESIGN.md format spec](https://raw.githubusercontent.com/google-labs-code/design.md/main/docs/spec.md). Answers "how it looks".
+- **PRODUCT.md** (strategic): root project file for target users, product purpose, positioning, audience world, cultural context, non-negotiable direction, personality, anti-references, and strategic design principles. Answers "who/what/why" and preserves the human knowledge future design work must not invent cold. Visitor mode is task-scoped and does not live here.
+- **DESIGN.md** (visual): root project file for the user-approved visual world: theme, color roles, typography direction, material and component language, layout behavior, motion, and signature. Follows the [DESIGN.md format spec](https://raw.githubusercontent.com/google-labs-code/design.md/main/docs/spec.md). Answers "how it looks".
 - **`.impeccable/live/config.json`** (live mode): pre-configured so `{{command_prefix}}impeccable live` boots straight into variant mode with no first-time detour.
 
-It closes by pointing the user at the best command to run next. Every other impeccable command reads PRODUCT.md and DESIGN.md before doing any work.
+It closes by pointing the user at the best command to run next. Every other impeccable command reads PRODUCT.md and DESIGN.md before doing any work. Identity invention happens here, with the user, not later inside a page build.
 
 ## Step 1: Load current state
 
-Check what already exists. PRODUCT.md and DESIGN.md live at the project root, or under `.agents/context/` or `docs/` (case-insensitive). Read whichever are present with your native file tool. Also note whether `.impeccable/live/config.json` already exists (Step 6 leaves it untouched if so).
+Check what already exists. PRODUCT.md and DESIGN.md live at the project root, or under `.agents/context/` or `docs/` (case-insensitive). Read whichever are present with your native file tool and remember each resolved path. Refresh the resolved existing file; do not create a second root authority beside it. In a child app that inherits root context, confirm whether the user intends to update the shared root or create app-specific context before writing. Also note whether `.impeccable/live/config.json` already exists (Step 6 leaves it untouched if so).
 
 Decision tree:
-- **Neither file exists (empty project or no context yet)**: do Steps 2-4 (write PRODUCT.md), then decide on DESIGN.md based on whether there's code to analyze.
-- **PRODUCT.md exists, DESIGN.md missing**: skip to Step 5 and offer to run `/impeccable document` for DESIGN.md.
-- **PRODUCT.md exists but has no `## Register` section (legacy)**: add it. Infer a hypothesis from the codebase (see Step 2), confirm with the user, write the field.
+- **Neither file exists (empty project or no context yet)**: do Steps 2-5. Write PRODUCT.md, then establish the visual world in DESIGN.md before any build resumes.
+- **PRODUCT.md exists, DESIGN.md missing**: do Step 5. For refinement or extension, document a coherent incumbent implementation; otherwise run the visual-world workshop and write a seed DESIGN.md.
 - **PRODUCT.md exists but has no `## Platform` section (legacy)**: add it the same way, but only when the project is native (`ios` / `android` / `adaptive`) or the user wants it explicit; a missing field already means `web`.
-- **Both exist**: {{ask_instruction}} Ask which file to refresh. Skip the one the user doesn't want changed.
+- **PRODUCT.md is missing Positioning, Audience World, Cultural Context where relevant, or Pinned Direction (legacy)**: interview only for the missing durable fields and merge them into the resolved file before substantial new work.
+- **Both exist, ordinary init**: {{ask_instruction}} Ask which file to refresh. Skip the one the user doesn't want changed.
+- **Redesign or rebrand**: keep confirmed product facts unless the user changes them, but replace DESIGN.md through a new visual-world choice. The old code and DESIGN.md are evidence and anti-reference, not constraints on the replacement. “Redesign this page/site” is enough authorization; do not require the user to say “discard the identity” twice.
 - **Just DESIGN.md exists (unusual)**: do Steps 2-4 to produce PRODUCT.md.
 
 Never silently overwrite an existing file. Always confirm first.
 
-If init was invoked as a setup blocker by another command, such as `{{command_prefix}}impeccable craft landing page`, pause that command here. Complete init, then resume the original command. Your own writes are the freshest source; no reload needed. For craft, resume into shape next; init creates project context, but it is not a substitute for the task-specific shape interview and confirmed design brief.
+If init was invoked as a setup blocker by another command, such as `{{command_prefix}}impeccable craft landing page`, pause that command here. Complete init, then resume the original command. Your own writes are the freshest source; do not rerun `context.mjs`. For craft, resume into the task-specific discovery and [new-work.md](new-work.md); init commits the world, while the surface flow decides the requested composition inside it.
 
 ## Step 2: Explore the codebase
 
@@ -35,19 +36,12 @@ Before asking questions, thoroughly scan the project to discover what you can. T
 - **Design tokens / CSS variables**: Existing color palettes, font stacks, spacing scales
 - **Any style guides or brand documentation**
 
-Also form a **register hypothesis** from what you find:
-
-- Brand signals: `/`, `/about`, `/pricing`, `/blog/*`, `/docs/*`, hero sections, big typography, scroll-driven sections, landing-page-shaped content.
-- Product signals: `/app/*`, `/dashboard`, `/settings`, `/(auth)`, forms, data tables, side/top nav, app-shell components.
-
-Register is a hypothesis at this point, not a decision; Step 3 confirms it.
-
-Also form a **platform hypothesis**:
+Form a **platform hypothesis**:
 
 - Native signals: React Native / Expo (`react-native`, `expo`), Flutter (`pubspec.yaml`, `flutter`), SwiftUI / UIKit (`.swift`, `.xcodeproj`, an `ios/` app target), Jetpack Compose / Android (`build.gradle`, an `android/` app module, `AndroidManifest.xml`). An `ios/` and/or `android/` directory that is a real app target, not just a Capacitor/Cordova wrapper around a website.
 - Web signals (the default): a web framework (Vite, Next, Nuxt, SvelteKit, Astro), an HTML entry, a CSS/Tailwind setup, no native app target.
 
-Values: `web` / `ios` / `android` / `adaptive` (one codebase, ships both, adapts per OS). Mobile web is still `web`. Like register, this is a hypothesis; Step 3 confirms it.
+Values: `web` / `ios` / `android` / `adaptive` (one codebase, ships both, adapts per OS). Mobile web is still `web`. This is a hypothesis; Step 3 confirms it when the repo does not make it certain.
 
 Note what you've learned and what remains unclear. Also note any rough edges worth a follow-up command (thin hierarchy, flat or gray palette, missing error/empty states, dull copy); Step 7 turns these into concrete recommendations without re-analyzing.
 
@@ -60,26 +54,18 @@ Note what you've learned and what remains unclear. Also note any rough edges wor
 If the repo is empty or the user's brief is sparse, run a short interview before proposing PRODUCT.md. Do **not** turn a one-sentence request into a complete inferred PRODUCT.md and ask for blanket confirmation.
 
 - Use the harness's structured question tool when one exists. Otherwise, ask directly in chat and stop: one question at a time, with lettered options where the crawl suggests likely answers, waiting for each answer before the next.
-- Keep skill vocabulary (register, belief ladder, anti-references) out of question text; ask for the thing in words the user would use. For the brand register, ask like a magazine editor profiling the brand: curious and narrative, drawing out the story, the feel, and what a visitor should come to believe.
+- Keep skill vocabulary (belief ladder, anti-references, visual world) out of question text; ask for the thing in words the user would use.
 - Ask in focused rounds and wait for answers between them. Keep **one topic per question**; add rounds rather than fold several topics into one either-or choice. Options obey the same rule: an option answers only the question asked; never write a compound option that bundles a feeling with a business outcome or names an additional audience.
 - Use inferred answers as hypotheses or options, not as finished facts.
-- Complete at least one real user-answer round before drafting PRODUCT.md, unless every required answer is directly discoverable from repo docs.
-- Round 1 should establish register, platform, users, purpose, positioning, and desired outcome.
-- Round 2 should establish brand personality or references, anti-references, and accessibility needs, plus conversion & proof for Persuade surfaces.
+- Complete at least one real user-answer or approval round before drafting PRODUCT.md. Repo evidence may prefill the proposal, but it does not silently approve strategy or identity.
+- Round 1 asks at most three high-leverage questions: who and what job, what makes the product meaningfully different, and what working or cultural world should feel native to it. Confirm platform separately only when repository evidence is ambiguous.
+- Add a second round only for a pinned direction, decisive anti-reference, missing proof/content, or accessibility requirement that would materially change the proposals. Do not collect personality adjectives and reference lists by default.
 
 ### Minimum viable interview
 
-Ask enough to complete PRODUCT.md. At minimum, cover register confirmation, **platform confirmation** (`web` / `ios` / `android` / `adaptive`), users, purpose, positioning, brand personality, anti-references, and accessibility needs (plus conversion & proof for Persuade surfaces) unless each answer is directly discoverable from repo context. Never let the template's default `web` stand unconfirmed for a native or cross-platform repo. After at least one interview round, you may propose inferred answers, but the user must confirm them before you write PRODUCT.md. Never synthesize PRODUCT.md from the original task prompt alone.
+Ask enough to capture users, purpose, positioning, the audience's working world, and any pinned direction or anti-reference the user actually has. Confirm **platform** (`web` / `ios` / `android` / `adaptive`) when repository evidence is ambiguous. Relevant cultural context, conversion proof, named references, personality, and additional accessibility needs are optional fields, not mandatory interview ceremony. Complete at least one real answer round, then propose only the remaining inferred facts for confirmation before writing. Never synthesize PRODUCT.md from the original task prompt alone.
 
-### Register (ask first; it shapes everything below)
-
-Every design task serves one of four visitor modes (see SKILL.md's Registers): **Persuade** (marketing, landing, campaigns), **Experience** (portfolios, albums, bodies of work), **Operate** (app UI, admin, dashboards, tools), and **Read** (documentation, editorial, long-form). PRODUCT.md stores the two-value family that covers them: `brand` covers Persuade and Experience, `product` covers Operate and Read. The brief decides the exact mode per task; the stored register only sets the default family.
-
-If Step 2 produced a clear hypothesis, lead with it: *"From the codebase, this looks like a [brand / product] surface. Does that match your intent, or should we treat it differently?"*
-
-If the signal is genuinely split (e.g. a product with a big marketing landing), {{ask_instruction}} Ask which register describes the **primary** surface. The register can be overridden per task later, but PRODUCT.md carries one default. Settle the default before drafting any register-dependent questions; never batch Persuade-only questions (Conversion & proof) into the same round as the question that decides the register.
-
-### Platform (ask right after register)
+### Platform
 
 Every project targets **web** (includes responsive mobile web), **ios**, **android**, or **adaptive** (one codebase, ships both, adapts per OS: Flutter, React Native, KMP). Platform picks the native rulebook: HIG for `ios`, Material 3 for `android`, both for `adaptive`, none for `web`.
 
@@ -94,8 +80,7 @@ A monorepo shipping both a website and a native app gets a PRODUCT.md per app, e
 - What does success look like?
 - If more than one kind of user is plausible, confirm a primary and secondary audience; don't manufacture a split that isn't there. An audience implied by another answer (a success metric, a CTA) is still unconfirmed; ask before writing it as secondary.
 - If the surface speaks to a different audience than the people who use the product, ask the user to name both.
-- For brand: what emotions should the interface evoke? (confidence, delight, calm, urgency) Ask this standalone; don't fold emotions into the success question.
-- For product: what workflow are they in? What's the primary task on any given screen?
+- What workflow or decision are they in when they use it?
 
 ### Positioning
 - In one line, what does this do that nothing else does? The single strategic claim every screen reinforces.
@@ -106,9 +91,19 @@ A monorepo shipping both a website and a native app gets a PRODUCT.md per app, e
   - Push for specific named references with the *specific* thing about them that fits this brand, not generic "modern" adjectives or category-bucket lanes.
 - What should this explicitly NOT look like? Any anti-references?
 
+### Audience world & direction
+
+The visual world needs roots deeper than a style adjective. Learn the reality the audience already inhabits before proposing a direction:
+
+- What tools, places, objects, documents, materials, or rituals are familiar to them in this context?
+- For Persuade and Experience work, what cultural home feels truthful: a place, era, craft, medium, or scene? Ask only for associations that illuminate the product; never force a decorative metaphor.
+- Is any visual direction non-negotiable? Preserve the user's exact constraint, whether it is a named aesthetic, an existing identity, a reference, or a deliberate refusal of one.
+
+These are strategic inputs, not a request for the user to design the page. Do not ask them to choose colors, fonts, radii, or a component recipe here. Step 5 turns the confirmed inputs into genuinely different visual-world proposals and asks the user to choose.
+
 ### Conversion & proof (Persuade surfaces only)
 
-Ask these only when the primary surface is a Persuade one (marketing, landing, campaigns). Experience and Read surfaces (portfolios, albums, long-form writing, documentation) get no CTA, belief-ladder, or proof questions even when the stored register is `brand`; skip this section and its PRODUCT.md counterpart.
+Ask these only when the current request is a Persuade surface (marketing, landing, campaigns) and the answers are not already in the brief. Experience and Read surfaces get no CTA, belief-ladder, or proof questions; visitor mode is decided per task and is not stored in PRODUCT.md.
 
 - What's the primary CTA?
 - What's the secondary fallback, for visitors not ready for the primary?
@@ -131,10 +126,6 @@ Synthesize into a strategic document:
 ```markdown
 # Product
 
-## Register
-
-product
-
 ## Platform
 
 web
@@ -148,8 +139,17 @@ web
 ## Positioning
 [The single strategic claim every screen reinforces. Not a visual rule, not an anti-reference.]
 
+## Audience World
+[The tools, places, objects, documents, materials, and rituals familiar to the audience in this context. Include only what the user confirmed.]
+
+## Cultural Context
+[The truthful place, era, craft, medium, or scene that can ground Persuade or Experience work. Omit the section when it is genuinely irrelevant to an Operate or Read product.]
+
+## Pinned Direction
+[Any visual direction, existing identity, named aesthetic, or reference the user made non-negotiable. Write `None.` when the user explicitly wants the workshop to remain open.]
+
 ## Conversion & proof
-[Persuade surfaces only (marketing, landing, campaigns). Omit this section entirely, heading included, for the product register and for Experience or Read surfaces such as portfolios, albums, or long-form writing.]
+[Persuade surfaces only (marketing, landing, campaigns). Omit this section entirely, heading included, for Experience, Operate, or Read surfaces.]
 - Primary and secondary CTA: [...]
 - The line a visitor remembers after 10 seconds: [...]
 - Belief ladder: [...]
@@ -168,22 +168,31 @@ web
 [WCAG level, known user needs, considerations]
 ```
 
-Register is either `brand` or `product` as a bare value. No prose, no commentary. Platform is `web`, `ios`, `android`, or `adaptive`, also a bare value; omit the section only on legacy files you're leaving untouched, otherwise write `web` explicitly.
+Platform is `web`, `ios`, `android`, or `adaptive` as a bare value; omit the section only on legacy files you're leaving untouched, otherwise write `web` explicitly.
 
 Write fields as prose, and use bold sparingly: only where a word carries a decision, never as a label lead-in on every line.
 
-Write to `PROJECT_ROOT/PRODUCT.md`. If `.impeccable.md` existed, the loader already renamed it; merge into that content rather than starting from scratch.
+For a new context file, write to `PROJECT_ROOT/PRODUCT.md`. When PRODUCT.md was resolved from another supported location, update that exact file instead. If `.impeccable.md` existed, the loader already renamed it; merge into that content rather than starting from scratch.
 
-## Step 5: Decide on DESIGN.md
+## Step 5: Establish the visual world (for DESIGN.md)
 
-Offer `/impeccable document` either way. Two paths:
+Identity is not an unattended prelude to the page build. Establish it here, while the user can choose it, and write DESIGN.md before any new-work flow resumes.
 
-- **Code exists** (CSS tokens, components, a running site): "I can generate a DESIGN.md that captures your visual system (colors, typography, components) so variants stay on-brand. Want to do that now?"
-- **Pre-implementation** (empty project): "I can seed a starter DESIGN.md from five quick questions about color strategy, type direction, motion energy, and references. You can re-run once there's code, to capture the real tokens. Want to do that now?"
+### Refinement or extension: document the incumbent world
 
-If the user agrees, delegate to `/impeccable document` (it auto-detects scan vs seed). Load its reference and follow that flow.
+If the request preserves or extends the current identity and the crawl found an intentional visual system in real code, do not invent a replacement merely because DESIGN.md is missing. Load [document.md](document.md), use scan mode, and show the user the design language you found before writing it down. Ask before replacing an existing DESIGN.md.
 
-If the user prefers to skip, mention they can run `/impeccable document` any time later.
+### Greenfield or redesign: run the workshop
+
+Run the workshop when the project is visually uncommitted or the user asked for a redesign/rebrand. On redesign, keep the old system visible only long enough to identify what must not survive and which product facts, content, functions, or assets remain useful. Do not offer “the old look, polished” as a candidate world.
+
+1. **Synthesize two or three credible worlds.** Derive them from the confirmed product mechanism, audience world, cultural context, pinned direction, personality, and anti-references in PRODUCT.md. Each proposal must have a distinct identity thesis, layout grammar, type and material character, palette strategy, component character, imagery stance, motion grammar, and one reusable signature. They must be different ways to make *this product* true, not generic category styles with new names. Do not design a particular page here; later craft work composes new surfaces inside the chosen grammar.
+2. **Use color entropy as a challenger, never an answer.** If color is genuinely unpinned, run `node {{scripts_path}}/palette.mjs` to challenge the reflex palette. Translate useful tension into a proposal; never let the script override the confirmed brief, pinned direction, existing assets, accessibility, or the user's choice. Structural concept entropy belongs to the task-scoped [new-work.md](new-work.md) flow, not to identity selection.
+3. **Ask the user to choose.** Present the directions concisely in the structured question tool when available, one option per world plus a way to revise the premises. Otherwise ask in chat and stop. The user may choose, combine compatible ideas, reject all of them, or tighten the direction. A harness-provided simulated user is a real answer mechanism and must exercise this same turn. Do not silently select a world while a question mechanism exists.
+4. **Resolve the chosen world.** Follow up only on choices that materially affect the system. Do not turn this into a token questionnaire. The goal is agreement on a coherent world and its invariants, not approval of every CSS value.
+5. **Write a seed DESIGN.md.** Follow the [DESIGN.md format spec](https://raw.githubusercontent.com/google-labs-code/design.md/main/docs/spec.md). Record the chosen thesis, layout behavior, typography direction, color roles, surfaces and materials, components, imagery, motion, and signature. Include concrete values only when the code, assets, palette exploration, or user established them; mark unresolved implementation details as such instead of fabricating a finished token system. Add `<!-- SEED: established with the user before implementation; refresh by scanning the built system -->` near the top. Write a new file at the project root; refresh an existing DESIGN.md at its resolved path.
+
+If there is truly no human or structured question mechanism, derive the proposals anyway, choose the one best supported by the explicit brief and pinned constraints, and add `<!-- UNCONFIRMED ASSUMPTIONS: confirm on the next attended init -->` to both context files. Surface the assumptions in the final response and force confirmation on the next attended init. This is a degraded fallback, not permission for a capable harness to skip the interview or call the world user-approved.
 
 ## Step 6: Configure live mode (when code exists)
 
@@ -206,12 +215,12 @@ Writing the config file is harmless and needs no consent; only the CSP **source-
 ## Step 7: Recommend starting points, then wrap up
 
 Summarize tersely:
-- Register captured (brand / product) and platform captured (web / ios / android / adaptive)
-- What was written (PRODUCT.md, DESIGN.md, live config, or a subset)
+- Platform captured (web / ios / android / adaptive) when relevant
+- What was written (PRODUCT.md, the chosen visual world in DESIGN.md, live config, or a subset)
 - The 3-5 strategic principles from PRODUCT.md that will guide future work
 - If DESIGN.md or live config is pending, one line on how to set it up later
 
-Then recommend the **best commands to run next**, drawn from what your Step 2 crawl already surfaced. Do not run a fresh analysis here; surface observations you already have. Tailor to register **and platform**, offer the 2-4 most relevant (not a menu dump), and give the exact command to type. Group by intent:
+Then recommend the **best commands to run next**, drawn from what your Step 2 crawl already surfaced. Do not run a fresh analysis here; surface observations you already have. Tailor to the current surface and platform, offer the 2-4 most relevant (not a menu dump), and give the exact command to type. Group by intent:
 
 - **Build something new**: `/impeccable craft <feature>` (shape, then build end-to-end) or `/impeccable shape <feature>` (plan first). Lead with this for empty or early-stage projects.
 - **Improve what's there**: name the specific surface. `/impeccable critique <page>` for a scored UX review; `/impeccable audit <area>` for a11y / perf / responsive checks; `/impeccable polish <component>` for a pre-ship pass. When the crawl flagged a specific weakness, point the matching command at it: thin hierarchy or spacing → `layout`, flat or gray palette → `colorize`, missing error / empty states → `harden` or `onboard`, dull or unclear copy → `clarify`.

skill/reference/live-generation.md

@@ -1,32 +0,0 @@
-# Live generation worker
-
-You generate reviewable variants for an existing interface. The supervisor owns all filesystem writes, publication, cancellation, and recovery. Return only the requested structured output.
-
-## Identity and quality
-
-- Preserve the existing product identity by default: palette roles, available fonts, component roles, copy, semantics, accessibility, and public APIs.
-- Treat DESIGN.md as visual authority and PRODUCT.md as strategy/voice authority.
-- Define one shared identity lock and distinct design axes before authoring the first variant.
-- Make each variant independently shippable. Vary hierarchy, topology, typography, color commitment, density, or structural decomposition, not arbitrary decoration.
-- Preserve short labels as readable units and avoid unnecessary wrapping at the supplied viewport.
-- Prefer hierarchy, proportion, rhythm, and composition before adding nested chrome.
-- Silently reject overflow, awkward wrapping, accidental compression, weak alignment, inaccessible states, and off-brand component treatments.
-
-## Authoring contract
-
-- The selected root is a complete replacement with exactly one top-level element.
-- Preserve copy and dynamic relationships unless the user explicitly requests content changes.
-- Never emit `data-impeccable-*` wrappers inside variant markup.
-- Follow `event.scaffold.cssAuthoring` exactly. Fence every preview selector to its variant.
-- Do not write source or project files. Return only paths and content permitted by the current output schema.
-- Published variants are immutable. Never repeat or revise an earlier variant in a later phase.
-- The staged artifact identifies the exact selected page/component. Inspect its real imports, shared layouts, styles, tokens, and route ownership with read-only tools whenever needed; do not assume a single-page project or guess from filenames.
-
-## Progressive phases
-
-- `first`: return variant 1 and the complete coherent plan. Defer parameters.
-- `remainder`: return variants 2 through N together, following the stored plan, plus final parameter wiring CSS and the manifest for every variant. Do not change variant 1 or any default appearance.
-- `params`: recovery only when all variants were durably published but their parameters were not. Return only parameter wiring CSS and the manifest.
-- Parameters are coarse, meaningful axes already present in the designs. Tiny elements may have none; larger compositions usually expose two or three. Never exceed four per variant.
-
-The supervisor runs the Impeccable detector before publication. On a repair turn, use judgment on every finding: fix real defects, but preserve contextually intentional design and detector false positives by returning the narrow `detectorWaivers` entry requested by the repair schema with a concrete reason. Never persist project ignore config or add inline ignore comments from this read-only worker. Publication proceeds only when every new finding was fixed or explicitly waived.

skill/reference/live.md

@@ -14,28 +14,21 @@ Execute in order. No step skipped, no step reordered.
 
 1. `live.mjs`: boot. If the request names or implies a file, route, or app inside a monorepo, infer the concrete path and run `node {{scripts_path}}/live.mjs --target <path>` instead; then run the rest of this live session from the returned `projectRoot`.
 2. Open the app URL that serves `pageFile` (infer from `package.json`, docs, terminal output, or an open tab). Never use `serverPort`; it's the helper, not the app. **Cursor:** `browser_navigate` to that URL before polling; do not skip. **Other harnesses:** use the available browser tool; if the URL is uncertain, ask the user once.
-3. Poll loop with the default long timeout (600000 ms). Run `live-poll.mjs` again immediately after every event or `--reply`; Codex runs this one-shot poll in the foreground. Never pass a short `--timeout=`.
+3. Poll loop with the default long timeout (600000 ms). After every event or `--reply`, run `live-poll.mjs` again immediately. Never pass a short `--timeout=`.
 
 The global bar **Impeccable mark** dims and shows a pulsing amber dot when no agent is long-polling `/poll`. Hover the mark for the hint; restart `live-poll.mjs` to reconnect.
-4. On `generate`: reuse `event.scaffold` when present; read the screenshot if present; load the action's reference; deliver variants using the harness policy below; `--reply done`; poll again. In Codex, delegate the complete event to `impeccable_live_generator` and resume the foreground poll immediately; the generator owns publication and the reply.
+4. On `generate`: read screenshot if present; load the action's reference; plan three distinct directions; write all variants in one edit; `--reply done`; poll again.
 5. On `steer`: read the message and `pageUrl`; do the work (page edits, navigation help, or a short reply in the `--reply` message); `--reply steer_done`; poll again. No pickup ack. The Steer bar unlocks when `steer_done` arrives over SSE.
-6. On `accept` / `discard`: the poll script runs `live-accept.mjs`, acknowledges the delivered event, and prints `_completionAck`. Plain accepts/discards are terminal immediately. Carbonize accepts remain recoverable until the foreground task runs `live-complete.mjs --id EVENT_ID`; finish that cleanup before polling again.
+6. On `accept` / `discard`: the poll script runs `live-accept.mjs`, acknowledges the delivered event, and prints `_completionAck`. Plain accepts/discards are terminal immediately; carbonize accepts remain recoverable until you finish cleanup, run `live-complete.mjs --id EVENT_ID`, and only then poll again.
 7. If interrupted, run `live-status.mjs` or `live-resume.mjs` before guessing. The durable journal replays unacknowledged work after helper restart.
 8. On `exit`: run the cleanup at the bottom.
 
 Harness policy:
 - **Claude Code**: run the poll as a **background task** (no short timeout). The harness notifies you when it completes, so the main conversation stays free. Do not block the shell.
 - **Cursor**: run **one-shot** poll in a **background terminal** with notify on `"type":"(steer|generate|accept|discard|exit)"`. After each event the poll exits; handle it, `--reply`, then start `live-poll.mjs` again. Do **not** use `--stream` on Cursor: incremental stdout notify is slower in practice than exit-based notify (~5s vs sub-second in testing).
-- **Codex**: run the default one-shot poll in a **yielded foreground exec session**. Do not suffix it with `&`, use `--stream`, or leave Live without an active foreground poll. When `generate` arrives, delegate to the low-effort `impeccable_live_generator` agent with a compact handoff, then immediately start the next foreground poll while that agent publishes and replies. Do not paste this full reference into the handoff. Handle Steer, Accept/Discard, manual Apply, carbonize, and Exit in the main task; after each handler/reply, restart the foreground poll.
+- **Codex**: run the poll in the **foreground** (blocking shell; not a background task, not a subagent). Codex background exec sessions do not reliably surface poll stdout back into the conversation at the moment events arrive, so a "fire-and-forget" background poll will stall live mode.
 - **Other harnesses**: one-shot foreground unless you know stdout reliably returns to this session when a shell exits.
 
-Generation delivery policy:
-- **Default (Claude Code, Cursor, and other harnesses):** keep the established atomic single-edit delivery unless that harness has independently demonstrated that progressive tool calls are faster and reliable. This avoids trading model latency for extra tool-call latency on harnesses with different streaming behavior.
-
-<codex>
-- **Codex progressive override:** deliver progressively through `live-publish.mjs`, never by editing project source directly. Publish variant 1 as soon as it is complete, then publish each additional validated variant (or the largest ready prefix) without waiting for later siblings. Attach parameter CSS/manifests only with the complete set. The browser makes every arrived variant immediately reviewable and acceptable; Accept/Discard durably cancel unfinished revisions.
-</codex>
-
 Chat is overhead. No recap, no tutorial output, no pasting PRODUCT / DESIGN bodies. Spend tokens on tools and edits; on failure, one or two short sentences.
 
 ## Start
@@ -46,10 +39,6 @@ node {{scripts_path}}/live.mjs
 
 Output JSON: `{ ok, serverPort, serverToken, pageFiles, hasProduct, product, productPath, hasDesign, design, designPath }`. `pageFiles` is the list of HTML entries the live script was injected into. Keep PRODUCT.md and DESIGN.md in mind for variant generation; **DESIGN.md wins on visual decisions; PRODUCT.md wins on strategic/voice decisions.** When DESIGN.md is missing, identity is **not** absent; extract it from CSS variables, computed styles, and sibling components on the page (see Step 4 Phase A). Identity preservation is the default; departure from existing identity requires an explicit trigger from PRODUCT.md anti-references or the user's freeform prompt.
 
-Normally `codexWorker.enabled` is `false`; run the default unfiltered `live-poll.mjs` command in the foreground. If an explicitly opted-in run returns `codexWorker.enabled: true`, follow the experimental worker section below instead.
-
-If an explicitly opted-in run includes `codexWorker.error: "codex_cli_unavailable"`, tell the user once that Live fell back to foreground generation, then run the returned unfiltered `codexWorker.foregroundPoll`. Do not retry or install anything during the session.
-
 `serverPort` and `serverToken` belong to the small **Impeccable live helper** HTTP server (serves `/live.js`, SSE, and `/poll`). That port is **not** your dev server and is usually not the URL you open to view the app. The browser page is whatever origin serves one of the `pageFiles` entries (Vite / Next / Bun / tunnel / LAN hostname).
 
 If output is `{ ok: false, error: "config_missing" | "config_invalid", path }`, this project hasn't been configured for live mode (or its config is stale). See **First-time setup** at the bottom.
@@ -101,61 +90,20 @@ node {{scripts_path}}/live-complete.mjs --id SESSION_ID
 
 Server restart rule: start `live-server.mjs` again, then poll. Startup requeues unacknowledged pending events from the journal, so do not ask the user to click Go again unless `live-resume.mjs` says no active session exists.
 
-### Experimental dedicated Codex worker
-
-The app-server supervisor is retained for controlled experiments, but it is not the primary Codex path. Enable it explicitly for a run:
-
-```bash
-IMPECCABLE_LIVE_CODEX_WORKER=1 node {{scripts_path}}/live.mjs
-```
-
-Activation remains process-local. The worker is off by default, including in Codex. `IMPECCABLE_LIVE_CODEX_WORKER=1` is the direct opt-in; alternatively, Codex may opt in through `experimentalCodexWorker.enabled`. A committed setting can never switch a non-Codex harness onto this path:
-
-```json
-{
-  "experimentalCodexWorker": {
-    "enabled": true,
-    "profile": "quality",
-    "delivery": "progressive"
-  }
-}
-```
-
-When explicitly enabled, the worker remains Codex-only. Claude, Gemini, Cursor, and every other harness keep their portable polling behavior. Before detaching anything, Live resolves the configured Codex executable using the same explicit-path/PATH rules as Node spawn. A missing CLI becomes an immediate, durable foreground fallback. Otherwise Live records the worker as `starting` and returns immediately. Run only the returned foreground control poll. It checks the owned worker process every two seconds and safely restores generation/accept/discard leasing if startup, authentication, model selection, or the worker process fails. Dedicated-worker leases expire after 15 seconds, so a hard process loss cannot strand browser work behind the portable ten-minute lease.
-
-```bash
-node {{scripts_path}}/live-poll.mjs --stream --types=steer,manual_edit_apply,carbonize_cleanup,exit --codex-worker-fallback
-```
-
-The supervisor launches its own `codex app-server --stdio` process, dynamically prefers the strongest visible general model (currently GPT-5.6 Sol), and uses medium reasoning. The optional `fast` profile retains Spark/mini selection and low reasoning for controlled comparisons. It creates a dedicated Impeccable-owned thread and persists only that id in `.impeccable/live/codex-worker.json`; it never lists, resumes, steers, or writes to the desktop task. A crash reconnect may resume that id only when the ownership marker and project cwd both match. Clean Live exit interrupts the active turn, archives the dedicated thread, and stops app-server.
-
-The first generation turn in a worker task attaches the installed Impeccable skill as a native app-server skill input and resolves inherited/monorepo PRODUCT.md and DESIGN.md through the same context loader as the foreground skill. Each generation supplies the exact selected source artifact, event, scaffold, page URL, and action reference. The persistent read-only thread decides which imports, route layouts, styles, tokens, or shared components it needs to inspect; no lexical source-neighborhood heuristic stands in for repository understanding. Annotated requests attach `screenshotPath` as a real high-detail local image instead of a JSON path.
-
-One persistent app-server thread performs both normal generation turns so identity, repository discoveries, the variant plan, and skill guidance remain coherent. Model turns run read-only and return structured staged-artifact files. Before publication, the supervisor runs the Impeccable detector against the staged candidate, compares it with the pre-existing baseline, and asks the same thread for one repair when new findings appear. The repair must fix real defects or explicitly classify contextually intentional/false-positive findings with narrow, reasoned per-candidate waivers; only findings left neither fixed nor waived block publication. Existing project detector ignores are honored by the scan, while the read-only worker never persists new config or inline suppressions. The supervisor then validates paths and publishes exclusively through the generation publisher's epoch/source-hash/immutable-prefix fence. Source-wrapper sessions use an isolated preview under `.impeccable/live/previews/`; the true source stays byte-identical until Accept. Progressive variant 1 is immediately reviewable; variants 2 through N and their parameters arrive together from turn two. Accept/Discard interrupts the active app-server turn, while the durable generation fence rejects any late completion that still races cancellation.
-
-Controls:
-
-```bash
-node {{scripts_path}}/live-codex-worker.mjs --status
-node {{scripts_path}}/live-codex-worker.mjs --stop
-```
-
-Model and binary overrides are `IMPECCABLE_LIVE_CODEX_PROFILE`, `IMPECCABLE_LIVE_CODEX_MODEL`, `IMPECCABLE_LIVE_CODEX_EFFORT`, and `IMPECCABLE_CODEX_PATH`. `delivery: "atomic"` retains the one-turn publication control. Steer, manual Apply, carbonize cleanup, and Exit remain on the high-judgment foreground control lane; the server's type filter prevents either lane from leasing the other's events.
-
 ## Handle `generate`
 
 **Replace mode** (default): `{id, action, freeformPrompt?, count, pageUrl, element, screenshotPath?, comments?, strokes?}`.
 
 **Insert mode** (`event.mode === "insert"`): `{id, mode: "insert", count, pageUrl, insert: { position, anchor }, placeholder: { width, height }, freeformPrompt?, screenshotPath?, comments?, strokes?}`. No `action`. Requires a non-empty `freeformPrompt` **or** annotations. Screenshot is sent only when annotations exist (same rule as replace). Use `placeholder` dimensions as a soft size hint for net-new content.
 
-Speed matters; the user is watching the selected element. Reuse server preflight metadata when available, minimize discovery calls, and follow the harness-specific delivery policy above.
+Speed matters; the user is watching a spinner. Minimize tool calls by using the wrap/insert helper and writing all variants in a single edit.
 
 ### Insert mode branch
 
 When `event.mode === "insert"`:
 
 1. Read the screenshot if `event.screenshotPath` is present (annotations only).
-2. If `event.scaffold` is present, use it as the insert-helper result and do **not** run the helper again. Otherwise run the insert helper instead of wrap:
+2. Run the insert helper instead of wrap:
 
 ```bash
 node {{scripts_path}}/live-insert.mjs --id EVENT_ID --count EVENT_COUNT --position after \
@@ -165,7 +113,7 @@ node {{scripts_path}}/live-insert.mjs --id EVENT_ID --count EVENT_COUNT --positi
 - `--position` ← `event.insert.position` (`before` | `after`)
 - Anchor flags ← `event.insert.anchor` (same mapping as wrap: id, classes, tag, text)
 
-The scaffold has **no** `data-impeccable-variant="original"`. Variants are net-new HTML+CSS inserted at `insertLine`. For Operate/Read surfaces load `operate.md`; Persuade/Experience surfaces use SKILL.md's mode guidance plus `new-work.md` when the variant invents identity (freeform only, no action sub-command). Deliver using the harness policy, then `--reply done`.
+The scaffold has **no** `data-impeccable-variant="original"`. Variants are net-new HTML+CSS inserted at `insertLine`. Load `brand.md` or `product.md` (freeform only, no action sub-command). Write all variants in one edit, then `--reply done`.
 
 For Svelte/SvelteKit targets, `live-insert.mjs` returns `previewMode: "svelte-component"` with `mode: "insert"`, `file` pointing at a temporary `node_modules/.impeccable-live/<id>/manifest.json`, `componentDir` pointing at the variant component files, and `sourceFile` pointing at the real `.svelte` route. Write each inserted variant as a real Svelte component (`v1.svelte`, `v2.svelte`, …) under `componentDir`. Insert variants must be non-empty net-new content with a single top-level root, no `data-impeccable-*` attributes, and CSS in each component's `<style>` block. Do **not** edit the route source during generation; the browser mounts the temporary component before/after the live anchor while the user cycles variants. On Accept, `live-accept.mjs` inserts the selected component markup into `sourceFile` immediately and deletes the temp session after the source write succeeds.
 
@@ -190,8 +138,6 @@ Reading annotations precisely:
 
 ### 2. Wrap the element
 
-When `event.scaffold` is present, the local helper already found and wrapped the source before the poll returned. Treat `event.scaffold` as the successful helper output and skip this command entirely. `event.scaffoldAttempted` with `scaffoldError` means local preflight could not finish; use the command/fallback path below. This optimization removes a deterministic tool round trip without changing the generated design.
-
 ```bash
 node {{scripts_path}}/live-wrap.mjs --id EVENT_ID --count EVENT_COUNT --element-id "ELEMENT_ID" --classes "class1,class2" --tag "div" --text "TEXT_SNIPPET"
 ```
@@ -211,9 +157,7 @@ Output on success: `{ file, insertLine, commentSyntax, styleMode, styleTag, cssS
 
 For Svelte/SvelteKit targets, `live-wrap.mjs` returns `previewMode: "svelte-component"` with `file` pointing at a temporary `node_modules/.impeccable-live/<id>/manifest.json`, `componentDir` pointing at the variant component files, and `sourceFile` pointing at the real `.svelte` route. Write each variant as a real Svelte component (`v1.svelte`, `v2.svelte`, …) under `componentDir`; use the `propContract` prop names for dynamic text (`{propName}`), not literal snapshot strings. Put variant CSS in each component's `<style>` block with semantic class selectors (no `@scope`, no `data-impeccable-*`). Reply with `--file` set to the manifest path; the browser dynamically imports and mounts the compiled components so Svelte HMR does not reset page state while the user cycles variants. On Accept, `live-accept.mjs` inlines the accepted component back into `sourceFile` immediately after source promotion succeeds.
 
-For Nuxt/Vue targets, `live-wrap.mjs` returns `previewMode: "vue-component"` with `file` pointing at an app-local generated manifest under `<appDir>/.impeccable-live/<id>/manifest.json`, `componentDir` pointing at real Vue SFC variants, and `sourceFile` pointing at the untouched `.vue` route. Write `v1.vue`, `v2.vue`, … with one root inside `<template>` and variant CSS in `<style scoped>`; keep dynamic text on the `propContract` bindings as `{{ propName }}`. Do **not** rewrite `sourceFile` during generation: Nuxt/Vite compiles and mounts these dev-only modules without invalidating the route. Accept is the only route write and inlines the selected template/CSS under the source lock; Discard deletes the generated session.
-
-**Params on component-preview paths go in a sidecar, never as an attribute.** Svelte parses `{` inside an attribute value as the start of an expression, and both Svelte/Vue previews mount without an HTML variant wrapper. Declare params in `componentDir/params.json`, keyed by variant number, using the exact param schema from section 7:
+**Params on the Svelte component path go in a sidecar, never as an attribute.** Svelte parses `{` inside an attribute value as the start of an expression, so a `data-impeccable-params='[{…}]'` attribute on a component element fails to compile (`Expected token }`). Declare params for this path in `componentDir/params.json`, keyed by variant number, using the exact param schema from section 7:
 
 ```json
 {
@@ -247,7 +191,7 @@ All three carry `fallback: "agent-driven"`. Follow **Handle fallback** below.
 
 ### 3. Load the action's reference
 
-If `event.action` is `impeccable` (the default freeform action), use SKILL.md's shared laws plus the loaded mode depth (`operate.md` for Operate/Read; `new-work.md` when the variant invents identity). Do not load a sub-command reference. **Freeform is not a pass to skip parameters:** you still follow the composition budget and the freeform bias in **§7 Parameters** below. Sub-command files list MUST-have signature knobs; freeform has no such file, so sizing knobs from surface weight and primary axes is entirely on you.
+If `event.action` is `impeccable` (the default freeform action), use SKILL.md's shared laws and decide the visitor mode from the selected surface. Do not load a sub-command reference. **Freeform is not a pass to skip parameters:** you still follow the composition budget and the freeform bias in **§7 Parameters** below. Sub-command files list MUST-have signature knobs; freeform has no such file, so sizing knobs from surface weight and primary axes is entirely on you.
 
 Any other `event.action` (`bolder`, `quieter`, `distill`, `polish`, `typeset`, `colorize`, `layout`, `adapt`, `animate`, `delight`, `overdrive`): Read `reference/<action>.md` before planning. Each sub-command encodes a specific discipline; skipping its reference produces generic output. Those files may require specific params; layer them on top of the §7 budget, not instead of it.
 
@@ -306,13 +250,13 @@ Three variants → three DIFFERENT axes. The trio reads as *the same brand at th
 
 **While planning each variant, also name its 2–3 parameter knobs** (per the §7 budget table). Parameters are part of the design, not a decoration added afterward. If the variant explores density, expose a density knob. If it explores color commitment, expose a color-amount range. Deciding "what's tunable" during planning produces better knobs than retrofitting them onto finished HTML.
 
-**Departure mode.** Each variant anchors to a different **aesthetic direction**, derived from the brand's stated voice and register in PRODUCT.md. Do NOT pick from a fixed catalog of lane categories. The right three directions for this brand are not the same as the right three for another brand, and picking from a list is itself the training-data reflex (the model selects "Swiss-grid, Terminal, Industrial-signage" every time because those are the furthest-from-editorial items in any enumerated list).
+**Departure mode.** Each variant anchors to a different **aesthetic direction**, derived from PRODUCT.md's audience world and voice plus the current DESIGN.md. Do NOT pick from a fixed catalog of lane categories. The right three directions for this product are not the same as the right three for another, and picking from a list is itself the training-data reflex (the model selects "Swiss-grid, Terminal, Industrial-signage" every time because those are the furthest-from-editorial items in any enumerated list).
 
 Instead, work from the brand:
 
 1. Read PRODUCT.md's Brand Personality words. What physical, spatial, or material experiences would embody those words if design were not involved? (A personality described as "specific, earned, unmistakable" evokes a hand-stamped letter, a numbered print, a watchmaker's loupe. A personality described as "restless, loud, unfiltered" evokes a concert poster, a spray-painted wall, a megaphone.)
 2. From those physical experiences, derive three visual directions that are genuinely different from each other AND from the current surface you're departing.
-3. Avoid the **reflex-reject lanes** in [new-work.md](new-work.md). Don't trade one monoculture for another. If you find yourself reaching for "Swiss-grid" or "Terminal" or "Industrial-signage" by reflex, you are pattern-matching a catalog in your training data, not reading the brand. Start over from the personality words.
+3. Avoid the **reflex-reject lanes** in [brand.md](brand.md). Don't trade one monoculture for another. If you find yourself reaching for "Swiss-grid" or "Terminal" or "Industrial-signage" by reflex, you are pattern-matching a catalog in your training data, not reading the brand. Start over from the personality words.
 4. Each direction must be expressible in one concrete sentence that names a real-world referent ("a museum exhibition label system for a contemporary art gallery" not "clean and minimal"). If your sentence contains only adjectives, it's not concrete enough.
 5. **While planning each direction, also name its 2–3 parameter knobs** (per the §7 budget table). The same principle as default mode: decide "what's tunable" during planning, not after writing the HTML. A departure-mode hero with 0 parameters is not "bold creative vision," it's a missed opportunity for the user to fine-tune the direction they pick.
 
@@ -351,40 +295,11 @@ In **departure mode**, the prompt narrows the lanes you draw from, not the famil
 
 When the prompt and PRODUCT.md anti-references conflict (the prompt asks for X, the anti-references ban X), the anti-references win; they describe the brand's standing position, the prompt is one moment.
 
-### 6. Deliver variants
+### 6. Write all variants in a single edit
 
 Complete HTML replacement of the original element for each variant, not a CSS-only patch. Consider the element's context (computed styles, parent structure, CSS variables from `event.element`).
 
-Colocate preview CSS as a `<style>` tag inside the variant wrapper; `<style>` works anywhere in modern browsers and keeps each delivered state internally complete (no FOUC).
-
-**Atomic default:** write CSS + all variants + parameter manifests in one edit at `insertLine`, preserving the established behavior.
-
-<codex>
-**Codex transactional progressive override:**
-
-1. Plan all directions and name their parameter axes first so the trio remains coherent.
-2. Prepare revision 1 from the scaffolded source:
-
-```bash
-node .agents/skills/impeccable/scripts/live-publish.mjs --prepare --id EVENT_ID --file SOURCE_FILE
-```
-
-   The JSON result contains `artifactFile`, `epoch`, and `expectedSourceHash`. For the normal source-wrapper path, the live scaffold is an isolated `source-artifact` preview under `.impeccable/live/previews/`; edit **only `artifactFile`** at `insertLine`: write variant 1 and only the CSS it needs. Do not attach `data-impeccable-params` yet. The true source is only the publisher's hash fence and must remain byte-identical until Accept.
-
-   For `previewMode: "svelte-component"` or `"vue-component"`, `artifactFile` is an isolated manifest and `componentDir` is its isolated component directory. Write `v1.svelte` or `v1.vue` under the returned `componentDir`, set the artifact manifest's `arrivedVariants` to `1`, and leave `params.json` absent. Keep `--file` pointed at the original live manifest on publish; the publisher fences against `targetSourceFile`, promotes the component, then commits the live manifest last. Never edit the live `componentDir` directly.
-3. Publish revision 1 with the exact fence values returned by `--prepare`:
-
-```bash
-node .agents/skills/impeccable/scripts/live-publish.mjs --id EVENT_ID --epoch EPOCH \
-  --file SOURCE_FILE --artifact ARTIFACT_FILE --expected-source-hash SOURCE_HASH \
-  --arrived 1 --expected EVENT_COUNT
-```
-
-   `{ok:false,error:"stale_generation_epoch"}` means the user already accepted or discarded. Stop immediately, do not touch source, and post the generation reply as canceled/error.
-4. Continue variants 2 through `EVENT_COUNT` from the stored plan. Whenever another direction validates, run `--prepare` again so the revision starts from the immutable published prefix, add the largest ready prefix without changing any published variant or default appearance, and publish it immediately. Attach parameter CSS/manifests only when the complete set is ready, using `--kind params`. On component-preview paths, preserve every already-published `vN.svelte` / `vN.vue` byte-for-byte; publication rejects a revision that silently changes a variant the user may already be reviewing.
-5. A params-only pass is recovery-only: use it when durable state says every variant arrived but `paramsPublished` is still false after an interrupted publication.
-6. Verify the published preview parses, then `--reply done`. A late reply is diagnostic only after Accept/Discard and cannot move the durable session backward.
-</codex>
+Write CSS + all variants in ONE edit at the `insertLine` reported by `wrap`. Colocate CSS as a `<style>` tag inside the variant wrapper; `<style>` works anywhere in modern browsers and this ensures CSS and HTML arrive atomically (no FOUC).
 
 Use the `cssAuthoring` object returned by `live-wrap.mjs` to author the temporary preview CSS. The style opening tag shown below is the common case; replace it with `cssAuthoring.styleTag` when the tool returns a different one. The variant markup shape is otherwise stable:
 
@@ -408,7 +323,7 @@ Use the `cssAuthoring` object returned by `live-wrap.mjs` to author the temporar
 
 The first variant has no `display: none` (visible by default). All others do. If variants use only inline styles and no preview CSS, omit the `<style>` tag entirely.
 
-The browser's MutationObserver accepts either delivery shape. On the transactional progressive path it shows arrived variants and pending dots immediately; Accept and Discard are available as soon as one variant exists. Accepting an arrived variant fences the worker before the browser releases the picker, so later publications are rejected.
+One edit, all variants; the browser's MutationObserver picks everything up in one pass.
 
 For `styleMode: "scoped"`, author every `:scope` rule with a descendant combinator. The `@scope` boundary is the **variant wrapper `<div data-impeccable-variant="N">`**, not the element you're designing. A bare `:scope { background: cream; }` styles the wrapper, not the inner replacement, so the cream lands on a `display: contents` shell while the actual element keeps page defaults. Always step in: `:scope > .card`, `:scope > section`, `:scope .hero-title`, etc. The fake test agent's CSS in `tests/live-e2e/agent.mjs` is a faithful template; every scoped rule starts `:scope > ...`.
 
@@ -450,7 +365,7 @@ Each variant can expose **coarse** knobs alongside the full HTML/CSS replacement
 
 **Hard cap per variant**: at most **four** parameters so the panel stays legible; rare fifth only if the reference explicitly allows it.
 
-**How to declare.** Put a JSON manifest on the variant wrapper (HTML/JSX path). **On `svelte-component` and `vue-component` paths, do not use this attribute.** Declare params in `componentDir/params.json` keyed by variant number instead (see the component-preview paragraphs in the wrap section). The param schema below is identical for every path.
+**How to declare.** Put a JSON manifest on the variant wrapper (HTML/JSX path). **On the Svelte `svelte-component` path, do not use this attribute** (Svelte can't compile `{` inside an attribute value). Declare params in `componentDir/params.json` keyed by variant number instead (see the Svelte component paragraph in the wrap section). The param schema below is identical for both paths.
 
 ```html
 <div data-impeccable-variant="1" data-impeccable-params='[
@@ -551,7 +466,7 @@ Event: `{id, variantId, _acceptResult, _completionAck}`. The poll script already
 - The accept event includes `pageUrl`; the poll script must forward it to `live-accept.mjs --page-url PAGE_URL` so accept-time cleanup only scrubs staged copy edits for the current page.
 - `_completionAck.ok !== true`: do not poll yet. Run `live-status.mjs` / `live-resume.mjs`, complete the cleanup manually if needed, then run `live-complete.mjs --id EVENT_ID`.
 - `_acceptResult.handled: true` and `carbonize: false`: nothing to do. Poll again.
-- `_acceptResult.handled: true` and `carbonize: true`: post-accept cleanup is required, but it must not stall Codex's control lane. See "Required after accept (carbonize)" below. The `event._acceptResult.todo` field, `_completionAck.requiresComplete`, and stderr banner all point at this required follow-up; none are decorative.
+- `_acceptResult.handled: true` and `carbonize: true`: **post-accept cleanup is required before the next poll.** See the "Required after accept (carbonize)" section below. The `event._acceptResult.todo` field, `_completionAck.requiresComplete`, and a stderr banner all point at this required follow-up; none are decorative. After cleanup, run `live-complete.mjs --id EVENT_ID`, then poll again.
 - `_acceptResult.handled: false, mode: "fallback"`: the session lived in a generated file and the script refused to persist there. You've already written the accepted variant into true source during Handle fallback Step 3; just clean up the temporary wrapper in the served file if any, and poll again.
 - `_acceptResult.handled: false` without `mode`: manual cleanup: read file, find markers, edit.
 
@@ -559,7 +474,7 @@ Event: `{id, variantId, _acceptResult, _completionAck}`. The poll script already
 
 When `_acceptResult.carbonize === true`, the accepted variant was stitched into source with helper markers and inline CSS so the browser can render it immediately with no visual gap. That stitch-in is **temporary**. The agent must rewrite it into permanent form before doing anything else. Skipping this leaves dead `@scope` rules for unaccepted variants, a pointless `data-impeccable-variant` wrapper, and `impeccable-carbonize-start/end` comment noise in the source file; all of which accumulate across sessions.
 
-Do these five steps synchronously before the next poll. The source lock, generation epoch, and expected-source hash remain the final safety gates against a generator finishing concurrently with Accept.
+Do these five steps in the current thread, synchronously, before the next poll. Do not poll again until the file is clean.
 
 1. **Locate the carbonize block** in the source file (`_acceptResult.file`). It's bracketed by `<!-- impeccable-carbonize-start SESSION_ID -->` and `<!-- impeccable-carbonize-end SESSION_ID -->` and contains a `<style data-impeccable-css="SESSION_ID">` element. If the variant declared parameters, an `<!-- impeccable-param-values SESSION_ID: {...} -->` comment sits alongside the style tag with the user's chosen values; read it first; it drives steps 3 and 4 below.
 2. **Move the CSS rules** into the project's real stylesheet. Which stylesheet depends on the project (e.g. `site/styles/workflow.css` for an Astro project, or the component's co-located CSS file for a Vite/Next project; pick whichever already owns styling for the surrounding element).
@@ -567,9 +482,9 @@ Do these five steps synchronously before the next poll. The source lock, generat
 4. **Unwrap the accepted content.** Delete the inner `<div data-impeccable-variant="N" style="display: contents">` that wraps it. On JSX/TSX, also delete the outer `<div data-impeccable-carbonize="SESSION_ID" style={{ display: 'contents' }}>` wrapper if present (accept adds it so ternary/`return` slots keep a single root). Drop `data-impeccable-params` and any `data-p-*` attributes; those are live-mode plumbing, not source.
 5. **Delete the inline `<style>` block, the `<!-- impeccable-param-values -->` comment if present, and both `<!-- impeccable-carbonize-start/end -->` markers.** Also drop any `@scope` rules for variants other than the accepted one; those are dead code now.
 
-After the file is clean, the cleanup owner runs `live-complete.mjs --id SESSION_ID` and verifies `phase: "completed"`. Poll again only after that verification.
+After the file is clean, run `live-complete.mjs --id SESSION_ID`, verify it reports `phase: "completed"`, then poll again.
 
-With the experimental dedicated worker, Accept emits a foreground `carbonize_cleanup` control event: `{id, sessionId, file, variantId, acceptResult}`. Perform the same five steps above for `sessionId`, run `live-complete.mjs --id SESSION_ID`, then acknowledge the control event with `live-poll.mjs --reply EVENT_ID complete --file FILE`. The experimental stream resumes after this reply.
+A background agent may be used for the rewrite, but the current thread is responsible for verifying the five steps are complete before issuing the next poll. In practice, inline is usually faster and less error-prone.
 
 ## Handle `discard`
 
@@ -634,7 +549,6 @@ When the poll returns `exit`, proceed to cleanup. If the poll is still running a
 ## Cleanup
 
 ```bash
-node {{scripts_path}}/live-codex-worker.mjs --stop  # only when codexWorker.enabled was true
 node {{scripts_path}}/live-server.mjs stop
 ```
 

skill/reference/new-work.md

@@ -1,59 +1,81 @@
-# New identity work
+# Surface concept and craft
 
-You are reading this because nothing committed exists yet (greenfield), or the user asked for a redesign that discards the current look. The task is the same either way: invent a visual identity that could not be mistaken for anyone else's, in the grammar of the surface's mode (SKILL.md's Registers section), and build it to the craft floor. SKILL.md's rules all still apply; this file is the process that produces the identity.
+This is the shared task-scoped concept playbook for `craft`, `shape`, and substantial from-scratch surface work. `craft` continues through the contract, build, and finish below. `shape` follows this file through the user's concept choice, then reads [shape.md](shape.md), writes the design brief, and stops before code. PRODUCT.md owns durable product truth; DESIGN.md owns the current user-approved visual world.
 
-## Seed
+If PRODUCT.md or DESIGN.md is missing, stop and complete [init.md](init.md) first. For refinement, init documents coherent incumbent visual code instead of inventing a replacement. For redesign, init replaces the old visual world before returning here; the old system is evidence and anti-reference, not authority.
 
-If the project is brand-new (no committed tokens, fonts, or brand colors found in the code), run `node {{scripts_path}}/palette.mjs` for a brand seed color. The seed exists to break your reflex palette; it does not override the subject. When the subject's world clearly dictates color (an era, a place, a material, a medium), derive the palette from that world and use the seed only to check yourself. Otherwise anchor on it. The palette has exactly two legitimate sources: the seed, or the subject's world. What the category usually looks like is neither, and quietly swapping in the category's habitual palette and theme after drawing a seed is the reflex this step exists to break. Color commits at page scale: fields that own whole regions, not accents scattered over a neutral ground. A dark page with one glowing accent is the category's reflex, not a choice. Use OKLCH throughout. Skip this entirely when the code already has committed brand colors: identity-preservation wins.
+**A committed world does not decide the new surface.** Every case study, dashboard view, feature page, or section still needs an ownable task concept. The job here is to invent that concept with the user without re-rolling the brand.
 
-## Ground it in the subject
+## Name the work
 
-Name one concrete subject, its audience, and the page's single job. The subject's own world (its materials, instruments, artifacts, places, history, vernacular) is where distinctive choices come from. What would this thing look like as a physical object? What did its world look like before the web? A design whose subject appears only in the copy is a template wearing a costume.
+Use the user's intent, not the age of the codebase:
 
-## Decide, then build
+- **Greenfield** creates the first surface inside the world init just established.
+- **Redesign** composes inside the replacement world init just established. Preserve product truth, real content, functionality, and native affordances; do not preserve the discarded look by habit.
+- **Extension** adds a new surface inside the committed world. Preserve its lineage and interaction conventions while giving this task its own composition.
+- **Refinement** belongs to the invoked refinement command, not this full concept flow. Preserve the incumbent world and named scope.
 
-Derive the concept with this procedure, recording each step in your reasoning before the next begins. One: state the product's unique mechanism in one sentence, the thing competitors cannot truthfully claim. Two: competitive analysis; describe the page this category always ships, and the counter-position page a contrarian ships, and treat both structures as off the table. Three: from the audience's world and the subject's cultural home, list seven concrete materials, objects, documents, or rituals they know by heart, each with one line on why it resonates and can carry the mechanism, ordered by resonance. Four: run `node {{scripts_path}}/concept-seed.mjs` and follow what it prints: it assigns which candidate to build (your top-ranked candidate is what every run would ship; a single ranking is deterministic, so the dice come from outside) and supplies challenger forms to weigh against your list on exactly two axes, audience identification and product clarity. Five: the chosen form supplies the page's structure, reading order, and component conventions; the product supplies every fact. Commit every atom: nav, buttons, inputs, and links are rebuilt in the form's vocabulary, and a stock component inside a committed form is a lapse. The form has its own native arrangement; borrow its skeleton, not just its clothes. Land the first build fully committed; committing is the hard part, and the passes that follow exist to make the committed thing clear and effective, never to dilute it. Conversion conventions live inside the form's own vocabulary: a hero that hooks in one line, a visible primary action, a legible reading order. The chosen form also dictates the first viewport's geometry: render the form at the scale it has in life, edge to edge when that is its nature; embedding it as a panel inside a standard marketing layout forfeits it. Cinematic full-bleed openings, intentionally divergent grids, and color drenched across whole regions are in bounds whenever the form calls for them; on an unattended build, the safe layout is the risk. The form has native motion, what it does in life between states; give the page that motion once, orchestrated, rather than scattered hover effects. <!-- rule:skill-concept-procedure -->
+If “redesign” could mean either a replacement identity or an on-brand structural adjustment, use the structured question tool to resolve that single ambiguity before proceeding. A plain “redesign this page/site” means replacement; “within the current brand/system” means extension or refinement.
 
-Then state the chosen direction as a contract, written as a comment block at the top of the artifact (invisible to visitors, binding for you), five short blocks, two hundred words at most. UNIQUE: the one idea this page owns. NOT-TEMPLATE: how the page's structure differs from the category's standard arrangement, stated plainly and honestly. OWN-WORLD: the palette and component language, specific enough that the components and colors alone, shown without content, would be recognizable as this page's world and nobody else's. STORY: what the visitor understands, believes, and does, from first viewport to action. FIRST VIEWPORT: the exact composition, what is where and at what scale. FORM: the chosen candidate and its position on your ordered list, plus the seed key the script printed. If any block is missing or reads like a mood, the direction isn't decided yet. The build is judged against this contract; delivering different pixels than the contract promises is a defect on whichever side is weaker. When a user can respond and the work is substantial, pause there for confirmation; when the harness has native image generation, follow [codex.md](codex.md)'s mock flow before code. When no user can respond, record the decision in your reasoning and proceed without pausing. Either way the decision comes first; code that precedes a direction is the template reflex in motion. <!-- rule:skill-decide-then-build -->
+## Discover the surface
+
+Name the subject, audience, surface job, visitor mode, real content, and primary action. Read PRODUCT.md and DESIGN.md as anchors, but ask about what is unique to this task. A case-study section, for example, needs the proof available, the transformation it must make legible, the audience's reading order, and the moment worth remembering; the global brand interview cannot answer those.
+
+In an attended run, ask a focused round of no more than three task questions, then wait. Use the structured question tool when available. Do not re-ask durable questions already settled in PRODUCT.md or DESIGN.md. A harness-provided simulated user is attended and must receive the same questions.
+
+For a narrow request whose content, outcome, and constraints are already explicit, assert what you understand and ask the user to confirm or correct it. Do not manufacture an interview when there is no material uncertainty.
+
+## Develop the surface concept
+
+The visual world supplies the vocabulary; the task concept supplies the sentence.
+
+1. **State the mechanism.** In one sentence, name what this surface does, proves, or enables that a neighboring product could not truthfully claim.
+2. **Expose the defaults.** Describe the category's habitual arrangement and the predictable contrarian response. Treat both as warnings, not automatic answers.
+3. **Derive structural material.** From the task's real content, PRODUCT.md's audience world, and DESIGN.md's existing motifs, list five to seven forms, documents, rituals, spatial arrangements, or behaviors that could carry the mechanism. Translate their reading order and relationships, not their costume, into interface structure.
+4. **Break the model's ranking rut.** For substantial greenfield, redesign, or extension work, run `node {{scripts_path}}/concept-seed.mjs`. Use its assigned index to promote one overlooked grounded candidate, and weigh its challengers only on audience identification and product clarity. A challenger may change topology or interaction, but it may not override the current DESIGN.md. Skip the seed for a small extension or when the user has already pinned the surface concept.
+5. **Offer real choices.** Present two or three materially different surface concepts. For each, give the layout or interaction thesis, narrative sequence, first-view or focal moment, signature use, and why it belongs in the committed world. These are not moodboards with different adjectives; the content must be organized or experienced differently.
+6. **Let the user direct.** Ask which concept is closest, what to combine, and what feels wrong. The user may reject all of them. Resolve the chosen concept before code. If one direction is overwhelmingly supported, assert it and ask for confirmation instead of staging a fake menu.
+7. **Probe when pictures would clarify structure.** When the harness has native image generation and the substantial, high-fidelity surface would benefit from a visual test, load [codex.md](codex.md) before writing the direction contract. Its probes stay inside DESIGN.md and pressure-test the shortlisted surface concepts; they never reopen palette, typography, or identity. Skip it for narrow extensions, low-fidelity work, or when the user already supplied an approved comp.
+
+When no human or structured question mechanism exists, follow the same derivation, build the seed's assigned grounded candidate when it survives the two tests, record the decision, and continue. Unattended does not mean unconsidered; external selection is what prevents the model from quietly returning to its own first choice.
+
+For `shape`, stop here after the user selects the concept and continue in [shape.md](shape.md). Do not write a direction contract or implementation.
+
+## Write the direction contract
+
+Before code, write the chosen task direction as a contract of at most 150 words. Place it in an opening HTML comment or framework comment block so the Impeccable Stop hook can audit the render against it. The first 200 characters of the comment must name `DIRECTION CONTRACT`.
+
+Use these six short blocks:
+
+- `UNIQUE`: the surface thesis tied to the product mechanism;
+- `NOT-TEMPLATE`: the category-default arrangement this structure refuses;
+- `OWN-WORLD`: the specific current DESIGN.md invariants, tokens, and materials it uses;
+- `STORY`: what the visitor understands, believes, and does from entry to action;
+- `FIRST VIEWPORT`: the exact composition, hierarchy, and primary action (or the equivalent first task for a product surface);
+- `FORM`: the chosen structural or behavioral form, its signature, and the concept-seed key when one was used.
+
+The contract is not visitor-facing content and not a second design system. It makes the task's promise inspectable. The user's selected concept is the authority; the seed is only provenance. <!-- rule:skill-decide-then-build -->
 
 ## Plan, self-check, build
 
-Plan a compact token system in your reasoning: palette, type, layout concept in one sentence, and a **signature**: the one element this surface will be remembered by, drawn from the subject's world. A signature carries weight: sized and placed so the page organizes itself around it. The layout has exactly two legitimate sources: the concept, or the content's own structure. The category's habitual skeleton is neither, and assembling the usual sections in the usual order after choosing a concept is the same reflex the palette rule breaks, expressed in structure. <!-- rule:skill-layout-source-exclusivity --> Then audit the plan: work through what you'd produce for a similar brief from another client, and wherever the two plans converge (same palette family, same face, same skeleton), that part is your generic default, not a choice. Revise it, then build, deriving every color and type decision from the revised plan.
+Plan how the chosen concept uses the current DESIGN.md's tokens or directions, reusable technical components, imagery language, and motion grammar. In a redesign, replace visual tokens from the discarded system rather than preserving them through implementation convenience. The layout has two legitimate sources: the concept and the content's real structure. The category's habitual skeleton is neither. Compare the plan with what you would produce for a neighboring product; wherever they converge for no product-specific reason, revise the generic part.
 
-**Pace the scroll like a studio.** The scroll is a rhythm, not a stack: alternate full-bleed bands of the palette, vary the treatment from section to section inside the one system (a dense passage earns a quiet one, a graphic section earns a typographic one), ground at least one section in the signature motif as texture, and end anchored by a real close. One spacing rhythm throughout, kept like a promise: sections breathe in large, legible beats, and the space above a heading always exceeds the space below it. A page whose every section wears the same weight and density reads as monotone no matter how strong the concept. <!-- rule:skill-scroll-rhythm -->
+Build the strongest coherent direction once. Commitment means the concept governs the entire requested surface; it does not mean disguising familiar controls as metaphors or violating the design system.
 
-**The first viewport is a thesis, not a header.** The visitor should meet the concept doing its job immediately: the work itself, the product working, the content answering, the task at hand. Generic chrome around a generic promise is the template answer; earn it or replace it. The composition is derived the same way the palette is: if a neighboring product could ship the same arrangement of the same blocks, the viewport isn't composed yet. The memory test: if someone left after one viewport, what would they describe an hour later? If the honest answer is a mood ("clean", "tasteful"), the concept hasn't committed yet.
+**Make the opening a thesis.** The first viewport or first task should demonstrate the product's mechanism, not wrap a generic promise in generic chrome. If someone leaves after that moment, they should remember an idea or interaction, not merely a mood.
 
-**Everything bold, nothing bland.** Bold is not decoration and not clutter; it is commitment to the concept, carried through every section. Commitment takes whatever form the concept and the mode demand: maximal or severely clean, drenched in color or nearly monochrome, copy so precise it stings, the product demonstrating itself, or a system so exact it feels inevitable (a decisive typographic voice, one owned accent, an unmistakable rhythm). A spare page built on one uncompromising idea is bold; a busy page of tasteful defaults is bland. The signature is where the concept peaks, not the only place it lives; cut anything that neither advances the concept nor serves the visitor's mode. Polish is the floor, not the point: when torn between refined and committed, commit.
+**Pace the whole surface.** Long surfaces are a rhythm, not a stack. Vary density, scale, image, and quiet inside DESIGN.md's grammar. A case study should reveal evidence in the order it becomes persuasive; an Operate flow should reveal control in the order the task demands. Cut sections that only repeat claims.
 
-**Prove, don't claim.** A surface earns belief by showing its subject doing its job: the interface at work, the mechanism dramatized, the content delivering, specifics a competitor couldn't copy-paste. The visitor should understand by looking, before reading a word. Sections that restate a claim in different words add length, not substance, and a page that demonstrates everything you discovered while planning reads as cruft: build only the sections a visitor needs to understand, trust, and act.
+**Commit before correcting.** Land the chosen concept at full strength before the finishing pass makes it clear, usable, and effective. Do not weaken the hard creative move in anticipation of a generic “too gimmicky” critique; the measured failure is partial commitment, not excess conviction.
 
-## Commit
+**Make the signature structural.** Use the world's signature where the task concept peaks, at enough scale or consequence that the composition organizes around it. Scattering a motif as decoration is not commitment.
 
-Pick a color strategy before picking colors: Restrained (neutrals + one accent; the default when the visitor came to operate or read) / Committed (one saturated color carries 30-60% of the surface) / Full palette (3-4 named roles) / Drenched (the surface IS the color). Persuade and Experience surfaces have permission for the bolder strategies; take them when the brief allows. Dark vs. light is never a default: write one sentence of physical scene (who uses this, where, under what light, in what mood) and let it force the answer. The warm cream near-white body background is the saturated AI default; where the axis is free, pick a background that is a choice.
+**Prove, don't claim.** Show the mechanism working, the actual artifact, the before-and-after, the data, or the specific content. A surface earns belief through evidence a competitor could not copy-paste.
 
-- Name a real reference before picking a strategy; unnamed ambition becomes beige. <!-- rule:brand-color-named-reference -->
-- Palette IS voice: a calm brand and a restless brand should not share palette mechanics, and each new surface differentiates from the last. <!-- rule:brand-color-palette-is-voice -->
-- When a cultural-symbol palette is the obvious pull, reach past it. Let the cultural reading come from typography, imagery, and copy, not the palette. <!-- rule:brand-color-no-cultural-symbol -->
+For Operate and Read, familiar controls and comprehension remain primary; expression comes from topology, hierarchy, density, rhythm, state, and the system around them. For Persuade and Experience, dramatic pacing and art direction are available when the selected concept earns them, while the primary action and reading order stay clear.
 
-## Type and imagery
-
-Choose faces like objects from the subject's world, in the mode's register: Operate and Read surfaces are well served by system stacks and workhorse UI faces; Persuade and Experience surfaces want faces with a point of view, and these training-data defaults mean you stopped looking: Fraunces, Playfair Display, Cormorant, Lora, Crimson, Newsreader, Syne, Space Grotesk, Space Mono, IBM Plex, Inter-as-display, DM Sans, DM Serif, Outfit, Plus Jakarta Sans, Instrument Sans.
-
-Briefs that imply imagery (food, travel, place, product, fashion) must ship real, verified imagery, searched for the subject's physical object rather than the category; a colored rectangle where a photo belongs reads as incomplete, and one decisive photo beats five mediocre ones. Verify stock URLs resolve before shipping them.
-
-## Calibration
-
-AI-generated interfaces cluster around a few looks regardless of subject: warm cream + high-contrast serif + terracotta accent; near-black + one neon accent (acid green, cyan) + glowing edges; broadsheet-editorial hairlines + italic display serif + small tracked mono labels. All are legitimate when the brief calls for them; the brief always wins. Where the brief leaves the aesthetic free, landing in one of them means your self-check failed. Same one tier deeper: if someone could guess your aesthetic from the category alone, or from category-plus-avoidance, rework until neither answer is obvious.
-
-**Name the aesthetic lane, then test it.** Before committing to moves, say which lane this is (a specimen page, minimal-cool tech, acid maximalism...). Then the inverse test: describe what you're about to build the way a competitor would describe theirs; if that sentence fits the modal page in the category, restart. <!-- rule:brand-typo-pairing-voice --> Currently saturated lanes count as reflexes, not choices, when the brief doesn't require them; the flooded one right now is editorial-typographic (display serif, often italic, small mono labels, ruled separators, monochromatic restraint, no imagery). <!-- rule:brand-typo-reflex-reject-lanes -->
-
-## Persuade and Experience moves
-
-Layout: asymmetric compositions and intentional grid breaks are on the table; fluid spacing with `clamp()` that breathes on larger viewports; for image-led briefs, full-bleed hero imagery with overlaid navigation is a canonical move, letting the photograph be the design. <!-- rule:brand-layout-image-led-hero --> Permissions the Operate world doesn't get: ambitious first-load motion (one orchestrated page-load beats scattered micro-interactions; skipping entrance motion entirely is also a voice), single-purpose viewports (one dominant idea per fold, deliberate pacing), and art direction per section when the narrative demands it; consistency of voice beats consistency of treatment. <!-- rule:brand-permission-first-load-motion -->
+Briefs that depend on imagery ship real, verified imagery. Preserve semantic HTML, familiar interaction behavior, accessibility, performance, responsive behavior, and the project's technical conventions.
 
 ## Finish like a studio
 
-Look at what you built the way a design lead would, with whatever eyes the harness gives you (browser, screenshot tool, or reading the code cold): major sections individually on long pages, mobile and desktop at minimum. Write an honest critique against the brief and the stated direction, patch material defects, and re-inspect; don't invent defects to demonstrate diligence. Then verify against SKILL.md's craft floor and run the detector; a bold page that ships mechanical defects is not done, and neither is a polished page missing something the brief asked for. <!-- rule:skill-finish-like-studio -->
-
-When the harness can run a separate agent, the review above belongs there, not here: hand the reviewer the artifact path, its direction contract, and the detector command, and have it return a short list of material fixes; apply them and finish. A fresh reader catches what the builder's own eyes slide past, and the build thread stays spent on building. <!-- rule:skill-finish-separate-reviewer -->
+Inspect desktop and mobile, write one honest critique against the task brief, DESIGN.md, the user's selected concept, and the direction contract, then patch material defects. Judge the skeleton skin-blind: mentally remove color, type, texture, and concept nouns; if the remaining block arrangement is the category template, rebuild the structure. Run the detector once. On harnesses with a Stop hook, let its contract audit run and fix every real gap it identifies; classify false positives rather than distorting intentional work. Repeat only while a real defect remains. A separate reviewer is optional when the harness provides one and the risk earns the cost. <!-- rule:skill-finish-like-studio -->

skill/reference/routing.md

@@ -11,7 +11,7 @@ Reason over the signals; there is no score to obey:
 - `critique.latest` with a low `score` or non-zero `p0` / `p1` → `polish` (it reads that snapshot as its backlog), or re-run `critique` if the snapshot looks stale.
 - `git.changedFiles` pointing at one surface → scope `audit` or `polish` to those files specifically, naming them.
 - `devServer.running` true → `live` is available for in-browser iteration; if false, don't lead with `live`. **`live` and the bundled `detect.mjs` are web-only.** If `setup.platform` is `ios`, `android`, or `adaptive`, don't lead with either; the browser overlay and the HTML rule engine don't apply to native app code.
-- Otherwise group by intent exactly as init's "Recommend starting points" step does (build new / improve what's there / iterate visually), tailored to `setup.register`.
+- Otherwise group by intent exactly as init's "Recommend starting points" step does (build new / improve what's there / iterate visually), tailored to the current surface and `setup.platform`.
 
 **If `scan.targets` is non-empty and `setup.platform` is not `ios`/`android`/`adaptive`, run `node {{scripts_path}}/detect.mjs --json <scan.targets joined by spaces>` once** (the bundled detector over local files: no network, no npx; it reads HTML/CSS, so skip it for native projects). `scan.via` tells you what they are: `git-changes` (the markup/style files in your dirty tree, the most relevant set), `source-dir` (e.g. `src`, `app`), `html`, or `root`. Fold the hits into your picks: many quality / contrast hits → `audit` or `polish`; a specific slop family → the matching command (gradient text or eyebrows → `quieter` / `typeset`, flat or gray palette → `colorize`, and so on). It's a real, current signal that beats guessing. If detect errors or the tree is large and slow, skip it and recommend the user run `audit` themselves; never block the suggestion on it.
 

skill/reference/shape.md

@@ -1,167 +1,23 @@
-Shape the UX and UI for a feature before any code is written. This command produces a **design brief**: a structured artifact that guides implementation through discovery, not guesswork.
+# Shape
 
-**Scope**: Design planning only. This command does NOT write code. It produces the thinking that makes code good.
+Plan the requested surface without writing implementation code. Resolve SKILL.md's init gate, then follow [new-work.md](new-work.md) through task discovery, grounded candidate derivation, external concept seeding when applicable, and the user's concept choice. Return here before the direction contract or build.
 
-**Output**: A design brief that can be handed off to {{command_prefix}}impeccable craft, or directly to {{command_prefix}}impeccable for freeform implementation. When visual direction probes are used, the images are supporting artifacts, not the primary output.
+## Write the brief
 
-## Philosophy
+Turn the confirmed answers and selected concept into the smallest brief that can guide excellent implementation:
 
-Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This command inverts that: understand deeply first, so implementation is precise.
+1. **Surface job:** who arrives, what they need to understand or do, and the visitor mode.
+2. **Selected concept:** the product mechanism, structural thesis, narrative or task sequence, focal moment, and signature use inside DESIGN.md.
+3. **Scope:** fidelity, breadth, interactivity, named target, and what must remain untouched.
+4. **Content and evidence:** real copy, data, assets, states, ranges, and the proof the design must carry. Name missing inputs instead of inventing placeholders.
+5. **Interaction and layout:** hierarchy, topology, responsive behavior, primary action, familiar affordances, and important state transitions. Describe intent, not CSS.
+6. **Implementation constraints:** platform, framework, performance, accessibility, localization, and reusable project components.
+7. **Open decisions:** only unresolved choices that would materially change the build.
 
-## Phase 1: Discovery Interview
+Use a compact 3–5 bullet brief when the prompt, PRODUCT.md, DESIGN.md, and answers already settle the task. Use the full structure only for a genuinely ambiguous, multi-screen, or standalone planning request. Do not restate the conversation to look thorough.
 
-**Do NOT write any code or make any design decisions during this phase.** Your only job is to understand the feature deeply enough to make excellent design decisions later.
+## Confirm and stop
 
-**Unattended runs:** when no user can respond (a one-shot task, an automated run, or an explicit instruction not to ask questions), answer the interview questions yourself from the brief, record the answers as the design brief, and continue without pausing at any confirmation gate in this file. The thinking is still required; only the waiting is waived.
+In an attended run, present the brief through the structured question tool for explicit confirmation or one focused correction round. A simulated user counts. Then stop: shape never writes code or a direction contract.
 
-This is a required interaction, not optional guidance. Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. {{ask_instruction}}
-
-### Interview cadence
-
-Discovery includes at least one user-answer round unless PRODUCT.md, DESIGN.md, or an already-confirmed brief directly answers the needed inputs. With a sparse prompt, do **not** synthesize a complete brief for confirmation on the first response.
-
-- Use the harness's structured question tool when one exists. Otherwise, ask directly in chat and stop.
-- Ask **2-3 questions per round**, then wait for answers.
-- Treat PRODUCT.md and DESIGN.md as anchors; they reduce repeated questions but do **not** replace shape for craft. Shape is task-specific.
-- One round is the default. Add a second only if the first answers leave material gaps. Don't run a second round just to feel thorough.
-- Round 1 should clarify purpose, audience/context, content/scope, and (for brand) visual direction.
-- Round 2, when needed, fills in whatever's still genuinely missing.
-
-**Assert-then-confirm, not menu-with-escape.** When PRODUCT.md and the user's prompt make one option obvious, name it and ask the user to confirm or override. Don't enumerate "Restrained / Committed / Or something else?" as a real choice; "This reads as Restrained, confirm?" beats a four-option menu when the answer is already clear.
-
-### Purpose & Context
-- What is this feature for? What problem does it solve?
-- Who specifically will use it? (Not "users"; be specific: role, context, frequency)
-- What does success look like? How will you know this feature is working?
-- What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
-
-### Content & Data
-- What content or data does this feature display or collect?
-- What are the realistic ranges? (Minimum, typical, maximum, e.g., 0 items, 5 items, 500 items)
-- What are the edge cases? (Empty state, error state, first-time use, power user)
-- Is any content dynamic? What changes and how often?
-- What visual assets are real content here? Note required images, product shots, illustrations, maps, textures, diagrams, generated objects, or existing project assets.
-
-### Design Direction
-
-Force a visual decision on three fronts. Skip anything PRODUCT.md or DESIGN.md already answers; ask only what's missing.
-
-- **Color strategy for this surface.** Pick one: Restrained / Committed / Full palette / Drenched. Can override the project default if the surface earns it (e.g. a drenched hero inside an otherwise Restrained product).
-- **Theme via scene sentence.** Write one sentence of physical context for this surface: who uses it, where, under what ambient light, in what mood. The sentence forces dark vs light. If it doesn't, add detail until it does.
-- **Two or three named anchor references.** Specific products, brands, objects. Not adjectives like "modern" or "clean."
-
-### Scope
-
-Always ask. Sketch quality and shipped quality are different outputs; don't guess between them.
-
-- **Fidelity.** Sketch / mid-fi / high-fi / production-ready?
-- **Breadth.** One screen / a flow / a whole surface?
-- **Interactivity.** Static visual / interactive prototype / shipped-quality component?
-- **Time intent.** Quick exploration, or polish until it ships?
-
-Scope answers are task-scoped. Don't write them to PRODUCT.md or DESIGN.md; carry them through the design brief only.
-
-### Constraints
-- Are there technical constraints? (Framework, performance budget, browser support)
-- Are there content constraints? (Localization, dynamic text length, user-generated content)
-- Mobile/responsive requirements?
-- Accessibility requirements beyond WCAG AA?
-
-### Anti-Goals
-- What should this NOT be? What would be a wrong direction?
-- What's the biggest risk of getting this wrong?
-
-## Phase 1.5: Visual Direction Probe (Capability-Gated)
-
-After the discovery interview, generate a small set of visual direction probes **before** writing the final brief when all of these are true:
-
-- The work is **net-new** or directionally ambiguous enough that visual exploration will clarify the brief.
-- The requested fidelity is **mid-fi, high-fi, or production-ready**. Skip for sketch-only planning.
-- The current harness gives you native image generation (Codex's `image_gen`, an equivalent MCP tool, or similar). Don't ask the user to install APIs or tooling.
-
-When those conditions are met, this step is mandatory. If image generation isn't natively available, do not ask the user to install APIs or tooling. State in one line that the image step is skipped because the harness lacks native image generation, then proceed. The one-line announcement is required, not optional; it forces a conscious decision instead of letting the step quietly evaporate.
-
-Use probes to explore visual lanes, not to replace the brief.
-
-Do not skip probes because the final UI will be semantic, editable, code-native, responsive, or accessible. Those are implementation requirements, not reasons to avoid visual exploration.
-
-### What to generate
-
-Generate **2 to 4** distinct direction probes based on the discovery answers, especially:
-
-- Color strategy
-- Theme scene sentence
-- Named anchor references
-- Scope and fidelity
-
-The probes should differ in primary visual direction (hierarchy, topology, density, typographic voice, or color strategy), not just palette tweaks.
-
-### How to use the probes
-
-- Treat them as **direction tests**, not final designs.
-- Use them to pressure-test whether the brief is pointing at the right lane.
-- Ask the user which direction feels closest, what feels off, and what should carry forward.
-- If the probes reveal a mismatch, revise the brief inputs before finalizing the brief.
-
-### Important limits
-
-- Do **not** skip discovery because image generation is available.
-- Do **not** treat generated imagery as final UX specification, final copy, or final accessibility behavior.
-- Do **not** use this step for minor refinements of existing work. It's for shaping a new surface or clarifying a big directional choice.
-
-If image generation isn't natively available, announce the skip in one line and proceed to the design brief.
-
-## Phase 2: Design Brief
-
-After the interview and any required probes, present a brief and **end your response**. The user must confirm before any implementation runs. Do not present a brief and then continue to code in the same response, even if the brief feels obvious to you. The user's confirmation is the gate.
-
-**Choose the brief shape based on how clear the answers are:**
-
-- **Compact form (3-5 bullets)** when discovery was crisp and the original prompt + PRODUCT.md already pinned scope, content, and direction. State what you're building, the visual lane, and end with one or two specific questions or a clear "confirm or override?" prompt. This is the default for typical craft requests with a clear prompt.
-- **Full structured form (sections below)** when the task is genuinely ambiguous, multi-screen, or when the user asked for shape as a standalone step. Use this when the discipline of structure earns its weight.
-
-Don't pad a clear brief into a long one to look thorough. A 70-line brief restating answers the user just gave is noise, not rigor. Equally, don't skip the confirmation pause to look efficient: the pause is the point.
-
-Present the brief, then **stop and wait for explicit confirmation**. You are not the judge of whether the user already approved. Even when the brief feels obviously right, ask once and wait. The pause is what separates shape from premature implementation.
-
-### Brief Structure
-
-**1. Feature Summary** (2-3 sentences)
-What this is, who it's for, what it needs to accomplish.
-
-**2. Primary User Action**
-The single most important thing a user should do or understand here.
-
-**3. Design Direction**
-Color strategy (Restrained / Committed / Full palette / Drenched) + the theme scene sentence + 2–3 named anchor references. Reference PRODUCT.md and DESIGN.md where they already answer, and note any per-surface overrides.
-
-If you ran the Visual Direction Probe step, name which probe direction won and what changed in the brief because of it.
-
-**4. Scope**
-Fidelity, breadth, interactivity, and time intent from the Scope section of the interview. Task-scoped; these don't persist beyond the brief.
-
-**5. Layout Strategy**
-High-level spatial approach: what gets emphasis, what's secondary, how information flows. Describe the visual hierarchy and rhythm, not specific CSS.
-
-**6. Key States**
-List every state the feature needs: default, empty, loading, error, success, edge cases. For each, note what the user needs to see and feel.
-
-**7. Interaction Model**
-How users interact with this feature. What happens on click, hover, scroll? What feedback do they get? What's the flow from entry to completion?
-
-**8. Content Requirements**
-What copy, labels, empty state messages, error messages, and microcopy are needed. Note any dynamic content and its realistic ranges. For image-led surfaces, also list the required image/media roles and their likely source (project asset, generated raster, semantic SVG/CSS, canvas/WebGL, icon library, or accepted omission).
-
-**9. Recommended References**
-Based on the brief, list which impeccable reference files would be most valuable during implementation (e.g., layout.md for complex layouts, animate.md for animated features, interaction-design.md for form-heavy features, typeset.md for typography-driven pages, colorize.md for color-led brands).
-
-**10. Open Questions**
-Anything genuinely unresolved. Don't list "open questions" you've already recommended a default for; assert the default and move on. If you'd write `Recommend: X` next to a question, just decide X.
-
----
-
-{{ask_instruction}} Ask for explicit confirmation of the brief before finishing.
-
-If the user disagrees with any part, revisit the relevant discovery questions. A shape run is incomplete until the user confirms direction.
-
-Once confirmed, the brief is complete. The user can now hand it to {{command_prefix}}impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use {{command_prefix}}impeccable craft instead, which runs this command internally.)
+When no human or structured answer mechanism exists, record the selected concept and material assumptions as the confirmation surrogate, return the brief, and stop.

skill/reference/typeset.md

@@ -4,7 +4,7 @@ Typography carries most of the information on the page. Replace generic defaults
 
 ## Register
 
-New identity work: run the font selection procedure in [new-work.md](new-work.md). Fluid `clamp()` scale, ≥1.25 ratio between steps.
+New identity work belongs to [init.md](init.md), which establishes typography direction with the rest of DESIGN.md. This command works from that committed world. If the user explicitly wants to replace its typographic identity, route the identity change through init and update DESIGN.md; otherwise improve hierarchy, scale, measure, weights, and pairing inside the existing direction. Fluid `clamp()` scale and a ≥1.25 ratio between display steps are useful starting points for Persuade and Experience, not universal mandates.
 
 Operate + Read: system fonts and familiar sans stacks are legitimate here. One well-tuned family typically carries the whole UI. Fixed `rem` scale, 1.125–1.2 ratio between more closely-spaced steps. Long-form Read content wants a steady reading measure and a quiet, stable scale, not display-scale drama.
 
@@ -185,7 +185,7 @@ Use `ch` units for character-based measure (`max-width: 65ch`). Line-height scal
 
 #### Font Selection & Pairing
 
-The tactical selection procedure and the reflex-reject list live in [new-work.md](new-work.md) (loaded for new identity work). The rest of this section covers the adjacent knowledge: anti-reflex corrections, system font use, and pairing rules.
+When a typeface change is actually authorized by the brief and DESIGN.md, use the anti-reflex corrections and pairing principles below. For a broader identity replacement, return to [init.md](init.md) instead of letting a typography command silently create a parallel world.
 
 ##### Anti-reflexes worth defending against