mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-12 22:26:38 +03:00
Paul BakausandClaude Fable 5
2c62f0f4f9
Fix batch from the visitor-mode bias audit. The skill's four modes (Persuade / Operate / Read / Experience) now reach the places that were still hard-coded to a SaaS-marketing default: - palette.mjs: rewrote 45 seed blurbs in material/world terms. The 29 tech-tool-world moods (13 Linear-indigo variants, 6 Figma-era, 5 climate-tech, 3 fintech, 2 Glossier DTC, incl. seed-201's docs-page CTA red) lose all company names and product-category words; Aesop trimmed from 17 blurbs to 4 and Klim from 7 to 4, excess rewritten as unnamed material terms. Also carries the earlier bg-block rewrite (brand refs out of the composition doc). - init.md: register explainer now names the four modes and the family each belongs to (stored value stays brand/product for compatibility); Conversion & proof interview + PRODUCT.md section gated to Persuade surfaces only (Experience/Read get no CTA/belief-ladder/proof). - critique.md: Nielsen heuristics 7 and 10 may score n/a on Persuade and Experience surfaces, total renormalized to the applicable max, snapshot records which were n/a; working-memory examples diversified beyond dashboard/pricing anatomy. - Register headers in bolder/delight/quieter/colorize/layout/animate/ typeset renamed from Brand:/Product: to Persuade + Experience: / Operate + Read:; typeset and layout gain one Read-specific sentence (steady reading measure; navigable linearity). - animate.md: plan checklist and implementation order lead with feedback and transitions; the single entrance moment comes after, scoped to modes that invite it. - codex.md: mock inventory says "primary-action treatment (when the surface has one)" instead of assuming a CTA. - delight.md: loading/empty-state/console-egg examples diversified beyond SaaS; streaks/badges scoped to Operate surfaces with recurring tasks. - distill.md: step-removal and next-action lines neutralized away from signup/checkout/CTA vocabulary. - document.md: canonical button label GET STARTED -> SAVE CHANGES; signature components gain a non-marketing example. - antipatterns registry: single-font rule renamed to "Single font without hierarchy" with a description that permits one family when weight/size contrast carries hierarchy. Staged provider copies regenerated via build:skills:release for the touched files only. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
106 lines
6.9 KiB
Markdown
106 lines
6.9 KiB
Markdown
# Codex: Visual Direction & 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.
|
|
|
|
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.
|
|
|
|
### Four stop points before code
|
|
|
|
Steps A through D each end with the user. Do not advance past any of them on your own read of the situation.
|
|
|
|
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 craft.md Step 4 and write code.
|
|
|
|
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.
|
|
|
|
## Step A: Explore Directions with the User
|
|
|
|
Before generating anything, run a brief direction conversation grounded in the shape brief.
|
|
|
|
**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.
|
|
|
|
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:
|
|
|
|
- "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.)"
|
|
|
|
**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.
|
|
|
|
## Step B: Generate the Brand Palette First
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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?"
|
|
|
|
**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 craft.md Step 4 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 `craft.md` Step 5 (Build to Production Quality). The implementation builds against the confirmed palette, approved mock, and the assets the producer wrote.
|