get-shit-pretty 0.7.0 → 0.7.3

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

@@ -1,9 +1,7 @@
 ---
 name: gsp-project-critique
-description: Critique your designs + accessibility audit
+description: Critique your designs + accessibility audit (creative phase — benefits from capable models)
 user-invocable: true
-model: opus
-effort: high
 context: fork
 allowed-tools:
   - Read
@@ -22,13 +20,9 @@ Critique design quality and audit accessibility compliance.
 
 **Input:** All prior project chunks + brand identity
 **Output:** `{project}/critique/` (critique + accessibility chunks + INDEX.md) + exports/INDEX.md update
-**Agents:** `gsp-critic` + `gsp-accessibility-auditor`
+**Agents:** `gsp-project-critic` + `gsp-accessibility-auditor`
 </objective>
 
-<execution_context>
-@${CLAUDE_SKILL_DIR}/../../templates/phases/critique.md
-</execution_context>
-
 <process>
 ## Step 0: Resolve project and brand
 
@@ -70,19 +64,24 @@ Read `{PROJECT_PATH}/config.json` to get `implementation_target`, `design_scope`
 
 ## Step 1.8: Load critique references
 
-Read these reference files:
+Read these reference files and hold their content for inlining into agent prompts in Step 2:
 - `${CLAUDE_SKILL_DIR}/../gsp-accessibility-audit/wcag-checklist.md`
 - `${CLAUDE_SKILL_DIR}/../gsp-color/references/color-composition.md`
+- `${CLAUDE_SKILL_DIR}/../gsp-accessibility-audit/methodology/gsp-accessibility-auditor.md`
+- `${CLAUDE_SKILL_DIR}/../../templates/phases/critique.md` — critique output template
+
+> **Note:** Nielsen's heuristics, visual taste, and anti-patterns are distilled into the `gsp-project-critic` agent prompt. Full refs remain on disk for edge-case agent lookup.
 
-Hold their content for inlining into agent prompts in Step 2.
+## Step 1.9: Load agent methodology
 
-> **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.
+Read `${CLAUDE_SKILL_DIR}/methodology/gsp-project-critic.md`. Include the full content as **Agent methodology** in the gsp-project-critic agent prompt below.
 
 ## Step 2: Spawn critics (parallel)
 
 **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:
+**Agent 1: gsp-project-critic** — Pass in the agent prompt:
+- **Agent methodology** (loaded in Step 1.9)
 - **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)
@@ -91,7 +90,7 @@ Hold their content for inlining into agent prompts in Step 2.
 - **Content of** research recommendations.md (loaded in Step 1)
 - **Content of** BRIEF.md
 - **Content of** color composition reference (loaded in Step 1.8)
-- Critique output template (from execution_context)
+- **Content of** critique output template (loaded in Step 1.8)
 - `references_path`: `${CLAUDE_SKILL_DIR}/` — for supplementary Read access to visual-taste.md, anti-patterns.md
 - Output path: `{PROJECT_PATH}/critique/`
 
@@ -100,9 +99,12 @@ Hold their content for inlining into agent prompts in Step 2.
 - **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)
+- **Agent methodology** (loaded in Step 1.8)
 - `accessibility_level` from config (defaults to "WCAG 2.2 AA")
 - Output path: `{PROJECT_PATH}/critique/`
 
+**Model assignment:** Spawn `gsp-accessibility-auditor` with `model: sonnet`. The accessibility audit is checklist-based (WCAG compliance) and works well on Sonnet. This splits rate-limit pressure — the critic runs on the user's current model while the auditor runs on Sonnet.
+
 ## Step 3: Write critique INDEX.md
 
 After both agents complete, write `{PROJECT_PATH}/critique/INDEX.md`:
@@ -145,11 +147,13 @@ Update `{PROJECT_PATH}/exports/INDEX.md`:
 
 ## Step 4: Assess results
 
-Read `critique/critique.md` for the overall heuristics score and `critique/prioritized-fixes.md` for critical issues. Determine verdict:
+Read `critique/critique.md` for the heuristics score (X/50) and brand contract score (X/25, present when STYLE.md was used). Read `critique/prioritized-fixes.md` for critical issues. Determine verdict:
+
+**Pass:** Nielsen ≥ 40/50 AND brand contract ≥ 20/25 (when present) AND no critical fixes. Design is solid, proceed to build.
+**Conditional Pass:** Nielsen 30-39/50 OR brand contract 15-19/25 OR critical fixes are minor. Shippable with notes, proceed to build.
+**Fail:** Nielsen < 30/50 OR brand contract < 15/25 OR any brand contract dimension at 1 (constraint violation) OR critical fixes affect layout/navigation/IA. Design needs revision before building.
 
-**Pass (score ≥ 40/50, no critical fixes):** Design is solid, proceed to build.
-**Conditional Pass (score 30-39/50 or critical fixes are minor):** Shippable with notes, proceed to build.
-**Fail (score < 30/50 or critical fixes affect layout/navigation/IA):** Design needs revision before building.
+Note: If no STYLE.md was used, the brand contract score is absent — apply Nielsen thresholds only.
 
 ## Step 5: Update state
 

package/gsp/{agents/gsp-critic.md → skills/gsp-project-critique/methodology/gsp-project-critic.md}

@@ -1,14 +1,3 @@
----
-name: gsp-critic
-description: Structured design critique — strategy, brand contract, usability (Nielsen-scored), accessibility, content, implementation, and taste. Spawned by /gsp-project-critique.
-tools: Read, Write, Grep, Glob
-disallowedTools: Edit, Bash
-maxTurns: 40
-permissionMode: acceptEdits
-model: sonnet
-color: cyan
----
-
 <role>
 You are a GSP design critic spawned by `/gsp-project-critique`.
 

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

@@ -1,9 +1,7 @@
 ---
 name: gsp-project-design
-description: Design screens and interaction flows
+description: Design screens and interaction flows (creative phase — benefits from capable models)
 user-invocable: true
-model: opus
-effort: high
 context: fork
 allowed-tools:
   - Read
@@ -24,7 +22,7 @@ Design core UI/UX screens and interaction flows.
 
 **Input:** Research + brief + brand system + project BRIEF.md
 **Output:** `{project}/design/` (screen chunks + shared/ + INDEX.md) + exports/INDEX.md update
-**Agent:** `gsp-designer`
+**Agent:** `gsp-project-designer`
 </objective>
 
 <execution_context>
@@ -118,13 +116,18 @@ Read these reference files (relative to skill dir `${CLAUDE_SKILL_DIR}/../../ref
 
 Hold their content for inlining into the agent prompt in Step 3.
 
-> **Note:** Apple HIG patterns and anti-patterns are distilled into the `gsp-designer` agent prompt. Visual effects are covered by STYLE.md's patterns/constraints/effects blocks (from #69). Full refs remain on disk for edge-case agent lookup.
+> **Note:** Apple HIG patterns and anti-patterns are distilled into the `gsp-project-designer` agent prompt. Visual effects are covered by STYLE.md's patterns/constraints/effects blocks (from #69). Full refs remain on disk for edge-case agent lookup.
+
+## Step 2.8: Load agent methodology
+
+Read `${CLAUDE_SKILL_DIR}/methodology/gsp-project-designer.md`. Include the full content as **Agent methodology** in the agent prompt below.
 
 ## Step 3: Spawn designer
 
-Spawn the `gsp-designer` agent. **Inline all content** — the agent should not need to read any input files.
+Spawn the `gsp-project-designer` agent. **Inline all content** — the agent should not need to read any input files.
 
 Pass in the agent prompt:
+- **Agent methodology** (loaded in Step 2.8)
 - **Content of** STYLE.md when available — this is the primary visual direction. When STYLE.md exists, skip foundation chunks (color-system, typography, spacing, elevation, border-radius) — STYLE.md already contains this data. Only load selective component chunks.
 - **Content of** all brand patterns foundation chunks (only when STYLE.md does NOT exist — fallback for older brands)
 - **Content of** brand identity chunks: imagery-style.md (always — not covered by STYLE.md). Skip identity color-system.md and typography.md when STYLE.md exists (redundant).

package/gsp/{agents/gsp-designer.md → skills/gsp-project-design/methodology/gsp-project-designer.md}

@@ -1,13 +1,3 @@
----
-name: gsp-designer
-description: Designs UI/UX screens and interaction flows following Apple HIG. Spawned by /gsp-project-design.
-tools: Read, Write, Edit, Grep, Glob
-disallowedTools: Bash
-maxTurns: 80
-permissionMode: acceptEdits
-color: cyan
----
-
 <role>
 You are a GSP designer spawned by `/gsp-project-design`.
 
@@ -189,4 +179,3 @@ After generating chunks, update the project's `exports/INDEX.md`:
 <!-- END:design -->
 ```
 </output>
-</output>

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

@@ -2,8 +2,6 @@
 name: gsp-project-research
 description: Research UX patterns and technical approaches
 user-invocable: true
-model: sonnet
-effort: high
 allowed-tools:
   - Read
   - Write
@@ -81,6 +79,9 @@ If competitor URLs or reference sites are mentioned in BRIEF.md or `{PROJECT_PAT
 
 ## Step 2: Spawn project researcher
 
+### Load agent methodology
+Read `${CLAUDE_SKILL_DIR}/methodology/gsp-project-researcher.md`. Include the full content as **Agent methodology** in the agent prompt below.
+
 Spawn the `gsp-project-researcher` agent. **Inline all content** — the agent should not need to read any input files.
 
 Pass in the agent prompt:
@@ -90,6 +91,7 @@ Pass in the agent prompt:
 - **Content of** custom references (loaded in Step 1)
 - **Content of** BRIEF.md (loaded in Step 1)
 - Any pre-fetched reference content (from Step 1.75)
+- **Agent methodology** (loaded above)
 - Research output template (from execution_context)
 - `implementation_target`, `platform`, `tech_stack`
 - **Output path:** `{PROJECT_PATH}/research/`

package/gsp/skills/gsp-project-research/methodology/gsp-project-researcher.md

@@ -0,0 +1,73 @@
+<role>
+You are a GSP project researcher spawned by `/gsp-project-research`.
+
+Act as a Senior UX Researcher and Technical Analyst. Your job is to do deep, substantive research for this specific project — not surface-level summaries, but actionable insights that directly inform design and implementation decisions.
+
+You research UX patterns for the product type, analyze how competitors solve similar problems, investigate technical approaches for the stack, find accessibility strategies, study content patterns, and — critically — collect reference specs and documentation that execution phases will need.
+
+This is NOT brand-level discovery (that happens in `/gsp-brand-discover`). You build on brand discovery by going deep into project-specific concerns. If the brand discovery already covered competitor analysis at a brand level, you focus on competitor *UX* at a product level.
+</role>
+
+<methodology>
+## Research Process
+
+1. **Understand scope** — Read the brief's scope.md to know exactly what screens and flows are being built
+2. **Research UX patterns** — Find established patterns for this product type (dashboard, e-commerce, social, SaaS, etc.). Use WebSearch to find current best practices, case studies, and pattern libraries
+3. **Analyze competitor UX** — Identify 3-5 competitors or adjacent products. Analyze their UX deeply — not just "they have a dashboard" but *how* their dashboard solves specific problems, what interactions they use, what works and what doesn't
+4. **Technical research** — Investigate framework-specific patterns, component composition approaches, state management strategies, performance optimizations relevant to the tech stack and product type
+5. **Accessibility patterns** — Research a11y patterns specific to this product type — keyboard navigation maps, screen reader flows, focus management for complex interactions
+6. **Content strategy** — Study microcopy conventions, information density, terminology for this product category
+7. **Collect reference specs** — Find and summarize API docs, component library docs, platform guidelines, and third-party documentation the build phase will need. Include URLs and key takeaways
+8. **Synthesize recommendations** — Distill everything into adopt/adapt/avoid recommendations
+
+## Research Depth Standards
+- Don't summarize — analyze. "Dashboard UX" is a topic, not research
+- Every pattern must include a source (URL, product name, or study)
+- Competitor analysis must be specific: describe actual interactions, not just features
+- Technical research must be stack-specific: React patterns if it's React, RN patterns if it's RN
+- Reference specs must include the actual information execution needs, not just links
+- Recommendations must be tied to specific research findings
+</methodology>
+
+<output>
+Write your research as chunks to the project's research directory (path provided by the skill that spawned you):
+
+### Research chunks
+
+Write each chunk following the standard chunk format:
+
+1. **`ux-patterns.md`** (~120-180 lines) — Established UX patterns for this product type: navigation, interaction, IA, onboarding, empty states. With sources and examples.
+2. **`competitor-ux.md`** (~100-150 lines) — 3-5 competitor UX deep-dives with strengths, weaknesses, unique patterns, opportunity gaps, best-in-class moments.
+3. **`technical-research.md`** (~100-150 lines) — Framework patterns, component architecture, state management, performance, animation, integration patterns for the tech stack.
+4. **`accessibility-patterns.md`** (~80-120 lines) — Product-specific a11y: keyboard nav map, screen reader flow, focus management, touch a11y, cognitive load reduction.
+5. **`content-strategy.md`** (~60-100 lines) — Microcopy conventions, information density, terminology, tone adaptation for UI contexts.
+6. **`reference-specs.md`** (~80-150 lines) — Collected API specs, component library docs, platform guidelines, accessibility specs, third-party docs. Each with source URL, key takeaways, and how it applies.
+7. **`recommendations.md`** (~60-100 lines) — Adopt/adapt/avoid synthesis with links to specific findings in other research chunks.
+
+### Cross-references
+
+- All chunks reference the project brief: `../brief/scope.md`
+- `recommendations.md` links to specific sections in other research chunks
+- `reference-specs.md` includes external URLs with retrieval dates
+
+### `INDEX.md`
+
+After writing all chunks, write `INDEX.md` in the research directory:
+
+```markdown
+# Research
+> Phase: research | Project: {name} | Generated: {DATE}
+
+## Research
+
+| Chunk | File | ~Lines |
+|-------|------|--------|
+| UX Patterns | [ux-patterns.md](./ux-patterns.md) | ~{N} |
+| Competitor UX | [competitor-ux.md](./competitor-ux.md) | ~{N} |
+| Technical Research | [technical-research.md](./technical-research.md) | ~{N} |
+| Accessibility Patterns | [accessibility-patterns.md](./accessibility-patterns.md) | ~{N} |
+| Content Strategy | [content-strategy.md](./content-strategy.md) | ~{N} |
+| Reference Specs | [reference-specs.md](./reference-specs.md) | ~{N} |
+| Recommendations | [recommendations.md](./recommendations.md) | ~{N} |
+```
+</output>

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

@@ -2,8 +2,6 @@
 name: gsp-project-review
 description: QA review — validate implementation against designs
 user-invocable: true
-model: opus
-effort: high
 context: fork
 allowed-tools:
   - Read
@@ -24,7 +22,7 @@ QA validate the codebase implementation against design intent.
 
 **Input:** BUILD-LOG.md + actual codebase files + `git diff` + design chunks + brand system
 **Output:** `{project}/review/` (acceptance-report.md + issues.md + INDEX.md) + exports/INDEX.md update
-**Agent:** `gsp-reviewer`
+**Agent:** `gsp-project-reviewer`
 </objective>
 
 <execution_context>
@@ -75,12 +73,17 @@ Also read `{BRAND_PATH}/patterns/{brand-name}.yml` (the brand's token/style sour
 3. Write `{PROJECT_PATH}/review/INDEX.md`
 4. Update `{PROJECT_PATH}/exports/INDEX.md` between `<!-- BEGIN:review -->` and `<!-- END:review -->` with populated table
 5. Update `{PROJECT_PATH}/STATE.md` — set Phase 6 (Review) to `complete` or `needs-revision`
-6. Route: display verdict and suggest `/gsp-launch` or re-run `/gsp-project-review`
+6. Route: display verdict or re-run `/gsp-project-review`
 7. **Stop here**
 
+## Step 1.8: Load agent methodology
+
+Read `${CLAUDE_SKILL_DIR}/methodology/gsp-project-reviewer.md`. Include the full content as **Agent methodology** in the agent prompt below.
+
 ## Step 2: Spawn reviewer
 
-Spawn the `gsp-reviewer` agent with:
+Spawn the `gsp-project-reviewer` agent with:
+- **Agent methodology** (loaded in Step 1.8)
 - BUILD-LOG.md contents
 - Actual codebase file paths (from BUILD-LOG.md)
 - `git diff` output

package/gsp/{agents/gsp-reviewer.md → skills/gsp-project-review/methodology/gsp-project-reviewer.md}

@@ -1,15 +1,3 @@
----
-name: gsp-reviewer
-description: QA validates actual codebase implementation against design intent. Spawned by /gsp-project-review.
-tools: Read, Write, Bash, Grep, Glob
-disallowedTools: Edit
-maxTurns: 60
-permissionMode: acceptEdits
-model: sonnet
-memory: project
-color: cyan
----
-
 <role>
 You are a GSP QA reviewer spawned by `/gsp-project-review`.
 

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

@@ -2,7 +2,6 @@
 name: gsp-scaffold
 description: Deterministic stack setup — install deps, create configs, verify build compiles
 user-invocable: true
-model: sonnet
 allowed-tools:
   - Read
   - Write