get-shit-pretty 0.7.0 → 0.7.1

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

@@ -2,7 +2,6 @@
 name: gsp-progress
 description: How pretty are we?
 user-invocable: true
-model: sonnet
 allowed-tools:
   - Read
   - Glob

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

@@ -2,12 +2,10 @@
 name: gsp-project-brief
 description: Scope what you're building
 user-invocable: true
-model: sonnet
 allowed-tools:
   - Read
   - Write
   - Bash
-  - Agent
   - Grep
   - Glob
 ---
@@ -24,7 +22,6 @@ Scope the project and plan adaptations from the brand system.
 
 **Input:** Brand system (via brand.ref) + project BRIEF.md + config.json
 **Output:** `{project}/brief/` (scope.md, target-adaptations.md, conditionals, INDEX.md)
-**Agent:** `gsp-scoper`
 </objective>
 
 <execution_context>
@@ -77,30 +74,62 @@ Suggest to the user:
 
 If the project scope feels large, suggest breaking it into multiple bounded issues — each one a focused deliverable that can be reviewed independently.
 
-## Step 2: Spawn scoper
+## Step 2: Scope the project
 
-Spawn the `gsp-scoper` agent. **Inline all content** — the agent should not need to read any input files.
-
-Pass in the agent prompt:
-- **Content of** brand patterns foundation + component chunks (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)
-- Brief output template (from execution_context)
-- `implementation_target`, `design_scope`, `codebase_type`
-- **Output path:** `{PROJECT_PATH}/brief/`
+Using all context loaded in Step 1, scope the project directly. Act as a Senior Design Project Lead bridging the brand system and the project's specific needs.
 
 If any sibling project is active and its scope overlaps with this project, flag it: "⚠️ {name} is actively working on {scope}. Coordinate to avoid conflicts."
 If this project modifies components from a sibling's manifest, note provenance.
 
-The agent writes chunks directly:
-- `brief/scope.md`
-- `brief/target-adaptations.md`
-- `brief/install-manifest.md` (shadcn/rn-reusables)
-- `brief/gap-analysis.md` (existing target)
-- `brief/file-references.md` (existing target)
-- `brief/INDEX.md`
+### Scoping process
+
+1. **Analyze brief** — what's being built, for whom, on what platforms
+2. **Define screen list** — prioritized screens from brief, user flows, success criteria
+3. **Map component scope** — which brand system components this project needs
+4. **Identify adaptations** — project-specific variants, overrides, or extensions to brand components
+5. **Map to implementation target** — connect design components to target primitives (shadcn, rn-reusables, existing, code)
+6. **Gap analysis** (existing codebases) — what's in the brand system but missing from the codebase
+7. **Generate install manifest** (shadcn/rn-reusables) — install commands for needed components
+8. **Issue framing** — suggest how to break the project into bounded, shippable issues
+
+### Quality standards
+
+- Every screen has a clear purpose and priority level
+- Component adaptations reference specific brand system components
+- Gap analysis is concrete (component names, token names)
+- Install manifests are copy-paste ready
+- Scope boundaries are explicit (what's in, what's out)
+
+### Write chunks to `{PROJECT_PATH}/brief/`
+
+Use the brief output template from execution_context for chunk formatting.
+
+1. **`scope.md`** (~80-120 lines) — prioritized screen list, component scope, project boundaries, success criteria, dependencies, issue framing
+2. **`target-adaptations.md`** (~60-100 lines) — token overrides, component adaptations, platform considerations, implementation target mapping
+3. **`install-manifest.md`** (shadcn/rn-reusables only) — install commands for all needed components
+4. **`gap-analysis.md`** (existing target only) — components/tokens in brand system but not in codebase
+5. **`file-references.md`** (existing target only) — paths to existing components/tokens being used
+
+Cross-references: `target-adaptations.md` links to `{BRAND_PATH}/patterns/components/{name}.md`; `gap-analysis.md` links to brand system components and tokens; `scope.md` references the project BRIEF.md.
+
+### Write `INDEX.md`
+
+```markdown
+# Brief
+> Phase: brief | Project: {name} | Generated: {DATE}
+
+## Scoping
+
+| Chunk | File | ~Lines |
+|-------|------|--------|
+| Scope | [scope.md](./scope.md) | ~{N} |
+| Target Adaptations | [target-adaptations.md](./target-adaptations.md) | ~{N} |
+| Install Manifest | [install-manifest.md](./install-manifest.md) | ~{N} |
+| Gap Analysis | [gap-analysis.md](./gap-analysis.md) | ~{N} |
+| File References | [file-references.md](./file-references.md) | ~{N} |
+```
+
+Only include rows for chunks that were actually produced.
 
 ## Step 3: Write exports
 

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

@@ -1,9 +1,7 @@
 ---
 name: gsp-project-build
-description: Translate designs to code
+description: Translate designs to code (technical phase — benefits from capable models)
 user-invocable: true
-model: opus
-effort: high
 allowed-tools:
   - Read
   - Write
@@ -24,7 +22,7 @@ Works with the dual-diamond architecture: reads brand system from `.design/brand
 Phase 1: SCAFFOLD (skill-level, no agent)
   └─ /gsp-scaffold → verify build passes
 
-Phase 2: FOUNDATIONS (agent: gsp-builder mode:foundations)
+Phase 2: FOUNDATIONS (agent: gsp-project-builder mode:foundations)
   ├─ 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
@@ -32,7 +30,7 @@ Phase 2: FOUNDATIONS (agent: gsp-builder mode:foundations)
 Phase 3: FOUNDATION REVIEW (interactive)
   └─ Present summary → user confirms
 
-Phase 4: SCREENS (agent: gsp-builder mode:screen, one per screen)
+Phase 4: SCREENS (agent: gsp-project-builder mode:screen, one per screen)
   ├─ Context per screen: its design chunk + referenced components only
   ├─ Agent reads foundations from codebase (not from context)
   ├─ CHECKPOINT per screen: compile check
@@ -45,7 +43,7 @@ Implement designs as production-ready code in the codebase via phased pipeline w
 
 **Input:** Design chunks + research chunks + brief chunks + brand system chunks
 **Output:** Code in the codebase + `{project}/build/BUILD-LOG.md` + `{project}/build/SCAFFOLD-LOG.md`
-**Agent:** `gsp-builder` (spawned per phase with execution mode)
+**Agent:** `gsp-project-builder` (spawned per phase with execution mode)
 </objective>
 
 <execution_context>
@@ -113,19 +111,23 @@ After scaffold completes, verify `{PROJECT_PATH}/build/SCAFFOLD-LOG.md` exists.
 
 **Gate:** If scaffold reports build failure, stop and surface the error. Do not proceed to foundations with a broken build.
 
-## Step 2.5: Load build references
+## Step 2.5: Load agent methodology
+
+Read `${CLAUDE_SKILL_DIR}/methodology/gsp-project-builder.md`. Include the full content as **Agent methodology** in all agent prompts below (Steps 3, 5, 7, 8).
+
+## Step 2.6: Load build references
 
 Read these reference files:
 - `${CLAUDE_SKILL_DIR}/visual-effects.md`
 - `${CLAUDE_SKILL_DIR}/../gsp-project-design/block-patterns.md`
 
-Hold their content for inlining into agent prompts in Steps 3 and 5.
+Hold their content for inlining into agent prompts in Steps 3, 5, 7, and 8.
 
-> **Note:** Anti-patterns are distilled into the `gsp-builder` agent prompt. Full ref remains on disk for edge-case agent lookup.
+> **Note:** Anti-patterns are distilled into the `gsp-project-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**.
+Spawn `gsp-project-builder` agent with **execution_mode: foundations**.
 
 ### Context for foundations agent (lean — no screen chunks):
 
@@ -139,7 +141,8 @@ Spawn `gsp-builder` agent with **execution_mode: foundations**.
 | `.design/system/COMPONENTS.md` | Existing components (if exists) |
 | `{PROJECT_PATH}/config.json` | Tech stack, target |
 | Build output template (from execution_context) | Build log structure |
-| Visual effects, block patterns refs (loaded in Step 2.5) | Design patterns + CSS recipes |
+| Visual effects, block patterns refs (loaded in Step 2.6) | Design patterns + CSS recipes |
+| Agent methodology (loaded in Step 2.5) | Builder role, process, quality standards |
 
 ### Agent instructions:
 
@@ -237,7 +240,8 @@ Build screens sequentially. For each screen in `SCREENS`:
 | `{PROJECT_PATH}/research/reference-specs.md` (if exists) | Technical specs |
 | `{PROJECT_PATH}/critique/prioritized-fixes.md` (if exists) | Critique fixes relevant to this screen |
 | Build output template (from execution_context) | Build log structure |
-| Visual effects, block patterns refs (loaded in Step 2.5) | Design patterns + CSS recipes |
+| Visual effects, block patterns refs (loaded in Step 2.6) | Design patterns + CSS recipes |
+| Agent methodology (loaded in Step 2.5) | Builder role, process, quality standards |
 
 **Does NOT receive:** other screen chunks, brand `.yml` (already integrated into codebase), full brand system, research monoliths.
 
@@ -359,11 +363,11 @@ Invoke `/gsp-phase-transition` with phase `build` and output directory `{PROJECT
 
 ## Step 7: Figma fallback
 
-For `implementation_target: figma`, skip the phased pipeline. Spawn a single `gsp-builder` agent with execution_mode: `full` and spec-only flag. Builder writes `build/CODE.md` + `build/components/` instead of editing codebase. Then continue from Step 6 (finalize).
+For `implementation_target: figma`, skip the phased pipeline. Spawn a single `gsp-project-builder` agent with execution_mode: `full` and spec-only flag. Builder writes `build/CODE.md` + `build/components/` instead of editing codebase. Then continue from Step 6 (finalize).
 
 ## Step 8: Revision mode
 
-For `needs-revision` status, spawn a single `gsp-builder` agent with execution_mode: `full` and `review/issues.md` contents. The agent fixes QA issues in the codebase and appends revision sections to BUILD-LOG.md.
+For `needs-revision` status, spawn a single `gsp-project-builder` agent with execution_mode: `full` and `review/issues.md` contents. The agent fixes QA issues in the codebase and appends revision sections to BUILD-LOG.md.
 
 ### Brand feedback on revisions
 

package/gsp/{agents/gsp-builder.md → skills/gsp-project-build/methodology/gsp-project-builder.md}

@@ -1,19 +1,3 @@
----
-name: gsp-builder
-description: Implements designs in the codebase as production-ready frontend code. Spawned by /gsp-project-build.
-tools: Read, Write, Edit, Bash, Grep, Glob
-maxTurns: 100
-permissionMode: acceptEdits
-memory: project
-hooks:
-  PostToolUse:
-    - matcher: "Edit|Write"
-      hooks:
-        - type: command
-          command: "${CLAUDE_PROJECT_ROOT}/scripts/lint-check.sh"
-color: cyan
----
-
 <role>
 You are a GSP builder spawned by `/gsp-project-build`.
 

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,6 +99,7 @@ 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/`
 

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