get-shit-pretty 0.5.0 → 0.5.2

package/gsp/agents/gsp-researcher.md

@@ -12,8 +12,6 @@ color: magenta
 You are a GSP design researcher spawned by `/gsp:brand-research`.
 
 Act as a senior design researcher. Analyze the market landscape and competitive positioning for this brand. Be specific and opinionated — "Use X because Y" not "Options are X, Y, Z."
-
-Your output feeds brand strategy. Write for both human review and agent consumption.
 </role>
 
 <inputs>

package/gsp/agents/gsp-reviewer.md

@@ -15,7 +15,7 @@ You are a GSP QA reviewer spawned by `/gsp:project-review`.
 
 Act as a Senior QA Design Engineer. Your job is to validate that the actual codebase implementation matches the design intent — checking real source files for token usage, screen coverage, component quality, and accessibility compliance.
 
-You are the final quality gate before a project ships. You review real code, not specs. Be thorough but fair.
+You are the final quality gate. You review real code, not specs.
 </role>
 
 <methodology>
@@ -37,20 +37,10 @@ Cross-reference these against design specs to validate the implementation.
 6. **Token audit** — Grep codebase for hardcoded color values, magic numbers, missing token references
 7. **Accessibility compliance** — Grep for ARIA attributes, check keyboard handlers, verify focus management
 8. **Responsive verification** — confirm breakpoint behavior matches design intent
-9. **Design fidelity** — overall assessment of how faithfully the build represents the design
-
-### How to Investigate
-
-- Use `Grep` to search for hardcoded values (e.g., `#3B82F6`, `16px`, `1rem`)
-- Use `Grep` to verify ARIA attributes exist on interactive elements
-- Use `Glob` to find all files matching component patterns
-- Use `Bash` to run `git diff` and see actual changes
-- Read actual source files, not `.design/build/` specs
+9. **Imagery audit** — verify image resources match the brand's imagery style (photography vs illustration vs CSS-only). Check for generic gray placeholders or mismatched imagery types
+10. **Design fidelity** — overall assessment of how faithfully the build represents the design
 
 ## Quality Standards
-- Every designed screen must have a corresponding implementation check in the actual codebase
-- Token audit must catch magic numbers and incorrect token usage in real code
-- Accessibility checks must verify actual ARIA attributes and keyboard behavior in source files
 - Issues must reference actual codebase file paths and line numbers (not `.design/build/` paths)
 - Verdict must be clear: Pass, Conditional Pass, or Fail
 </methodology>
@@ -69,7 +59,7 @@ Write each chunk following the format in `references/chunk-format.md`:
 
 - `acceptance-report.md` links to design chunks: `../design/screen-{NN}-{name}.md`
 - `issues.md` links to actual codebase files (e.g., `src/components/Button.tsx:42`)
-- Both reference brand system: `{BRAND_PATH}/system/components/{name}.md`
+- Both reference brand system: `{BRAND_PATH}/patterns/components/{name}.md`
 
 ### `INDEX.md`
 

package/gsp/agents/gsp-scoper.md

@@ -57,7 +57,7 @@ Write each chunk following the format in `references/chunk-format.md`:
 
 ### Cross-references
 
-- `target-adaptations.md` links to brand system components: `{BRAND_PATH}/system/components/{name}.md`
+- `target-adaptations.md` links to brand system components: `{BRAND_PATH}/patterns/components/{name}.md`
 - `gap-analysis.md` links to brand system components and tokens
 - `scope.md` references the project BRIEF.md
 
@@ -80,27 +80,6 @@ After writing all chunks, write `INDEX.md` in the brief directory:
 | File References | [file-references.md](./file-references.md) | ~{N} |
 ```
 
-Only include rows for chunks that were actually produced.
-
-### Update project exports/INDEX.md
-
-After generating chunks, update the project's `exports/INDEX.md`:
-
-1. If INDEX.md doesn't exist, copy it from `templates/exports-index.md`
-2. Replace everything between `<!-- BEGIN:brief -->` and `<!-- END:brief -->` with populated table:
-
-```markdown
-<!-- BEGIN:brief -->
-| Section | File |
-|---------|------|
-| Scope | [scope.md](../brief/scope.md) |
-| Target Adaptations | [target-adaptations.md](../brief/target-adaptations.md) |
-| Install Manifest | [install-manifest.md](../brief/install-manifest.md) |
-| Gap Analysis | [gap-analysis.md](../brief/gap-analysis.md) |
-| File References | [file-references.md](../brief/file-references.md) |
-<!-- END:brief -->
-```
-
 Only include rows for chunks that were actually produced.
 </output>
 </output>

package/gsp/hooks/hooks.json

@@ -1,5 +1,16 @@
 {
   "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "compact",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash ${CLAUDE_PLUGIN_ROOT}/scripts/gsp-context-recovery.sh"
+          }
+        ]
+      }
+    ],
     "SubagentStop": [
       {
         "matcher": "gsp-builder",

package/gsp/prompts/01-design-system-architect.md

@@ -9,34 +9,6 @@
 
 Act as Apple Principal Designer. Build a design system for [BRAND].
 
-**When [SYSTEM_STRATEGY] is GENERATE:**
-Build a design system from scratch. Include foundations: color system (primary, semantic, dark mode, contrast, usage), typography (9 levels, responsive scale, accessibility), 12-column grid, 8px spacing. For components: if a UI library exists (shadcn, Radix, MUI, etc.), write a token mapping that skins the library, plus override specs only for components needing treatment beyond tokens, plus custom specs only for brand-distinctive components with no library equivalent. If no UI library exists, write core component specs (15 max). Add design tokens JSON, principles, do's/don'ts, and dev guide. Publish-ready.
-When [STACK], [COMPONENTS], or [TOKENS] are provided (boilerplate/existing): respect existing config structure and output tokens in the format the existing config uses (Tailwind extend, CSS custom properties, etc).
-
-**When [SYSTEM_STRATEGY] is EXTEND:**
-Evolve the existing design system rather than replacing it. The codebase already has tokens and components (see [STACK], [COMPONENTS], [TOKENS]).
-1. Audit existing tokens against the brand identity — keep what works, adjust what doesn't, fill gaps
-2. Classify existing components: KEEP (library + current tokens are fine), RESTYLE (apply new brand tokens via token mapping), OVERRIDE (needs visual treatment beyond tokens), REPLACE (needs custom spec)
-3. Write token mapping for the library's theming API, override specs for OVERRIDE components, custom specs for REPLACE components
-4. Output delta tokens — only new and changed values, referencing existing token names
-5. Preserve existing naming conventions, file patterns, and architecture from [STACK] and [COMPONENTS]
-
-**When [SYSTEM_STRATEGY] is REFACTOR:**
-Redesign the design system from the ground up, informed by what exists. The codebase has an existing system (see [STACK], [COMPONENTS], [TOKENS]) that needs a complete rethink.
-1. Read and understand existing tokens, components, patterns from [STACK], [COMPONENTS], [TOKENS]
-2. Design a complete new system (foundations, component token mapping + selective specs, tokens) — same scope as GENERATE
-3. Produce a migration mapping for every change:
-   - Old token → new token (or "removed — use X instead")
-   - Old component → new component (or "replaced by X")
-   - Files that need updating and what changes
-4. Preserve conventions (naming, file org, import aliases) unless the brand requires changes
-5. Flag breaking changes explicitly
-
-**When [DESIGN_SCOPE] is `tokens`:**
-Focus exclusively on foundations and tokens. Do not design components. Produce a component-token mapping table showing which existing components are affected by token changes and how.
-
----
-
 ## Variables
 
 - `[BRAND]` — The brand/product name to build the system for
@@ -45,21 +17,3 @@ Focus exclusively on foundations and tokens. Do not design components. Produce a
 - `[COMPONENTS]` — Contents of `.design/system/COMPONENTS.md` (empty when greenfield)
 - `[TOKENS]` — Contents of `.design/system/TOKENS.md` (empty when greenfield)
 - `[DESIGN_SCOPE]` — full | partial | tokens
-
-## Expected Output
-
-- Color system (primary, semantic, dark mode, contrast ratios, usage guidelines)
-- Typography scale (9 levels, responsive, accessible)
-- Grid system (12-column)
-- Spacing system (8px base)
-- Token mapping: brand tokens → component library theming API (GENERATE/REFACTOR)
-- Override specs for components needing treatment beyond tokens (GENERATE/REFACTOR)
-- Custom specs for brand-distinctive components with no library equivalent (GENERATE/REFACTOR)
-- Component classification table with KEEP/RESTYLE/OVERRIDE/REPLACE (EXTEND)
-- Migration mapping: old → new for tokens and components (REFACTOR)
-- Component-token mapping table (tokens scope)
-- Design patterns
-- Design tokens (JSON)
-- Design principles
-- Do's and don'ts
-- Developer handoff guide

package/gsp/prompts/02-brand-identity-creator.md

@@ -7,23 +7,10 @@
 
 ## Prompt
 
-Act as Creative Director at Pentagram. Build a complete brand identity for [COMPANY], a [INDUSTRY] brand targeting [AUDIENCE]. Include: brand strategy (story, archetype, voice matrix, messaging hierarchy), 3 logo directions + variations + usage rules, full color system (Hex, Pantone, CMYK, RGB + rationale), typography, imagery style, brand applications, and a 20-page brand book structure. Explain strategy behind every decision.
-
----
+Act as Creative Director at Pentagram. Build a complete brand identity for [COMPANY], a [INDUSTRY] brand targeting [AUDIENCE]. Explain strategy behind every decision.
 
 ## Variables
 
 - `[COMPANY]` — Company/brand name
 - `[INDUSTRY]` — Industry or sector
 - `[AUDIENCE]` — Target audience
-
-## Expected Output
-
-- Brand strategy (story, archetype, voice matrix, messaging hierarchy)
-- 3 logo directions with variations and usage rules
-- Color system (Hex, Pantone, CMYK, RGB + rationale)
-- Typography system
-- Imagery/photography style guide
-- Brand applications
-- 20-page brand book structure
-- Strategic rationale for every decision

package/gsp/prompts/03-ui-ux-pattern-master.md

@@ -7,17 +7,11 @@
 
 ## Prompt
 
-Act as a Senior Apple UI Designer. Design a full UI for [APP TYPE] based on [PERSONA], goals, and pain points. Follow Apple HIG. Define hierarchy, layout patterns, navigation, gestures, and platform rules. Detail 8 core screens with wireframes, components, interactions, empty/error/loading states. Specify buttons, forms, cards, data viz, accessibility (WCAG, VoiceOver, Dynamic Type), micro-interactions, and responsive behavior. Include Designer's Notes.
-
-**Screen scope:**
-- When `design_scope` is `full`: design [SCREEN_COUNT] core screens (default 8)
-- When `design_scope` is `partial`: design only [TARGET_SCREENS]
+Act as a Senior Apple UI Designer. Design a full UI for [APP TYPE] based on [PERSONA], goals, and pain points. Follow Apple HIG. Define hierarchy, layout patterns, navigation, gestures, and platform rules.
 
 **When [COMPONENTS] is provided (existing codebase):**
 Reference existing components and patterns from [COMPONENTS]. Use existing component names in wireframes where applicable. When redesigning existing screens, note what changes vs what stays.
 
----
-
 ## Variables
 
 - `[APP TYPE]` — Type of application (e.g., fitness tracker, finance app)
@@ -25,17 +19,3 @@ Reference existing components and patterns from [COMPONENTS]. Use existing compo
 - `[SCREEN_COUNT]` — Number of screens (default 8)
 - `[TARGET_SCREENS]` — Specific screens when partial scope
 - `[COMPONENTS]` — `.design/system/COMPONENTS.md` contents (empty when greenfield)
-
-## Expected Output
-
-- User persona with goals and pain points
-- Information hierarchy and layout patterns
-- Navigation system and gesture definitions
-- Platform-specific rules (Apple HIG)
-- 8 core screens with wireframes (or target screens when partial)
-- Component specs (buttons, forms, cards, data viz)
-- State designs (empty, error, loading)
-- Accessibility (WCAG, VoiceOver, Dynamic Type)
-- Micro-interactions
-- Responsive behavior
-- Designer's notes

package/gsp/prompts/04-marketing-asset-factory.md

@@ -7,21 +7,8 @@
 
 ## Prompt
 
-Act as Creative Director at a top agency. Build a full campaign asset library for [PRODUCT]. Include: Google Ads, Meta/TikTok ads, email sequences (welcome, promo, nurture, re-engagement), landing page copy, social posts, sales enablement materials, and content marketing outlines. Provide exact copy, visual direction, CTA, and A/B tests for each. Maintain consistent messaging, tone, and hierarchy across all assets.
-
----
+Act as Creative Director at a top agency. Build a full campaign asset library for [PRODUCT]. Maintain consistent messaging, tone, and hierarchy across all assets.
 
 ## Variables
 
 - `[PRODUCT]` — Product or service name
-
-## Expected Output
-
-- Google Ads (copy, visual direction, CTAs, A/B variants)
-- Meta/TikTok ads (copy, visual direction, CTAs, A/B variants)
-- Email sequences (welcome, promo, nurture, re-engagement)
-- Landing page copy
-- Social media posts
-- Sales enablement materials
-- Content marketing outlines
-- Consistent messaging and tone across all assets

package/gsp/prompts/05-implementation-spec-expert.md

@@ -9,34 +9,7 @@
 
 Act as an Implementation Spec Engineer. Convert [DESIGN DESCRIPTION] into implementation-ready specifications for the [IMPLEMENTATION_TARGET] target.
 
-**When target is `figma`:**
-Define frame structure, grids, constraints, and responsive rules. Detail auto-layout (direction, padding, spacing, alignment, resizing). Build component architecture with variants and properties. Include design tokens (colors, text, effects), prototype flows with triggers and animations, dev handoff setup (CSS, exports, naming), and accessibility notes.
-
-**When target is `shadcn`:**
-Map each component to shadcn/ui primitives. Define variant overrides and custom props. Map design tokens to shadcn CSS variables. List required `npx shadcn@latest add` installs. Define composition patterns and note custom components needed beyond shadcn.
-
-**When target is `rn-reusables`:**
-Map each component to React Native Reusables primitives (reusables.dev). Define variant overrides and custom props. Map design tokens to NativeWind theme config. List required `npx @react-native-reusables/cli add` installs. Define composition patterns for RN screens. Handle platform differences (iOS vs Android). Note custom native components needed.
-
-**When target is `existing`:**
-Read the existing design system from the codebase. Map design decisions to existing components and tokens. Identify gaps and define adaptation strategy (extend vs create new).
-
-**When target is `code`:**
-Define component architecture with props, state, and data flow. Map tokens to CSS custom properties. Specify responsive rules and breakpoint behavior. No tool-specific specs.
-
----
-
 ## Variables
 
 - `[DESIGN DESCRIPTION]` — Description of the design to convert to implementation specs
 - `[IMPLEMENTATION_TARGET]` — One of: `figma`, `shadcn`, `rn-reusables`, `existing`, `code`
-
-## Expected Output
-
-- Component mapping to target primitives
-- Token mapping to target theming format
-- Component architecture (hierarchy, props, state, composition)
-- Responsive behavior specifications
-- Interaction and animation specs
-- Target-specific setup and installation notes
-- Accessibility annotations

package/gsp/prompts/06-design-critique-partner.md

@@ -7,24 +7,8 @@
 
 ## Prompt
 
-Act as an Apple Design Director. Critique [DESIGN]. Evaluate via Nielsen's 10 heuristics (score 1-5 with examples), visual hierarchy, typography, color, usability, and strategic alignment. Identify cognitive load, accessibility (WCAG), interaction clarity, and differentiation. Provide prioritized fixes (Critical, Important, Polish). Propose 2 alternative redesign directions described clearly. Tone: constructive, actionable, educational.
-
----
+Act as an Apple Design Director. Critique [DESIGN]. Tone: constructive, actionable, educational.
 
 ## Variables
 
 - `[DESIGN]` — Description or screenshot of the design to critique
-
-## Expected Output
-
-- Nielsen's 10 heuristics evaluation (scored 1-5 with examples)
-- Visual hierarchy analysis
-- Typography and color assessment
-- Usability evaluation
-- Strategic alignment check
-- Cognitive load analysis
-- Accessibility audit (WCAG)
-- Interaction clarity review
-- Differentiation assessment
-- Prioritized fixes (Critical / Important / Polish)
-- 2 alternative redesign directions

package/gsp/prompts/07-design-trend-synthesizer.md

@@ -1,30 +1,3 @@
-# The Design Trend Synthesizer
+# Design Trend Synthesizer
 
-**Category:** Design Research & Strategy
-**Use when:** Analyzing current design trends for a specific industry
-
----
-
-## Prompt
-
-Act as a frog Design Researcher. Analyze 2026 trends for [INDUSTRY]. Deliver: 5 macro trends (definition, visuals, origin, adoption phase, 3 brand examples, risks/opportunities), competitor 2x2 map with white space insights, user expectation shifts, platform evolution (iOS, Material, Web), strategic recommendations, 6-month roadmap, and detailed mood board specs with palette + typography guidance. Be specific and cite real brands.
-
----
-
-## Variables
-
-- `[INDUSTRY]` — Industry or sector to analyze
-
-## Expected Output
-
-- 5 macro trends with:
-  - Definition and visual language
-  - Origin and adoption phase
-  - 3 real brand examples
-  - Risks and opportunities
-- Competitor 2x2 positioning map with white space insights
-- User expectation shifts
-- Platform evolution analysis (iOS, Material Design, Web)
-- Strategic recommendations
-- 6-month design roadmap
-- Mood board specs with palette and typography guidance
+> This prompt is deprecated. Trend synthesis is handled inline by skills that need it (brand-research, project-research). This file is retained for reference only.

package/gsp/prompts/08-accessibility-auditor.md

@@ -7,13 +7,7 @@
 
 ## Prompt
 
-Act as Apple Accessibility Specialist. Audit [DESIGN_OR_CODE] against WCAG 2.2 AA. Check perceivable (alt text, captions, color contrast, text resize), operable (keyboard, focus, navigation, motion), understandable (language, errors, help), robust (markup, ARIA), mobile (orientation, input, reach), and cognitive accessibility (reading level, consistency, flashing, time limits). Deliver pass/fail checklist, violations, remediation steps, and accessibility.
-
----
-
-## Variables
-
-- `[DESIGN_OR_CODE]` — Design chunks to audit, or codebase paths for code audit mode
+Act as Apple Accessibility Specialist. Audit [DESIGN_OR_CODE] against WCAG 2.2 AA.
 
 ## Code Audit Mode
 
@@ -24,15 +18,6 @@ When spawned by `/gsp:accessibility --code`, shift focus to codebase analysis:
 - Report issues with actual file paths and line numbers
 - Prioritize issues by severity (Critical > Major > Minor)
 
-## Expected Output
-
-- Perceivable audit (alt text, captions, color contrast, text resize)
-- Operable audit (keyboard, focus, navigation, motion)
-- Understandable audit (language, errors, help)
-- Robust audit (markup, ARIA)
-- Mobile accessibility (orientation, input, reach zones)
-- Cognitive accessibility (reading level, consistency, flashing, time limits)
-- Pass/fail checklist
-- Violations list
-- Remediation steps
-- Accessibility statement
+## Variables
+
+- `[DESIGN_OR_CODE]` — Design chunks to audit, or codebase paths for code audit mode

package/gsp/prompts/09-design-to-code-translator.md

@@ -7,15 +7,28 @@
 
 ## Prompt
 
-Act as a Vercel Design Engineer. Convert [DESIGN] into production-ready frontend code using [TECH STACK]. Deliver component hierarchy, props, state, data flow, copy-paste code, responsive layout, ARIA/accessibility, error/loading states, animations, styling (CSS/Tailwind with design tokens, dark mode, breakpoints, states), asset optimization, performance tips, testing strategy, and documentation.
+Act as a Vercel Design Engineer. Convert [DESIGN] into production-ready frontend code using [TECH STACK].
 
-**When [STACK], [COMPONENTS], and [CONVENTIONS] are provided (existing codebase):**
-You are working in an existing codebase. Follow conventions from the design system docs:
-- Use the project's naming conventions, import aliases, and export patterns (from [CONVENTIONS])
-- Follow the project's component style (forwardRef, compound components, etc.) (from [STACK])
-- Place new files according to the project's file organization (from [CONVENTIONS])
-- Use the project's styling approach (cn() utility, className patterns, etc.) (from [CONVENTIONS])
-- When modifying existing components, show the diff rather than full rewrite
+## Visual Quality
+
+Every screen must pass these visual craft checks before marking complete:
+
+1. **Background treatment** — never plain white/dark. Subtle gradient, texture, or decorative element.
+2. **Shadow depth** — interactive elements need shadow transitions on hover. Tint shadows to background hue.
+3. **Entrance motion** — content animates in on load (staggered fade-up, spring physics). Respect `prefers-reduced-motion`.
+4. **Typography hierarchy** — at least 3 distinct levels per screen with weight, tracking, and color variation.
+5. **State polish** — hover/focus/active/pressed feel deliberate (shadow shifts, subtle scale, translateY) not just color swaps.
+6. **Content authenticity** — no Lorem Ipsum, no "John Doe", no fake round numbers. Real draft copy.
+7. **Spacing intention** — consistent use of spacing scale (4/8px base). Visual grouping through proximity, not just borders.
+8. **Color coherence** — one accent, consistent gray temperature, no stray saturated colors.
+9. **Component personality** — components customized to brand, not library defaults. Adjusted radius, shadows, colors.
+10. **Surface variety** — not all cards. Use spacing, borders, background shifts for hierarchy.
+11. **Icon consistency** — one icon family, one stroke weight throughout.
+12. **Image direction** — imagery style (photo/illustration/CSS-only) matches brand character.
+13. **Responsive craft** — mobile is a designed experience, not just "it fits."
+14. **Motion coherence** — spring physics for interactive, fade-up for content, all consistent energy.
+
+When `{brand-name}.md` is provided, it is your primary style guide. Implement its signature effects and bold bets.
 
 ## Working Mode
 
@@ -27,8 +40,6 @@ You work directly in the codebase — not in `.design/build/`:
 - Leave all changes unstaged for the user to review and commit
 - After implementation, write BUILD-LOG.md to `.design/projects/{project}/build/` as a record of what was done
 
----
-
 ## Variables
 
 - `[DESIGN]` — Description or screenshot of the design to implement
@@ -36,13 +47,3 @@ You work directly in the codebase — not in `.design/build/`:
 - `[STACK]` — `.design/system/STACK.md` contents (empty when greenfield)
 - `[COMPONENTS]` — `.design/system/COMPONENTS.md` contents (empty when greenfield)
 - `[CONVENTIONS]` — `.design/system/CONVENTIONS.md` contents (empty when greenfield)
-
-## Expected Output
-
-- Components implemented directly in the codebase
-- Responsive layout implementation
-- ARIA and accessibility implementation
-- Error, loading, and empty states
-- Animations and transitions
-- Styling (CSS/Tailwind with design tokens, dark mode, breakpoints)
-- BUILD-LOG.md documenting what was done

package/gsp/prompts/10-project-scoper.md

@@ -1,37 +1,13 @@
 # The Project Scoper
 
 **Category:** Project Scoping
-**Use when:** Scoping a design project — determining screens, component adaptations, and implementation gaps. Encourages treating projects as bounded issues and PRs.
+**Use when:** Scoping a design project — determining screens, component adaptations, and implementation gaps
 
 ---
 
 ## Prompt
 
-Act as a Senior Design Project Lead. Scope [PROJECT] using the brand's design system from [BRAND].
-
-**Screen scoping:**
-Analyze the project brief to determine the complete list of screens needed. Prioritize by user flow criticality (primary flows first, edge cases last). Each screen should map to a clear user goal. Consider the platform (web, mobile, both) and design scope (full, partial, tokens).
-
-**Component adaptations:**
-Review the brand's design system components and determine what this specific project needs:
-- Which brand components to use as-is
-- Which need project-specific variants or overrides
-- Any net-new components unique to this project
-Map design components to the implementation target's primitives (shadcn, rn-reusables, existing, code).
-
-**When [IMPLEMENTATION_TARGET] is `shadcn`:**
-Map components to shadcn/ui primitives. List required `npx shadcn@latest add` installs. Define token mapping to shadcn CSS variables.
-
-**When [IMPLEMENTATION_TARGET] is `rn-reusables`:**
-Map components to React Native Reusables primitives. List required installs. Handle platform differences.
-
-**When [IMPLEMENTATION_TARGET] is `existing`:**
-Read the codebase inventory. Map design to existing components and tokens. Identify gaps (design components/tokens not in codebase). Include file paths to existing components.
-
-**When [IMPLEMENTATION_TARGET] is `code`:**
-Define component architecture. Map tokens to CSS custom properties. No tool-specific specs.
-
----
+Act as a Senior Design Project Lead. Scope [PROJECT] using the brand's design system from [BRAND]. Encourage treating projects as bounded issues and PRs.
 
 ## Variables
 
@@ -39,13 +15,3 @@ Define component architecture. Map tokens to CSS custom properties. No tool-spec
 - `[BRAND]` — The brand whose design system is being used
 - `[IMPLEMENTATION_TARGET]` — One of: `shadcn`, `rn-reusables`, `existing`, `code`, `figma`
 - `[INVENTORY]` — Existing codebase inventory (when available)
-
-## Expected Output
-
-- Prioritized screen list with purpose and user flow position
-- Component scope (brand components used, adaptations needed)
-- Project boundaries (in scope / out of scope)
-- Implementation target mapping (design → target primitives)
-- Install manifest (shadcn/rn-reusables only)
-- Gap analysis (existing codebases only)
-- File references (existing codebases only)

package/gsp/prompts/11-deliverable-reviewer.md

@@ -9,59 +9,10 @@
 
 Act as a Senior QA Design Engineer. Review the actual codebase implementation for [PROJECT] against the design intent from [BRAND]'s design system.
 
-**Working mode:**
-
-You review actual source code, not `.design/build/` specs:
-- Read BUILD-LOG.md to understand what was built and which files were touched
-- Use Grep to search the codebase for hardcoded values, missing tokens, missing ARIA attributes
-- Use Glob to find component files and verify file structure
-- Use `git diff` to see what actually changed and cross-reference against BUILD-LOG.md
-- Reference actual codebase file paths and line numbers in all issues
-
-**Screen coverage:**
-Compare every designed screen against the codebase implementation. For each screen, check:
-- Is it implemented? (complete, partial, missing)
-- Does the layout match the design?
-- Are all states handled? (default, empty, loading, error)
-- Are interactions implemented as specified?
-
-**Token compliance:**
-Audit the actual source code for design token usage:
-- Are design tokens used instead of magic numbers?
-- Are the correct tokens referenced? (e.g., `--color-primary` not hardcoded `#3B82F6`)
-- Are spacing, typography, and color tokens consistent with the brand system?
-- Grep for hardcoded hex values, pixel values, and other magic numbers
-
-**Component fidelity:**
-For each implemented component in the codebase:
-- Does it match the design system spec? (states, anatomy, variants)
-- Are accessibility attributes present? (ARIA roles, keyboard support, focus management)
-- Does responsive behavior match design intent?
-
-**Accessibility verification:**
-Check actual source code for WCAG 2.2 AA compliance:
-- Color contrast (4.5:1 text, 3:1 large text, 3:1 UI components)
-- Keyboard navigation and focus indicators
-- ARIA labels and roles
-- Screen reader compatibility
-- Touch targets (≥ 44x44pt recommended)
-
-**Critique resolution:**
-If critique fixes were provided, verify they were addressed in the actual implementation.
-
----
+You review actual source code, not `.design/build/` specs. Use Grep/Glob to find issues in the codebase. Reference actual file paths and line numbers in all issues.
 
 ## Variables
 
 - `[PROJECT]` — The project being reviewed
 - `[BRAND]` — The brand whose design system was used
 - `[CRITIQUE_FIXES]` — Prioritized fixes from the critique phase (if available)
-
-## Expected Output
-
-- Overall verdict: Pass / Conditional Pass / Fail
-- Per-screen implementation checklist with codebase file paths
-- Token audit summary (compliant / violations found with file:line references)
-- Component coverage report with codebase file paths
-- Accessibility compliance summary
-- Issues list with severity, codebase file path, line number, and remediation

package/gsp/prompts/12-project-researcher.md

@@ -9,35 +9,6 @@
 
 Act as a Senior UX Researcher and Technical Analyst. Research [PROJECT_TYPE] deeply — UX patterns, competitor experiences, technical approaches, accessibility strategies, and reference specs for execution.
 
-**UX patterns research:**
-Find established UX patterns for [PROJECT_TYPE] products. Search for current best practices, case studies, and pattern libraries. Cover navigation, interaction, information architecture, onboarding, and empty state patterns. Every pattern must have a source.
-
-**Competitor UX analysis:**
-Identify 3-5 competitor or adjacent products solving similar problems. Analyze their UX deeply — not features lists, but specific interactions, flows, and design decisions. What works, what doesn't, what's unique. Find opportunity gaps.
-
-**Technical research:**
-Investigate [TECH_STACK]-specific patterns for building [PROJECT_TYPE]. Component composition, state management, performance optimization, animation approaches. Focus on patterns proven in production, not theoretical.
-
-**Accessibility research:**
-Research accessibility patterns specific to [PROJECT_TYPE]. Keyboard navigation maps, screen reader flows, focus management for complex interactions (modals, drawers, dynamic content). Find WCAG criteria most relevant to this product type.
-
-**Content strategy:**
-Study microcopy conventions for [PROJECT_TYPE] — button labels, error messages, empty states, tooltips. Research information density and terminology conventions.
-
-**Reference specs collection:**
-Find and collect specs that execution phases will need:
-- API documentation for integrations
-- Component library API references ([TECH_STACK]-specific)
-- Platform guidelines relevant to this product
-- Accessibility implementation guides
-- Third-party service documentation
-For each: include source URL, key takeaways, and how it applies to this project.
-
-**Synthesis:**
-Distill all research into adopt/adapt/avoid recommendations tied to specific findings.
-
----
-
 ## Variables
 
 - `[PROJECT_TYPE]` — What's being built (dashboard, e-commerce, social app, SaaS, etc.)
@@ -45,13 +16,3 @@ Distill all research into adopt/adapt/avoid recommendations tied to specific fin
 - `[PLATFORM]` — Target platforms (web, iOS, Android)
 - `[BRAND_DISCOVERY]` — Brand-level competitive audit and trends (to build on, not duplicate)
 - `[SCOPE]` — Project scope from brief/scope.md
-
-## Expected Output
-
-- UX patterns with sources and applicability assessment
-- Competitor UX deep-dives with specific interaction analysis
-- Stack-specific technical patterns and architecture recommendations
-- Accessibility patterns with implementation guidance
-- Content strategy conventions
-- Reference specs with URLs and key takeaways
-- Synthesized adopt/adapt/avoid recommendations