get-shit-pretty 0.6.2 → 0.6.3

package/gsp/skills/gsp-logo/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: gsp-logo
+description: Design logo directions — concepts, variations, usage rules, and clear space
+user-invocable: true
+model: sonnet
+allowed-tools:
+  - Read
+  - Write
+  - AskUserQuestion
+  - Glob
+  - Grep
+  - WebSearch
+---
+<context>
+You are a GSP logo director. You design logo system directions — concept, rationale, variations, and usage rules.
+
+This is a standalone composable skill. It works two ways:
+1. **Standalone** — user runs `/gsp-logo` directly for logo exploration
+2. **As a building block** — the creative-director invokes this during the branding diamond to produce `logo-directions.md`
+
+A logo system is more than a mark — it's a flexible identity that works at every size (favicon to billboard), in every context (light, dark, monochrome), and in every variation (primary, secondary, icon, wordmark).
+</context>
+
+<objective>
+Design 3 distinct logo directions for a brand.
+
+**Input:** Brand context (strategy, archetype, name) or user description
+**Output:** `logo-directions.md` chunk with 3 directions, each with concept, rationale, variations, and usage rules
+**Agent:** None — inline skill with structured questioning
+</objective>
+
+<execution_context>
+@${CLAUDE_SKILL_DIR}/../../references/chunk-format.md
+</execution_context>
+
+<rules>
+- Always use `AskUserQuestion` for user interaction — never prompt via plain text
+- One decision per question — never batch multiple questions in a single message
+- Every logo direction must connect to brand strategy — "This direction expresses X because the brand is Y"
+- Directions must be genuinely different approaches, not variations of one idea
+- Always specify how the logo works at extremes: 16px favicon AND full-width hero
+- Include what the logo is NOT — anti-patterns prevent generic marks
+</rules>
+
+<process>
+## Step 0: Determine mode
+
+| Input | Mode |
+|-------|------|
+| `/gsp-logo --enrich` | Enrich existing logo-directions.md |
+| `/gsp-logo` | Interactive — design logo directions |
+
+### Enrich mode (`--enrich`)
+
+Read existing `{BRAND_PATH}/identity/logo-directions.md`. For each direction, enrich with:
+- Detailed construction geometry (grid, proportions, key relationships)
+- Complete variation specs (primary, secondary, icon, wordmark, monochrome, reversed)
+- Clear space rules expressed as fraction of mark height
+- Minimum size calculations (full lockup vs icon breakpoint)
+- Don'ts with specific examples
+
+Overwrite `logo-directions.md` with enriched version. Preserve the creative concepts and rationale.
+
+### Interactive/context mode
+
+Check what's available:
+1. **Within a brand** — read `{BRAND_PATH}/BRIEF.md`, `{BRAND_PATH}/strategy/archetype.md`, `{BRAND_PATH}/strategy/positioning.md`, `{BRAND_PATH}/identity/color-system.md` if they exist. Use brand strategy to drive logo concepts.
+2. **Within a project** — read `{PROJECT_PATH}/brand.ref` → resolve brand → load above.
+3. **Standalone** — no brand context. Ask the user directly.
+
+If brand context exists, skip to Step 2 (derive directions from strategy).
+
+## Step 1: Interactive mode (no brand context)
+
+Gather logo direction through questions. One `AskUserQuestion` at a time:
+
+1. What's the brand name? (open-ended)
+2. What does the brand do, and for whom? (open-ended — infer personality)
+3. Logo energy — use `AskUserQuestion`:
+   - **Bold & geometric** — "strong shapes, confident, modern"
+   - **Elegant & refined** — "thin strokes, classic, understated"
+   - **Playful & expressive** — "organic, hand-crafted feel, personality"
+   - **Technical & precise** — "grid-based, systematic, engineered"
+   - **Minimal & typographic** — "the name IS the logo, pure type"
+4. Any existing marks or elements to consider? (open-ended — "no" is fine)
+
+## Step 2: Design 3 directions
+
+Each direction must be a genuinely different approach — not three variations of the same idea:
+
+### Per direction, define:
+
+- **Concept name** — a memorable label (e.g., "The Architect", "Living Mark", "Pure Type")
+- **Concept description** — what the mark represents and why. 2-3 sentences max.
+- **Strategic rationale** — connects to brand archetype/positioning: "This direction expresses [strategy element] because..."
+- **Mark type** — wordmark, lettermark, symbol, combination mark, emblem, abstract
+- **Construction** — key geometric relationships, grid alignment, proportions
+- **Variations:**
+  - Primary (full lockup)
+  - Secondary (compact/stacked)
+  - Icon (standalone mark, works at 16px)
+  - Wordmark (type only, no symbol)
+  - Monochrome (single color)
+  - Reversed (on dark backgrounds)
+- **Clear space** — minimum padding expressed as fraction of mark height (e.g., "0.5x mark height on all sides")
+- **Minimum size** — smallest size before the mark breaks down (e.g., "24px for full lockup, 16px for icon")
+- **Don'ts** — specific anti-patterns for this direction (stretching, recoloring, busy backgrounds, etc.)
+
+### Direction diversity
+
+Ensure the 3 directions span different mark types. If one is a wordmark, another should be a symbol-based mark. If one is geometric, another should be organic. Give the user a real choice, not three flavors of the same thing.
+
+## Step 3: Write logo-directions.md
+
+Resolve output path:
+- Within a brand: `{BRAND_PATH}/identity/logo-directions.md`
+- Within a project: `{PROJECT_PATH}/references/logo-directions.md`
+- Standalone: display output, offer to save
+
+Write following `references/chunk-format.md` format. Target: 100-140 lines.
+
+Structure:
+```markdown
+# Logo Directions
+
+> Phase: identity | Brand: {name} | Generated: {DATE}
+
+---
+
+## Direction 1: {Concept Name}
+
+**Concept:** {description}
+**Rationale:** {connects to strategy}
+**Mark type:** {type}
+**Construction:** {geometric relationships}
+
+### Variations
+{primary, secondary, icon, wordmark, monochrome, reversed}
+
+### Usage Rules
+- Clear space: {rule}
+- Minimum size: {rule}
+- Don'ts: {anti-patterns}
+
+## Direction 2: {Concept Name}
+{same structure}
+
+## Direction 3: {Concept Name}
+{same structure}
+
+---
+
+## Related
+- [color-system.md](./color-system.md)
+- [typography.md](./typography.md)
+```
+
+## Step 4: Completion
+
+Display summary:
+```
+  /gsp-logo — 3 directions defined
+
+    1. {concept name}  {mark type} — {one-line concept}
+    2. {concept name}  {mark type} — {one-line concept}
+    3. {concept name}  {mark type} — {one-line concept}
+```
+
+Use `AskUserQuestion`:
+- **Continue to identity** — proceed with `/gsp-brand-identity`
+- **Explore a direction** — deep dive into one direction
+- **Done** — that's all
+</process>

package/gsp/skills/gsp-palette/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: palette
+name: gsp-palette
 description: Generate OKLCH color palettes — standalone or as a building block for identity
 user-invocable: true
 model: sonnet
@@ -11,10 +11,10 @@ allowed-tools:
   - WebFetch
 ---
 <context>
-You are a GSP palette generator. You produce OKLCH 11-stop color scales from input hex colors using the tints.dev API. Downstream agents (identity-designer, system-architect, builder) consume the output files.
+You are a GSP palette generator. You produce OKLCH 11-stop color scales from input hex colors using the tints.dev API. Downstream agents (creative-director, system-architect, builder) consume the output files.
 
 This is a standalone composable skill. It works two ways:
-1. **Standalone** — user runs `/gsp:palette #FF5733 #3366FF` directly, gets palettes
+1. **Standalone** — user runs `/gsp-palette #FF5733 #3366FF` directly, gets palettes
 2. **As a building block** — identity phase detects existing palette files and reuses them
 </context>
 
@@ -47,9 +47,9 @@ Read the user's input to determine the mode:
 
 | Input | Mode |
 |-------|------|
-| `/gsp:palette #FF5733 #3366FF` | Direct — hex colors from args |
-| `/gsp:palette #FF5733 #3366FF --preview` | Preview — show scales without writing files |
-| `/gsp:palette` | Interactive — ask for colors |
+| `/gsp-palette #FF5733 #3366FF` | Direct — hex colors from args |
+| `/gsp-palette #FF5733 #3366FF --preview` | Preview — show scales without writing files |
+| `/gsp-palette` | Interactive — ask for colors |
 
 ## Step 1: Collect colors
 
@@ -100,7 +100,7 @@ Parse the response and extract the scale values.
 If `--preview`, display the scales without writing files:
 
 ```
-  /gsp:palette preview
+  /gsp-palette preview
   ═══════════════════════════════════════
 
   primary (#FF5733)
@@ -120,7 +120,7 @@ If `--preview`, display the scales without writing files:
     ...
 
   ─────────────────────────────────────
-  Run /gsp:palette #FF5733 #3366FF to write files.
+  Run /gsp-palette #FF5733 #3366FF to write files.
 ```
 
 Stop here. Do not write any files.
@@ -146,7 +146,7 @@ Write `{OUTPUT_PATH}/palettes.json` with the full OKLCH scales:
 
 ```json
 {
-  "$description": "OKLCH 11-stop color palettes generated by /gsp:palette",
+  "$description": "OKLCH 11-stop color palettes generated by /gsp-palette",
   "$source": "tints.dev",
   "primary": {
     "source": "#FF5733",
@@ -245,7 +245,7 @@ Write `{OUTPUT_PATH}/color-system.md` as a foundation chunk per `references/chun
 Display the result:
 
 ```
-  /gsp:palette — {n} colors scaled
+  /gsp-palette — {n} colors scaled
   ═══════════════════════════════════════
 
   {OUTPUT_PATH}/
@@ -260,8 +260,8 @@ Display the result:
 
 Then use `AskUserQuestion` with routing options:
 
-- **Generate type scale** — "pair these palettes with typography" → route to `/gsp:typescale`
-- **Apply a full style** — "use a style preset for the complete system" → route to `/gsp:style`
-- **Continue to identity** — "use these palettes in the branding diamond" → route to `/gsp:brand-identity`
+- **Generate type scale** — "pair these palettes with typography" → route to `/gsp-typescale`
+- **Apply a full style** — "use a style preset for the complete system" → route to `/gsp-style`
+- **Continue to identity** — "use these palettes in the branding diamond" → route to `/gsp-brand-identity`
 - **Done** — "that's all for now"
 </process>

package/gsp/skills/gsp-pretty/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pretty
+name: gsp-pretty
 description: "Surprise ASCII art in the terminal"
 user-invocable: true
 model: sonnet
@@ -59,5 +59,5 @@ Spawn the `gsp-ascii-artist` agent with this prompt, filling in the context you
 
 ## Step 3: Done
 
-No iteration needed. If the user wants more control, point them to `/gsp:art`.
+No iteration needed. If the user wants more control, point them to `/gsp-art`.
 </process>

package/gsp/skills/gsp-progress/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: progress
+name: gsp-progress
 description: How pretty are we?
 user-invocable: true
 model: sonnet
@@ -57,7 +57,7 @@ Determine the Brand Mark diamond states:
 
 For each phase marked as complete in STATE.md, verify the phase directory contains at least 1 chunk file. If `status === 'complete'` and chunk count is 0, display that phase as `◆!` with note "(empty — may need re-run)".
 
-If `config.json` is missing or unparseable for any instance, show the instance name with "(config error — run /gsp:doctor)" instead of crashing.
+If `config.json` is missing or unparseable for any instance, show the instance name with "(config error — run /gsp-doctor)" instead of crashing.
 
 ## Step 5: Display progress
 
@@ -66,15 +66,15 @@ Output as plain text using the visual elements from the styling section above.
 ### Empty State
 
 ```
-  /gsp: ◇◇
+  /gsp- ◇◇
 
   no brands or projects found.
-  run /gsp:start to begin.
+  run /gsp-start to begin.
 ```
 
 ### Standard State — render these elements:
 
-**Brand Mark:** `/gsp:` (accent+bold) followed by state diamonds
+**Brand Mark:** `/gsp-` (accent+bold) followed by state diamonds
 
 **Labeled Divider:** `  ─── {Label} ──────────────────` (tertiary `───`, secondary+bold label)
 
@@ -93,12 +93,12 @@ Column positions: phase at col 4, status at col 19, chunks at col 29, time at co
 **Collapsed complete items:**
 When 100% complete, single-line: `  acme-corp ◆ complete (4/4, 11 chunks)`
 
-**Next Skill:** `  → next: /gsp:brand-identity` (secondary `→ next:`, accent skill name)
+**Next Skill:** `  → next: /gsp-brand-identity` (secondary `→ next:`, accent skill name)
 
 ### Example: Early State (2/4 branding)
 
 ```
-  /gsp: ◈◇
+  /gsp- ◈◇
 
 
   ─── Brands ───────────────────────────
@@ -113,7 +113,7 @@ When 100% complete, single-line: `  acme-corp ◆ complete (4/4, 11 chunks)`
     identity       ◇         —         —
     patterns       ◇         —         —
 
-  → next: /gsp:brand-identity
+  → next: /gsp-brand-identity
 
 
   ─── Overall ──────────────────────────
@@ -127,7 +127,7 @@ When 100% complete, single-line: `  acme-corp ◆ complete (4/4, 11 chunks)`
 ### Example: Late State (brand complete, 4/6 project)
 
 ```
-  /gsp: ◆◈
+  /gsp- ◆◈
 
 
   ─── Brands ───────────────────────────
@@ -149,7 +149,7 @@ When 100% complete, single-line: `  acme-corp ◆ complete (4/4, 11 chunks)`
     build          ◈         —         —
     review         ◇         —         —
 
-  → next: /gsp:project-build
+  → next: /gsp-project-build
 
 
   ─── Overall ──────────────────────────
@@ -169,18 +169,18 @@ After the summary, if everything is 100% complete, add: `  fully pretty.` in pri
 For each in-progress instance, identify the next pending phase and suggest the skill.
 
 **Brand routing:**
-- Phase 1 (Research) pending -> `/gsp:brand-research`
-- Phase 2 (Strategy) pending -> `/gsp:brand-strategy`
-- Phase 3 (Identity) pending -> `/gsp:brand-identity`
-- Phase 4 (Patterns) pending -> `/gsp:brand-patterns`
+- Phase 1 (Research) pending -> `/gsp-brand-research`
+- Phase 2 (Strategy) pending -> `/gsp-brand-strategy`
+- Phase 3 (Identity) pending -> `/gsp-brand-identity`
+- Phase 4 (Patterns) pending -> `/gsp-brand-guidelines`
 
 **Project routing:**
-- Brief pending -> `/gsp:project-brief`
-- Research pending -> `/gsp:project-research`
-- Design pending -> `/gsp:project-design`
-- Critique pending -> `/gsp:project-critique`
-- Build pending -> `/gsp:project-build`
-- Review pending -> `/gsp:project-review`
+- Brief pending -> `/gsp-project-brief`
+- Research pending -> `/gsp-project-research`
+- Design pending -> `/gsp-project-design`
+- Critique pending -> `/gsp-project-critique`
+- Build pending -> `/gsp-project-build`
+- Review pending -> `/gsp-project-review`
 
 Output this as a single block. Do NOT add commentary or suggestions beyond the dashboard content.
 </process>

package/gsp/skills/gsp-project-brief/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: project-brief
+name: gsp-project-brief
 description: Scope what you're building
 user-invocable: true
 model: sonnet
@@ -28,7 +28,6 @@ Scope the project and plan adaptations from the brand system.
 </objective>
 
 <execution_context>
-@${CLAUDE_SKILL_DIR}/../../prompts/10-project-scoper.md
 @${CLAUDE_SKILL_DIR}/../../templates/phases/brief.md
 </execution_context>
 
@@ -37,7 +36,7 @@ Scope the project and plan adaptations from the brand system.
 
 Resolve project from `.design/projects/` (one → use it, multiple → ask). Set `PROJECT_PATH`.
 
-Read `{PROJECT_PATH}/brand.ref` → set `BRAND_PATH`. If brand.ref doesn't exist, tell the user to run `/gsp:start`.
+Read `{PROJECT_PATH}/brand.ref` → set `BRAND_PATH`. If brand.ref doesn't exist, tell the user to run `/gsp-start`.
 
 ## Step 1: Load context
 
@@ -45,9 +44,9 @@ Read `{PROJECT_PATH}/brand.ref` → set `BRAND_PATH`. If brand.ref doesn't exist
 
 Read `{BRAND_PATH}/patterns/INDEX.md`. If it exists, load all foundation chunks + selective component chunks.
 
-If it doesn't exist, tell the user to run `/gsp:brand-patterns` first to create the brand's design patterns.
+If it doesn't exist, tell the user to run `/gsp-brand-guidelines` first to create the brand's design patterns.
 
-Also read `{BRAND_PATH}/patterns/tokens.json`.
+Also read the brand `.yml` preset from `{BRAND_PATH}/patterns/`.
 
 ### Project context
 
@@ -68,7 +67,7 @@ Glob `.design/projects/*/STATE.md` — detect active sibling projects.
 **If `design_scope` is `tokens`:**
 1. Update `{PROJECT_PATH}/STATE.md` — set Phase 1 (Brief) status to `skipped`
 2. Display: "Brief phase skipped — design scope is `tokens`."
-3. Route: "Run `/gsp:project-build`."
+3. Route: "Run `/gsp-project-build`."
 4. Stop here.
 
 ## Step 1.7: Issue framing
@@ -84,11 +83,11 @@ Spawn the `gsp-scoper` agent. **Inline all content** — the agent should not ne
 
 Pass in the agent prompt:
 - **Content of** brand patterns foundation + component chunks (loaded in Step 1)
-- **Content of** tokens.json (loaded in Step 1)
+- **Content of** brand `.yml` preset (loaded in Step 1)
 - **Content of** BRIEF.md (loaded in Step 1)
 - **Content of** `.design/system/STACK.md`, `COMPONENTS.md` (when loaded in Step 1)
 - **Content of** CHANGELOG.md + relevant MANIFEST.md files (loaded in Step 1)
-- The Project Scoper prompt (10), brief output template (from execution_context)
+- Brief output template (from execution_context)
 - `implementation_target`, `design_scope`, `codebase_type`
 - **Output path:** `{PROJECT_PATH}/brief/`
 

package/gsp/skills/gsp-project-build/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: project-build
+name: gsp-project-build
 description: Translate designs to code
 user-invocable: true
 model: opus
@@ -22,10 +22,10 @@ Works with the dual-diamond architecture: reads brand system from `.design/brand
 **Pipeline architecture:**
 ```
 Phase 1: SCAFFOLD (skill-level, no agent)
-  └─ /gsp:scaffold → verify build passes
+  └─ /gsp-scaffold → verify build passes
 
 Phase 2: FOUNDATIONS (agent: gsp-builder mode:foundations)
-  ├─ Context: tokens.json, target-adaptations.md, STACK.md, CONVENTIONS.md
+  ├─ Context: {brand-name}.yml + token-mapping.md, target-adaptations.md, STACK.md, CONVENTIONS.md
   ├─ Writes: token config, global CSS, layout, shared utils
   └─ CHECKPOINT: build must compile
 
@@ -49,7 +49,6 @@ Implement designs as production-ready code in the codebase via phased pipeline w
 </objective>
 
 <execution_context>
-@${CLAUDE_SKILL_DIR}/../../prompts/09-design-to-code-translator.md
 @${CLAUDE_SKILL_DIR}/../../templates/phases/build.md
 </execution_context>
 
@@ -63,7 +62,7 @@ Read `{PROJECT_PATH}/brand.ref` → set `BRAND_PATH`.
 ## Step 0.5: Validate prerequisites
 
 Read `{PROJECT_PATH}/STATE.md`. Check that Design (Phase 3) is `complete` or `needs-revision` (revision means critique ran and is feeding back).
-If design is `pending` or missing: "No designs found. Run `/gsp:project-design` first — building without designs leads to poor results." Then stop.
+If design is `pending` or missing: "No designs found. Run `/gsp-project-design` first — building without designs leads to poor results." Then stop.
 
 Exception: if `design_scope` is `tokens` in config.json, skip this check (tokens-only projects don't need design).
 
@@ -90,7 +89,7 @@ Check `{PROJECT_PATH}/STATE.md` for build status. If status is `needs-revision`:
 
 ### Design check
 
-If design doesn't exist (no `design/` dir or no screen chunks in it), tell the user to run `/gsp:project-design` first and stop.
+If design doesn't exist (no `design/` dir or no screen chunks in it), tell the user to run `/gsp-project-design` first and stop.
 
 ### Enumerate screens
 
@@ -101,7 +100,7 @@ Log screen list for user visibility.
 
 ## Step 2: Phase 1 — SCAFFOLD
 
-Invoke `/gsp:scaffold` via the Skill tool.
+Invoke `/gsp-scaffold` via the Skill tool.
 
 This handles: dependency installation, config file creation, component library init, build verification.
 
@@ -114,10 +113,11 @@ After scaffold completes, verify `{PROJECT_PATH}/build/SCAFFOLD-LOG.md` exists.
 Read these reference files (relative to skill dir `${CLAUDE_SKILL_DIR}/../../references/`):
 - `visual-effects.md`
 - `block-patterns.md`
-- `anti-patterns.md`
 
 Hold their content for inlining into agent prompts in Steps 3 and 5.
 
+> **Note:** Anti-patterns are distilled into the `gsp-builder` agent prompt. Full ref remains on disk for edge-case agent lookup.
+
 ## Step 3: Phase 2 — FOUNDATIONS
 
 Spawn `gsp-builder` agent with **execution_mode: foundations**.
@@ -126,15 +126,15 @@ Spawn `gsp-builder` agent with **execution_mode: foundations**.
 
 | File | Purpose |
 |------|---------|
-| `{BRAND_PATH}/patterns/tokens.json` | Design tokens |
-| `{BRAND_PATH}/patterns/{brand-name}.md` | Brand visual DNA — effects, component stylings, bold bets (if exists) |
+| `{BRAND_PATH}/patterns/{brand-name}.yml` | Token values only — used with `references/token-mapping.md` to generate CSS variables. Do NOT re-read patterns/constraints/effects from here — those are in STYLE.md. |
+| `{BRAND_PATH}/patterns/STYLE.md` | Design law — philosophy, patterns, constraints, effects, bold bets, implementation hints (if exists; fall back to `{brand-name}.md`) |
 | `{PROJECT_PATH}/brief/target-adaptations.md` | Component adaptations for target |
 | `.design/system/STACK.md` | Stack state |
 | `.design/system/CONVENTIONS.md` | Codebase conventions (if exists) |
 | `.design/system/COMPONENTS.md` | Existing components (if exists) |
 | `{PROJECT_PATH}/config.json` | Tech stack, target |
-| Design-to-Code Translator prompt (09, from execution_context) | Translation methodology |
-| Visual effects, block patterns, anti-patterns refs (loaded in Step 2.5) | Design patterns + constraints |
+| Build output template (from execution_context) | Build log structure |
+| Visual effects, block patterns refs (loaded in Step 2.5) | Design patterns + CSS recipes |
 
 ### Agent instructions:
 
@@ -146,7 +146,7 @@ Spawn `gsp-builder` agent with **execution_mode: foundations**.
 > 2. Create global CSS (resets, base styles, font imports, dark mode setup)
 > 3. Create root layout with nav shell and footer shell (structure only — no page content)
 > 4. Create shared utilities (cn helper, theme provider if needed)
-> 5. Apply the brand style prompt's visual effects and signature patterns — create CSS utilities or Tailwind extensions for the brand's signature effects (glass, glow, gradients, shadows, motion patterns)
+> 5. Apply the STYLE.md bold bets and effects vocabulary — create CSS utilities or Tailwind extensions for the brand's signature effects. Validate against constraints (never/always rules are non-negotiable).
 > 6. Do NOT build individual screens or page content
 > 7. Write code directly to the codebase, not to `.design/`
 > 8. Leave changes unstaged
@@ -210,10 +210,10 @@ If the user requests adjustments during foundation review:
 
 1. Apply the changes to the project codebase first (directly or via a quick builder re-run)
 2. Ask: "Should this change also update the brand system? (Other projects using this brand would inherit it)"
-3. If yes, spawn a background `gsp-pattern-architect` agent to update brand patterns:
+3. If yes, spawn a background `gsp-brand-engineer` agent to update brand patterns:
    - Pass: the specific changes made (what tokens/values changed, old → new)
-   - Pass: `{BRAND_PATH}/patterns/tokens.json` and relevant identity chunks
-   - Agent updates tokens.json, foundation chunks, and style preset YAML if applicable
+   - Pass: `{BRAND_PATH}/patterns/{brand-name}.yml` and relevant identity chunks
+   - Agent updates the `.yml` preset, foundation chunks, and STYLE.md if applicable
    - Agent writes to `{BRAND_PATH}/` — the brand source of truth
    - Run in background (`run_in_background: true`) so the build pipeline continues
 4. Continue to Step 5 without waiting for brand sync
@@ -231,10 +231,10 @@ Build screens sequentially. For each screen in `SCREENS`:
 | `{PROJECT_PATH}/brief/target-adaptations.md` | Component adaptations |
 | `{PROJECT_PATH}/research/reference-specs.md` (if exists) | Technical specs |
 | `{PROJECT_PATH}/critique/prioritized-fixes.md` (if exists) | Critique fixes relevant to this screen |
-| Design-to-Code Translator prompt (09, from execution_context) | Translation methodology |
-| Visual effects, block patterns, anti-patterns refs (loaded in Step 2.5) | Design patterns + constraints |
+| Build output template (from execution_context) | Build log structure |
+| Visual effects, block patterns refs (loaded in Step 2.5) | Design patterns + CSS recipes |
 
-**Does NOT receive:** other screen chunks, tokens.json (already in codebase), full brand system, research monoliths.
+**Does NOT receive:** other screen chunks, brand `.yml` (already integrated into codebase), full brand system, research monoliths.
 
 ### Agent instructions per screen:
 
@@ -308,7 +308,7 @@ This step is **not auto-applied** — the user decides what to extract.
 If the extraction scan finds hardcoded values that should be tokens (finding type #2), and those tokens are missing from the brand system:
 
 1. After applying fixes in the project, ask: "These token gaps also exist in the brand. Update brand patterns?"
-2. If yes, spawn a background `gsp-pattern-architect` agent with the missing token definitions to add them to `{BRAND_PATH}/patterns/tokens.json` and relevant foundation chunks.
+2. If yes, spawn a background `gsp-brand-engineer` agent with the missing token definitions to add them to `{BRAND_PATH}/patterns/{brand-name}.yml` and relevant foundation chunks.
 
 ## Step 6: Finalize
 
@@ -365,7 +365,7 @@ For `needs-revision` status, spawn a single `gsp-builder` agent with execution_m
 After the revision agent completes, check if any QA fixes changed token-level values (colors, typography, spacing, shadows). If so:
 
 1. Ask: "These revisions changed brand-level values. Update brand patterns so future projects inherit the fix?"
-2. If yes, spawn a background `gsp-pattern-architect` agent with the changed values to update `{BRAND_PATH}/patterns/`.
+2. If yes, spawn a background `gsp-brand-engineer` agent with the changed values to update `{BRAND_PATH}/patterns/`.
 
 Then continue from Step 6 (finalize).
 </process>

package/gsp/skills/gsp-project-critique/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: project-critique
+name: gsp-project-critique
 description: Critique your designs + accessibility audit
 user-invocable: true
 model: opus
@@ -26,8 +26,6 @@ Critique design quality and audit accessibility compliance.
 </objective>
 
 <execution_context>
-@${CLAUDE_SKILL_DIR}/../../prompts/06-design-critique-partner.md
-@${CLAUDE_SKILL_DIR}/../../prompts/08-accessibility-auditor.md
 @${CLAUDE_SKILL_DIR}/../../templates/phases/critique.md
 </execution_context>
 
@@ -59,13 +57,13 @@ Read `{PROJECT_PATH}/config.json` to get `implementation_target`, `design_scope`
 ## Step 1.5: Scope check
 
 **If `design_scope` is `tokens`:**
-1. Check if `{PROJECT_PATH}/critique/accessibility-token-audit.md` exists (from prior `/gsp:accessibility --tokens`). If yes, reference it and skip inline token checks. If no, suggest running `/gsp:accessibility --tokens` for detailed token contrast analysis.
+1. Check if `{PROJECT_PATH}/critique/accessibility-token-audit.md` exists (from prior `/gsp-accessibility --tokens`). If yes, reference it and skip inline token checks. If no, suggest running `/gsp-accessibility --tokens` for detailed token contrast analysis.
 2. Review system chunks only — token foundations, naming, scale consistency
 3. Run accessibility audit on color contrast and token values only (unless prior token audit exists)
 4. Write results to `{PROJECT_PATH}/critique/accessibility-audit.md` and `accessibility-fixes.md`
 5. Write `{PROJECT_PATH}/critique/INDEX.md`
 6. Update STATE.md — set Phase 4 to `complete`
-7. Route: "Run `/gsp:project-build`."
+7. Route: "Run `/gsp-project-build`."
 8. **Stop here**
 
 **Otherwise:** If design chunks don't exist and scope is not `tokens`, tell the user to complete the design phase first.
@@ -73,34 +71,35 @@ Read `{PROJECT_PATH}/config.json` to get `implementation_target`, `design_scope`
 ## Step 1.8: Load critique references
 
 Read these reference files (relative to skill dir `${CLAUDE_SKILL_DIR}/../../references/`):
-- `nielsen-heuristics.md`
-- `visual-taste.md`
-- `anti-patterns.md`
 - `wcag-checklist.md`
 - `color-composition.md`
 
 Hold their content for inlining into agent prompts in Step 2.
 
+> **Note:** Nielsen's heuristics, visual taste, and anti-patterns are distilled into the `gsp-critic` agent prompt. Full refs remain on disk for edge-case agent lookup.
+
 ## Step 2: Spawn critics (parallel)
 
-**Inline all content** — agents should not need to read any input files.
+**Inline all project content** — agents should not need to read project files. Reference files for supplementary evaluation (visual-taste, anti-patterns) are on disk — the critic reads them as needed.
 
 **Agent 1: gsp-critic** — Pass in the agent prompt:
 - **Content of** all design chunks (loaded in Step 1)
 - **Content of** all identity chunks (loaded in Step 1)
 - **Content of** all patterns chunks (loaded in Step 1)
+- **Content of** `STYLE.md` from `{BRAND_PATH}/patterns/` (if exists) — the critic checks designs against STYLE.md constraints, patterns, effects vocabulary, and bold bets
 - **Content of** brief chunks (loaded in Step 1)
 - **Content of** research recommendations.md (loaded in Step 1)
 - **Content of** BRIEF.md
-- **Content of** Nielsen's 10 Heuristics, visual taste, anti-patterns, color composition references (loaded in Step 1.8)
-- The Design Critique Partner prompt (06), critique output template (from execution_context)
+- **Content of** color composition reference (loaded in Step 1.8)
+- Critique output template (from execution_context)
+- `references_path`: `${CLAUDE_SKILL_DIR}/../../references/` — for supplementary Read access to visual-taste.md, anti-patterns.md
 - Output path: `{PROJECT_PATH}/critique/`
 
-**Agent 2: gsp-accessibility-auditor** — Check if `{PROJECT_PATH}/critique/accessibility-audit.md` already exists from a prior `/gsp:accessibility` run. If yes, skip spawning the accessibility auditor — reuse the existing output. If no, pass in the agent prompt:
+**Agent 2: gsp-accessibility-auditor** — Check if `{PROJECT_PATH}/critique/accessibility-audit.md` already exists from a prior `/gsp-accessibility` run. If yes, skip spawning the accessibility auditor — reuse the existing output. If no, pass in the agent prompt:
 - **Content of** all design chunks (loaded in Step 1)
 - **Content of** identity color-system.md and typography.md (loaded in Step 1)
 - **Content of** patterns tokens chunks (loaded in Step 1)
-- **Content of** WCAG checklist reference (loaded in Step 1.8), Accessibility Auditor prompt (08, from execution_context)
+- **Content of** WCAG checklist reference (loaded in Step 1.8)
 - `accessibility_level` from config (defaults to "WCAG 2.2 AA")
 - Output path: `{PROJECT_PATH}/critique/`
 
@@ -169,6 +168,6 @@ If verdict is **Fail**:
 
 Render phase transition (see `references/phase-transitions.md`). This phase has pass/fail variants — the reference covers both.
 
-If critique identified brand-level issues (palette contrast, typography weight, spacing scale), note: "Some issues are brand-level — run `/gsp:brand-refine` to adjust tokens without re-running identity."
+If critique identified brand-level issues (palette contrast, typography weight, spacing scale), note: "Some issues are brand-level — run `/gsp-brand-refine` to adjust tokens without re-running identity."
 </process>
 </output>