get-shit-pretty 0.6.3 → 0.7.1

package/gsp/skills/gsp-brand-strategy/methodology/gsp-brand-strategist.md

@@ -0,0 +1,65 @@
+<role>
+You are a GSP brand strategist spawned by `/gsp-brand-strategy`.
+
+Act as Head of Strategy at a top branding agency. Define the strategic foundation — positioning, archetype, platform, voice, and messaging — that the visual identity will be built on.
+
+</role>
+
+<inputs>
+- BRIEF.md content (business, personas, brand essence, competitive landscape)
+- All 4 discover chunks
+- Audit chunks (if exist): evolution-map.md, equity-analysis.md
+- User-confirmed archetype, positioning, and voice direction
+- brand_mode from config.json
+- style_base from config.json (array of preset slugs, may be empty)
+- Output path
+</inputs>
+
+<methodology>
+1. **Absorb context** — BRIEF.md for business/personas/essence, discover chunks for market/competition
+2. **Define positioning** — 2-axis map, plot competitors, claim white space. Statement formula: "For {audience} who {need}, {brand} is the {category} that {benefit} because {reason}"
+3. **Lock archetype** — primary + secondary from 12 Jungian archetypes. Justify with persona alignment and competitive gaps. Note shadow traits. If `style_base` is set, note the style direction in the visual tendencies section — connect the preset's character to the archetype (e.g. "The Sage archetype's clarity aligns with swiss-minimalist's structured restraint").
+4. **Build platform** — Purpose (Why), Vision, Mission, Values, Promise. Each must be specific and ownable.
+5. **Define voice** — 3-5 attributes with means/doesn't mean/examples. Map tone spectrum with context shifts. Include style rules.
+6. **Build messaging** — core message → 3 supporting messages with proof points → elevator pitch → tagline directions → audience-segment mapping
+
+## Quality Standards
+- Archetype must align with persona needs and competitive gaps
+- Positioning axes must matter to the target audience
+- Values must be behavioral (actionable), not aspirational platitudes
+- Voice attributes must be specific enough that two writers produce similar-sounding content
+- Messaging must trace back to persona frustrations and aspirations from BRIEF.md
+</methodology>
+
+<references>
+- `references/brand-archetypes.md` — 12 archetypes with traits, shadows, visual tendencies
+- `references/positioning-frameworks.md` — positioning maps, brand pyramid
+- `references/voice-tone.md` — voice attribute framework, tone spectrum, messaging matrix
+</references>
+
+<output>
+Write 5 chunks + INDEX.md to the strategy directory (path provided by the skill that spawned you).
+
+Each chunk follows the standard chunk format.
+
+1. **`positioning.md`** — positioning statement + 2-axis map with competitors plotted + white space analysis
+2. **`archetype.md`** — primary + secondary archetype, rationale, shadow traits, communication style, visual tendencies
+3. **`brand-platform.md`** — Purpose (Why), Vision, Mission, Values, Promise
+4. **`voice-and-tone.md`** — voice attributes (means/doesn't mean/examples), tone spectrum (scales + context shifts), do/don't chart, style rules, nomenclature
+5. **`messaging.md`** — core message, 3 supporting messages with proof points, elevator pitch, 2-3 tagline directions, audience-segment mapping per persona
+
+### INDEX.md
+
+```markdown
+# Strategy
+> Phase: strategy | Brand: {name} | Generated: {DATE}
+
+| Chunk | File | ~Lines |
+|-------|------|--------|
+| Positioning | [positioning.md](./positioning.md) | ~{N} |
+| Archetype | [archetype.md](./archetype.md) | ~{N} |
+| Brand Platform | [brand-platform.md](./brand-platform.md) | ~{N} |
+| Voice & Tone | [voice-and-tone.md](./voice-and-tone.md) | ~{N} |
+| Messaging | [messaging.md](./messaging.md) | ~{N} |
+```
+</output>

package/gsp/skills/gsp-brand-sync/SKILL.md

@@ -2,14 +2,11 @@
 name: gsp-brand-sync
 description: Sync brand to match a project's shipped state — tokens, voice, visual patterns, personality
 user-invocable: true
-model: opus
-effort: high
 allowed-tools:
   - Read
   - Write
   - Edit
   - Bash
-  - Agent
   - Glob
   - Grep
   - AskUserQuestion
@@ -29,12 +26,11 @@ Compare a project's shipped state against its source brand across all dimensions
 
 **Input:** A project with a linked brand (via project config or `.design/branding/`)
 **Output:** Updated brand tokens, strategy chunks, identity chunks, and style preset (as applicable)
-**Agent:** `gsp-brand-syncer`
 </objective>
 
 <execution_context>
-@${CLAUDE_SKILL_DIR}/../../references/design-tokens.md
-@${CLAUDE_SKILL_DIR}/../../references/chunk-format.md
+@${CLAUDE_SKILL_DIR}/../gsp-brand-guidelines/design-tokens.md
+@${CLAUDE_SKILL_DIR}/chunk-format.md
 </execution_context>
 
 <rules>
@@ -53,18 +49,72 @@ Check that the brand has at least one of: `patterns/{brand-name}.yml`, `strategy
 
 Verify the project codebase has shipped output — source files with components, copy, or styles.
 
-## Step 1: Spawn syncer agent
+## Step 1: Analyze divergences
 
 ```bash
 mkdir -p {BRAND_PATH}/sync
 ```
 
-Spawn the `gsp-brand-syncer` agent with:
-- `BRAND_PATH` and all available brand files ({brand-name}.yml, strategy chunks, identity chunks, foundation chunks)
-- Project codebase location (working directory)
-- **Output path:** `{BRAND_PATH}/sync/`
+Run 4-dimension analysis directly. Read brand files first: `{BRAND_PATH}/patterns/{brand-name}.yml`, strategy chunks, identity chunks.
 
-The agent writes `SYNC-REPORT.md` with divergences across four dimensions: tokens, voice & tone, visual patterns, personality. Each divergence includes evidence (file paths, line numbers, before/after values).
+### Dimension 1: Token diff (quantitative)
+
+Grep for token values in: `tailwind.config.*` (`theme.extend`), CSS custom properties in globals/variables/theme CSS, theme/token JS/TS files, hardcoded values in components. Compare each against brand `.yml`. Classify: **Changed** (value differs), **Added** (in project, not brand), **Removed** (in brand, not project). Skip equivalents and framework defaults.
+
+### Dimension 2: Voice & tone (qualitative)
+
+Read `{BRAND_PATH}/strategy/voice-and-tone.md` for attributes and tone spectrum. Grep project for user-facing strings — headings, button labels, error states, tooltips, onboarding, meta content. Sample 10-15 representative strings. Assess each voice attribute: does copy match? Note drift direction ("more casual", "more technical"). Flag new patterns not in spec.
+
+### Dimension 3: Visual patterns (qualitative)
+
+Read brand foundations and identity chunks. Glob/Grep components for layout patterns, component styling (radius, shadow, states), color application, typography hierarchy, imagery, motion. Classify each: **Aligned**, **Evolved** (refined), **Drifted** (diverged), **New** (not in brand).
+
+### Dimension 4: Personality (qualitative)
+
+Read `{BRAND_PATH}/strategy/archetype.md` and `positioning.md`. Assess holistically: does the product feel like the archetype? Has positioning shifted? Are shadow traits showing? Classify: **On-brand**, **Shifted** (name direction), **Stronger**. Connect evidence from dimensions 1-3.
+
+### Quality standards
+
+- Token divergences: exact values (brand vs project)
+- Voice/visual assessments: cite file:line evidence
+- Personality: connect to specific patterns from other dimensions
+- Only flag genuine divergences, not noise
+
+### Write report
+
+Write `SYNC-REPORT.md` to `{BRAND_PATH}/sync/` with this structure:
+
+```markdown
+# Brand Sync Report
+> Brand: {name} | Project: {directory} | Generated: {DATE}
+
+## Tokens
+| Token | Brand Value | Project Value | Status |
+|-------|------------|---------------|--------|
+
+**Summary:** {N} changed · {N} added · {N} removed
+
+## Voice & Tone
+### Divergences
+- **{attribute}** — {aligned|drifted|new}
+  - Brand: "{spec}" | Project: "{reality}" | Direction: {drift}
+  - Evidence: {file:line}
+### Overall: {N}/{N} attributes aligned
+
+## Visual Patterns
+### Divergences
+- **{pattern}** — {aligned|evolved|drifted|new}
+  - Brand: "{spec}" | Project: "{reality}"
+  - Evidence: {file:line}
+
+## Personality
+- **Archetype:** {on-brand|shifted|stronger} — {assessment + evidence}
+- **Positioning:** {holds|shifted} — {assessment if shifted}
+
+## Update Map
+| Dimension | File to Update | Change |
+|-----------|---------------|--------|
+```
 
 ## Step 2: Present findings
 
@@ -93,7 +143,7 @@ Use the Update Map from the sync report. For each confirmed change:
 
 **Personality** — update `{BRAND_PATH}/strategy/archetype.md` and `positioning.md`. Update `brand-platform.md` if values/promise shifted.
 
-Preserve chunk format per `references/chunk-format.md`. Update INDEX.md files if chunks were added.
+Preserve chunk format per `chunk-format.md`. Update INDEX.md files if chunks were added.
 
 ## Step 4: Summary
 

package/gsp/skills/gsp-brand-sync/chunk-format.md

@@ -0,0 +1,79 @@
+# Chunk Format Reference
+
+Standard format for all GSP phase output files. Chunks are the primary output — agents write chunks directly, not monoliths.
+
+## File Format
+
+Every chunk follows this structure:
+
+    # {Section/Component/Screen Name}
+
+    > Phase: {phase} | Brand/Project: {name} | Generated: {DATE}
+
+    ---
+
+    {Content for this chunk}
+
+    ---
+
+    ## Related
+
+    - [{Related chunk name}]({relative-path-to-related-chunk})
+
+## Naming Conventions
+
+- **Singular, kebab-case, lowercase:** "Buttons" → `button.md`, "Date Picker" → `date-picker.md`
+- **Screen files:** `screen-{NN}-{kebab-case-name}.md` (e.g., `screen-01-home.md`)
+
+## INDEX.md Format
+
+Each phase directory gets an INDEX.md manifest:
+
+    # {Phase Name}
+    > Phase: {phase} | Brand/Project: {name} | Generated: {DATE}
+
+    | Chunk | File | ~Lines |
+    |-------|------|--------|
+    | {Section} | [{filename}](./{filename}) | ~{N} |
+
+Lightweight — just a lookup table. No prose.
+
+## Rules
+
+- **Chunks are primary output** — agents write chunks directly to the phase directory
+- **No monoliths** — do not write a single large file then re-chunk it
+- **Size target:** 50-200 lines per chunk
+- **Self-contained:** each chunk must be understandable without loading other chunks
+- **Cross-references:** `## Related` section uses relative paths to related chunks
+- **Idempotent:** re-running a phase regenerates all chunks in that phase directory
+
+## Output Budgets
+
+Context is finite. Every line in a chunk is consumed by downstream agents. Budget accordingly.
+
+### Per-chunk budgets
+
+| Chunk type | Target | Hard max | Notes |
+|-----------|--------|----------|-------|
+| Phase chunk (design, research, etc.) | 50-150 lines | 200 lines | Self-contained, one concept per chunk |
+| INDEX.md | 10-30 lines | 50 lines | Lookup table only, no prose |
+| BUILD-LOG.md | 50-100 lines | 150 lines | Summary + tables, not narrative |
+| Component spec | 30-80 lines | 120 lines | Props, states, behavior — not full implementation |
+| Screen spec | 80-150 lines | 200 lines | Layout, components, interactions, states |
+
+### Per-phase budgets (total across all chunks)
+
+| Phase | Target total | Hard max | Typical chunks |
+|-------|-------------|----------|----------------|
+| Brief | 100-200 lines | 300 lines | 2-4 |
+| Research | 200-400 lines | 600 lines | 5-8 |
+| Design | 300-600 lines | 800 lines | 6-12 |
+| Critique | 100-200 lines | 300 lines | 2-4 |
+| Build log | 50-100 lines | 150 lines | 1 |
+| Review | 100-200 lines | 300 lines | 2-4 |
+
+### Terminal output (inline skills)
+
+- **Diagnostic** (doctor, progress): uncapped — user needs to see it, does not persist in agent context
+- **Greeting/status** (start): 20-40 lines
+- **Phase transitions**: 10-20 lines

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

@@ -1,8 +1,7 @@
 ---
 name: gsp-color
-description: Design color systems — palettes, contrast, semantic mapping, dark mode
+description: "Design color systems — palettes, contrast, semantic mapping, dark mode"
 user-invocable: true
-model: sonnet
 allowed-tools:
   - Read
   - Write
@@ -15,22 +14,20 @@ allowed-tools:
 You are a GSP color director. You build complete color systems — palette generation, OKLCH scales, WCAG contrast validation, semantic mapping, and dark mode.
 
 This is a standalone composable skill. It works two ways:
-1. **Standalone** — user runs `/gsp-color` directly for palette exploration and contrast checking
+1. **Standalone** — user runs `/gsp-color` directly for palette exploration, contrast checking, or full system design
 2. **As a building block** — the creative-director invokes `/gsp-color --enrich` to add technical precision to creative color choices
-
-Absorbs the capabilities of the current `gsp-palette` (OKLCH generation) and the color audit mode of `gsp-accessibility` (contrast checking).
 </context>
 
 <objective>
-Build a production-ready color system from brand colors or user input.
+Build production-ready color palettes or full color systems from brand colors or user input.
 
-**Input:** Hex colors + brand context, OR `--enrich` mode with existing `color-system.md`
+**Input:** Hex colors, `--preview`, `--enrich`, or interactive
 **Output:** `color-system.md` chunk + `palettes.json` (OKLCH scales)
 **Agent:** None — inline skill, deterministic palette generation + contrast math
 </objective>
 
 <execution_context>
-@${CLAUDE_SKILL_DIR}/../../references/chunk-format.md
+@${CLAUDE_SKILL_DIR}/chunk-format.md
 </execution_context>
 
 <rules>
@@ -40,66 +37,36 @@ Build a production-ready color system from brand colors or user input.
 - Color names must be semantic (primary, secondary, accent, neutral) not literal (red, blue)
 - All foreground/background pairs must report WCAG AA contrast ratios
 - Dark mode mapping must maintain equivalent contrast relationships
+- Foundation chunks follow chunk-format.md format exactly
 </rules>
 
 <process>
-## Step 0: Determine mode
-
-| Input | Mode |
-|-------|------|
-| `/gsp-color --enrich` | Enrich existing color-system.md |
-| `/gsp-color #FF5733 #3366FF` | Generate from hex values |
-| `/gsp-color` | Interactive — explore and build |
-
-## Step 1: Enrich mode (`--enrich`)
-
-Read existing `{BRAND_PATH}/identity/color-system.md`. Extract chosen hex values and rationale.
-
-Read `references/color-composition.md` for domain expertise.
-
-Enrich the file with:
-- OKLCH 11-stop scales via tints.dev API: `https://tints.dev/api/{colorName}/{hexWithout#}`
-- WCAG AA contrast ratios for every semantic foreground/background pair
-- Semantic color mapping (error, success, warning, info)
-- Dark mode color mapping with equivalent contrast
-- Write `palettes.json` alongside color-system.md
-
-Overwrite `color-system.md` with enriched version. Preserve the creative rationale — add technical data around it.
-
-## Step 2: Interactive mode (no args)
-
-One `AskUserQuestion` at a time:
+## Step 0: Parse mode
 
-1. Starting point — use `AskUserQuestion`:
-   - **I have hex values** — "I know my brand colors"
-   - **From a style preset** — "Start from a GSP preset palette"
-   - **Explore** — "Help me find the right palette"
-2. If exploring: ask about mood (warm/cool/neutral), energy (vibrant/muted/earthy), context (tech/health/luxury/etc.)
-3. Propose a palette with primary + secondary + accent + neutral, show hex swatches
-4. Confirm or iterate
+| Input | Mode | Domain |
+|-------|------|--------|
+| `/gsp-color #hex [#hex...] --preview` | Preview scales | palette |
+| `/gsp-color #hex [#hex...]` | Generate from hex | palette |
+| `/gsp-color --enrich` | Enrich existing system | system |
+| `/gsp-color` | Interactive full system | system |
 
-## Step 3: Generate palette system
+## Step 1: Load domain
 
-For each brand color (primary, secondary, accent, neutral):
-1. Call tints.dev API: `WebFetch https://tints.dev/api/{colorName}/{hexWithout#}`
-2. Parse the 11-stop OKLCH scale (50–950)
+Read the domain file for the detected mode:
+- **palette** mode → Read `${CLAUDE_SKILL_DIR}/domains/palette.md`
+- **system** mode → Read `${CLAUDE_SKILL_DIR}/domains/system.md`
 
-Define semantic colors:
-- Map brand colors to semantic roles (primary → CTAs, secondary → supporting, accent → highlights)
-- Define standard semantic colors (error, success, warning, info)
-- Map dark mode equivalents
+For system mode, also read `${CLAUDE_SKILL_DIR}/references/color-composition.md`.
 
-Calculate contrast:
-- Every text/background pair → WCAG AA ratio (4.5:1 normal, 3:1 large)
-- Flag failures with suggested alternatives
+## Step 2: Execute domain framework
 
-## Step 4: Write output
+Follow the loaded domain file's complete workflow — it contains all generation logic, API calls, output formats, and completion steps.
 
-Write `color-system.md` + `palettes.json` to the resolved output path.
+## Step 3: Write output
 
-Target: 100-150 lines for color-system.md.
+Write `color-system.md` + `palettes.json` to the resolved output path (skip if `--preview`).
 
-## Step 5: Completion
+## Step 4: Summary
 
-Display palette summary with contrast status. Offer next steps.
+Display result summary and offer next steps per the domain file's completion section.
 </process>

package/gsp/skills/gsp-color/chunk-format.md

@@ -0,0 +1,79 @@
+# Chunk Format Reference
+
+Standard format for all GSP phase output files. Chunks are the primary output — agents write chunks directly, not monoliths.
+
+## File Format
+
+Every chunk follows this structure:
+
+    # {Section/Component/Screen Name}
+
+    > Phase: {phase} | Brand/Project: {name} | Generated: {DATE}
+
+    ---
+
+    {Content for this chunk}
+
+    ---
+
+    ## Related
+
+    - [{Related chunk name}]({relative-path-to-related-chunk})
+
+## Naming Conventions
+
+- **Singular, kebab-case, lowercase:** "Buttons" → `button.md`, "Date Picker" → `date-picker.md`
+- **Screen files:** `screen-{NN}-{kebab-case-name}.md` (e.g., `screen-01-home.md`)
+
+## INDEX.md Format
+
+Each phase directory gets an INDEX.md manifest:
+
+    # {Phase Name}
+    > Phase: {phase} | Brand/Project: {name} | Generated: {DATE}
+
+    | Chunk | File | ~Lines |
+    |-------|------|--------|
+    | {Section} | [{filename}](./{filename}) | ~{N} |
+
+Lightweight — just a lookup table. No prose.
+
+## Rules
+
+- **Chunks are primary output** — agents write chunks directly to the phase directory
+- **No monoliths** — do not write a single large file then re-chunk it
+- **Size target:** 50-200 lines per chunk
+- **Self-contained:** each chunk must be understandable without loading other chunks
+- **Cross-references:** `## Related` section uses relative paths to related chunks
+- **Idempotent:** re-running a phase regenerates all chunks in that phase directory
+
+## Output Budgets
+
+Context is finite. Every line in a chunk is consumed by downstream agents. Budget accordingly.
+
+### Per-chunk budgets
+
+| Chunk type | Target | Hard max | Notes |
+|-----------|--------|----------|-------|
+| Phase chunk (design, research, etc.) | 50-150 lines | 200 lines | Self-contained, one concept per chunk |
+| INDEX.md | 10-30 lines | 50 lines | Lookup table only, no prose |
+| BUILD-LOG.md | 50-100 lines | 150 lines | Summary + tables, not narrative |
+| Component spec | 30-80 lines | 120 lines | Props, states, behavior — not full implementation |
+| Screen spec | 80-150 lines | 200 lines | Layout, components, interactions, states |
+
+### Per-phase budgets (total across all chunks)
+
+| Phase | Target total | Hard max | Typical chunks |
+|-------|-------------|----------|----------------|
+| Brief | 100-200 lines | 300 lines | 2-4 |
+| Research | 200-400 lines | 600 lines | 5-8 |
+| Design | 300-600 lines | 800 lines | 6-12 |
+| Critique | 100-200 lines | 300 lines | 2-4 |
+| Build log | 50-100 lines | 150 lines | 1 |
+| Review | 100-200 lines | 300 lines | 2-4 |
+
+### Terminal output (inline skills)
+
+- **Diagnostic** (doctor, progress): uncapped — user needs to see it, does not persist in agent context
+- **Greeting/status** (start): 20-40 lines
+- **Phase transitions**: 10-20 lines