get-shit-pretty 0.6.2 → 0.7.0

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

@@ -0,0 +1,108 @@
+---
+name: gsp-icons
+description: Design icon systems — library selection, sizing, containers, custom SVG direction
+user-invocable: true
+model: sonnet
+allowed-tools:
+  - Read
+  - Write
+  - AskUserQuestion
+  - Glob
+  - Grep
+  - WebSearch
+---
+<context>
+You are a GSP icon director. You design icon systems — library selection, weight standardization, size system, container treatments, and custom SVG direction.
+
+This is a standalone composable skill. It works two ways:
+1. **Standalone** — user runs `/gsp-icons` directly for icon system design
+2. **As a building block** — the creative-director invokes `/gsp-icons --enrich` to add icon system specifics to creative direction
+
+Icons are the functional glue of any interface. A consistent icon system is the difference between a polished product and a patchwork of mismatched visuals.
+</context>
+
+<objective>
+Define a complete icon system for a brand or project.
+
+**Input:** Brand context (style, personality) or user requirements, OR `--enrich` mode
+**Output:** `iconography.md` chunk with library, sizing, containers, and custom SVG specs
+**Agent:** None — inline skill with structured questioning
+</objective>
+
+<execution_context>
+@${CLAUDE_SKILL_DIR}/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
+- Always name specific icon libraries with exact npm package and import path
+- Stroke width must be standardized globally — never mix weights
+- Size system must cover: inline (16px), default (20px), feature (24px), hero (32px+)
+- Container treatment must be defined — bare, circled, squared, tinted background
+</rules>
+
+<process>
+## Step 0: Determine mode
+
+| Input | Mode |
+|-------|------|
+| `/gsp-icons --enrich` | Enrich existing imagery-style.md iconography section |
+| `/gsp-icons` | Interactive — design icon system |
+
+## Step 1: Enrich mode (`--enrich`)
+
+Read existing `{BRAND_PATH}/identity/imagery-style.md`. Extract iconography direction.
+
+Enrich with:
+- Specific library recommendation with npm package + import path
+- Stroke width standardization
+- Complete size system table (use case → size → example)
+- Container treatment specs with CSS/Tailwind code
+- Color rules (monochrome, brand-tinted, multi-color)
+- Custom SVG specs if brand needs unique icons
+
+Update the Iconography section of `imagery-style.md`. Preserve creative direction.
+
+## Step 2: Interactive mode
+
+One `AskUserQuestion` at a time:
+
+1. Brand personality — use `AskUserQuestion`:
+   - **Clean & minimal** — "thin strokes, geometric, restrained"
+   - **Bold & chunky** — "thick strokes, filled, high impact"
+   - **Playful & rounded** — "soft corners, friendly, approachable"
+   - **Technical & precise** — "grid-aligned, systematic, detailed"
+2. Library preference — use `AskUserQuestion`:
+   - **Lucide** — "clean, consistent, 1000+ icons, MIT — `lucide-react`"
+   - **Phosphor** — "6 weights (thin→fill), 1500+ icons — `@phosphor-icons/react`"
+   - **Heroicons** — "Tailwind ecosystem, outline/solid — `@heroicons/react`"
+   - **Radix Icons** — "15x15 grid, minimal — `@radix-ui/react-icons`"
+   - **Custom SVG** — "brand needs unique iconography"
+3. Container style — use `AskUserQuestion`:
+   - **Bare** — "icon only, no container"
+   - **Circle** — "rounded-full background"
+   - **Rounded square** — "rounded-lg background"
+   - **Brand-tinted** — "background uses brand color at low opacity"
+
+## Step 3: Define icon system
+
+- **Library:** package name, import path, version guidance
+- **Weight/stroke:** global standardization (e.g., strokeWidth={1.5})
+- **Size system:**
+
+| Use case | Size | Example |
+|----------|------|---------|
+| Inline text | 16px | breadcrumbs, metadata |
+| Default UI | 20px | nav items, buttons |
+| Feature | 24px | feature cards, lists |
+| Hero | 32px+ | hero sections, empty states |
+
+- **Container treatment:** CSS/Tailwind for each container style
+- **Color rules:** when to use foreground, brand color, muted, multi-color
+- **Custom SVG specs:** grid (24x24), stroke cap/join, corner radius, export format
+
+## Step 4: Write output + completion
+
+Write `iconography.md` chunk or update iconography section of `imagery-style.md`. Target: 60-90 lines.
+</process>

package/gsp/skills/gsp-icons/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-launch/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: launch
+name: gsp-launch
 description: Create launch and marketing assets
 user-invocable: true
 model: opus
@@ -27,7 +27,6 @@ Create marketing campaign assets for product launch.
 </objective>
 
 <execution_context>
-@${CLAUDE_SKILL_DIR}/../../prompts/04-marketing-asset-factory.md
 @${CLAUDE_SKILL_DIR}/../../templates/phases/launch.md
 </execution_context>
 
@@ -73,7 +72,7 @@ Pass in the agent prompt:
 - **Content of** strategy voice-and-tone.md + messaging.md (loaded in Step 1)
 - **Content of** all design screen chunks (loaded in Step 1)
 - **Content of** BRIEF.md (loaded in Step 1)
-- The Marketing Asset Factory prompt (04), launch output template (from execution_context)
+- Launch output template (from execution_context)
 - **Output path:** `{PROJECT_PATH}/launch/`
 
 The agent writes chunks directly:
@@ -94,5 +93,5 @@ Update `{PROJECT_PATH}/STATE.md`:
 
 ## Step 4: Phase transition output
 
-Render phase transition (see `references/phase-transitions.md`). This is the final phase.
+Invoke `/gsp-phase-transition` with phase `launch` and output directory `{PROJECT_PATH}/launch/`.
 </process>

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}/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 `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-logo/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-phase-transition/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: gsp-phase-transition
+description: "Render phase transition screens — pipeline progress, completion banner, file tree. Invoked by pipeline skills at phase completion."
+user-invocable: false
+model: sonnet
+allowed-tools:
+  - Read
+  - Glob
+---
+<context>
+Rendering utility invoked by pipeline skills at phase completion. Produces the visual transition — pipeline progress line, completion banner, file tree of outputs — then returns control to the calling skill for routing.
+
+The calling skill provides phase name and output directory. This skill reads STATE.md, renders the transition, and returns. The calling skill handles routing (AskUserQuestion, E2E auto-invoke, etc.) after this skill completes.
+</context>
+
+<objective>
+Render a phase transition screen showing pipeline progress, the completed phase, and output file tree.
+
+**Input:** Phase name + output directory path from the invoking skill
+**Output:** Terminal output with pipeline progress, completion banner, and file tree
+**Agent:** None — inline rendering
+</objective>
+
+<process>
+## Step 0: Parse invocation context
+
+The invoking skill provides:
+- **Phase name** — which phase just completed (e.g., "discover", "strategy", "build")
+- **Output directory** — path to the phase's output files
+
+Look up the completion message from the defaults table. If the invoking skill provided a custom message, use that instead.
+
+## Step 1: Read STATE.md
+
+Determine context by reading the brand or project STATE.md:
+- Which pipeline (branding or project)?
+- Which phases are complete?
+- Brand/project name?
+
+Use Glob to find STATE.md: `.design/branding/*/STATE.md` or `.design/projects/*/STATE.md`.
+
+## Step 2: Pipeline progress line (conditional)
+
+Show the pipeline line **only when 2+ phases are complete**. If this is the first phase completed, skip the pipeline line.
+
+### Styling
+
+- `◆` for completed phases
+- `◈` for next phase
+- `◇` for pending phases
+- `───` connecting phases
+
+```
+  {brand-or-project-name}
+  ◆ discover ─── ◆ strategy ─── ◈ identity ─── ◇ guidelines
+```
+
+### Branding phases
+
+`discover ─── strategy ─── identity ─── guidelines`
+
+If audit phase exists (evolve mode), prepend: `audit ─── `
+
+### Project phases
+
+`brief ─── research ─── design ─── critique ─── build ─── review`
+
+If launch is in scope, append: ` ─── launch`
+
+## Step 3: Completion banner + file tree
+
+```
+  ◆ {phase} complete — {completion_message}
+
+    {phase_dir}/
+    ├── {file1}.md
+    ├── {file2}.md
+    └── INDEX.md
+
+  ──────────────────────────────
+```
+
+Read the actual output directory to list real files.
+
+### File tree rules
+
+- Root is the phase directory name followed by `/`
+- Files sorted alphabetically, directories first
+- INDEX.md always listed last
+- Use `├──` for all items except the last, which uses `└──`
+- Subdirectories show their contents with `│` continuation
+
+### Final phase
+
+If all phases in the pipeline are complete, add `  fully pretty.` after the divider.
+
+## Default completion messages
+
+### Branding
+
+| Phase | Message |
+|-------|---------|
+| audit | brand assessed |
+| discover | market landscape mapped |
+| strategy | brand platform defined |
+| identity | visual system designed |
+| guidelines | design system built |
+
+### Project
+
+| Phase | Message |
+|-------|---------|
+| brief | project scoped |
+| research | patterns and approaches researched |
+| design | screens designed |
+| critique | designs critiqued |
+| build | code implemented |
+| review | implementation validated |
+| launch | campaign assets created |
+
+## Step 4: Return
+
+Return control to the calling skill. Do NOT present routing options — the calling skill owns routing.
+</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>