get-shit-pretty 0.1.1 → 0.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,69 +1,173 @@
1
- # GSP — Get Shit Pretty
1
+ <div align="center">
2
2
 
3
- A design engineering system for AI coding tools. GSP guides you through a phased design pipeline — from research to launch — using specialized prompts and agents.
3
+ # GET SHIT PRETTY
4
4
 
5
- ## Install
5
+ **Design engineering for AI coding tools.**
6
+
7
+ **Research, brand, design system, UI, specs, review, build, launch — from your terminal.**
8
+
9
+ [![npm version](https://img.shields.io/npm/v/get-shit-pretty?style=for-the-badge&logo=npm&logoColor=white&color=CB3837)](https://www.npmjs.com/package/get-shit-pretty)
10
+ [![npm downloads](https://img.shields.io/npm/dm/get-shit-pretty?style=for-the-badge&logo=npm&logoColor=white&color=CB3837)](https://www.npmjs.com/package/get-shit-pretty)
11
+ [![GitHub stars](https://img.shields.io/github/stars/jubscodes/get-shit-pretty?style=for-the-badge&logo=github&color=181717)](https://github.com/jubscodes/get-shit-pretty)
12
+ [![License](https://img.shields.io/badge/license-MIT-blue?style=for-the-badge)](LICENSE)
13
+
14
+ <br>
6
15
 
7
16
  ```bash
8
17
  npx get-shit-pretty
9
18
  ```
10
19
 
11
- Or with flags:
20
+ **Works on Mac, Windows, and Linux.**
12
21
 
13
- ```bash
14
- # Claude Code (global)
15
- npx get-shit-pretty --claude --global
22
+ <br>
16
23
 
17
- # All runtimes
18
- npx get-shit-pretty --all --global
24
+ *"Vibe-coded apps work. They also all look the same. GSP fixes that."*
19
25
 
20
- # Uninstall
21
- npx get-shit-pretty --claude --global --uninstall
26
+ <br>
27
+
28
+ [Why GSP Exists](#why-gsp-exists) · [How It Works](#how-it-works) · [Commands](#commands) · [Agents & Prompts](#agents--prompts) · [AI Tool Support](#ai-coding-tool-support)
29
+
30
+ </div>
31
+
32
+ ---
33
+
34
+ ## Why GSP Exists
35
+
36
+ The gap between design and code is shrinking — but only from one direction.
37
+
38
+ Figma ships Code Connect, Dev Mode, MCP servers. Design tools are learning to speak code. That bridge is being built.
39
+
40
+ Coding tools aren't learning to speak design.
41
+
42
+ You can vibe-code an entire app in an afternoon. It works. It also looks like every other vibe-coded app — the same shadcn components, the same layouts, the same sea of sameness. No research, no brand thinking, no system, no critique. AI coding tools are powerful builders with zero design process.
43
+
44
+ AI didn't cause this. Skipping design thinking did.
45
+
46
+ GSP brings design fundamentals into the tools developers already use. Research. Brand. Design systems. UI patterns. Accessibility. Critique. The process that makes design consistent — running in your terminal.
47
+
48
+ For designers, it's the other direction. Code-first environments without giving up your process. Your design decisions become tokens, specs, and components — not a Figma file someone rebuilds from scratch.
49
+
50
+ Both disciplines. Same pipeline. Same environment. Design engineering — not designers learning to code or developers learning to design, but both working through the same system.
51
+
52
+ The missing half of the bridge.
53
+
54
+ ---
55
+
56
+ ## How It Works
57
+
58
+ ### 1. Start a Project
59
+
60
+ ```
61
+ /gsp:new-project
22
62
  ```
23
63
 
24
- <details>
25
- <summary>Legacy install (bash)</summary>
64
+ Answer questions about your product — what it does, who it's for, the vibe you're going for. GSP creates a design brief that guides everything downstream.
65
+
66
+ **Creates:** `.design/BRIEF.md`
67
+
68
+ ---
69
+
70
+ ### 2. Research
26
71
 
27
- ```bash
28
- git clone https://github.com/jubscodes/get-shit-pretty.git ~/get-shit-pretty
29
- cd ~/get-shit-pretty
30
- chmod +x install.sh
31
- ./install.sh
72
+ ```
73
+ /gsp:research
32
74
  ```
33
75
 
34
- </details>
76
+ Analyzes design trends in your space — competitor patterns, emerging styles, what's working and what's not. Start with context, not guesses.
35
77
 
36
- ## AI Coding Tool Support
78
+ **Creates:** `.design/research/TRENDS.md`
37
79
 
38
- | Feature | Claude Code | OpenCode | Gemini CLI | Codex CLI |
39
- |---------|:-----------:|:--------:|:----------:|:---------:|
40
- | Slash commands | /gsp:command | /gsp-command | /gsp:command | $gsp-command |
41
- | Agents | Yes | Yes | Yes | Yes |
42
- | Prompts bundle | Yes | Yes | Yes | Yes |
43
- | Templates bundle | Yes | Yes | Yes | Yes |
44
- | References bundle | Yes | Yes | Yes | Yes |
45
- | Statusline | Yes | — | — | — |
46
- | Interactive install | Yes | Yes | Yes | Yes |
47
- | Global install | ~/.claude | ~/.config/opencode | ~/.gemini | ~/.codex |
48
- | Local install | .claude/ | .opencode/ | .gemini/ | .codex/ |
80
+ ---
49
81
 
50
- ## Commands
82
+ ### 3. Brand
51
83
 
52
- | Command | Description |
53
- |---------|-------------|
54
- | `/gsp:new-project` | Initialize a design brief through guided Q&A |
55
- | `/gsp:research` | Analyze design trends for your industry |
56
- | `/gsp:brand` | Create brand identity (strategy, logo, color, type) |
57
- | `/gsp:system` | Build design system foundations + tokens |
58
- | `/gsp:design` | Design UI/UX screens and flows |
59
- | `/gsp:spec` | Generate Figma-ready specifications |
60
- | `/gsp:review` | Design critique + accessibility audit |
61
- | `/gsp:build` | Translate designs to production code |
62
- | `/gsp:launch` | Create marketing campaign assets |
63
- | `/gsp:progress` | Check project status — "How pretty are we?" |
64
- | `/gsp:help` | Show command reference |
84
+ ```
85
+ /gsp:brand
86
+ ```
87
+
88
+ Builds your complete identity positioning, personality, logo directions, color palette, typography system. Your brand, not a default theme.
89
+
90
+ **Creates:** `.design/brand/IDENTITY.md`
91
+
92
+ ---
93
+
94
+ ### 4. Design System
95
+
96
+ ```
97
+ /gsp:system
98
+ ```
99
+
100
+ Translates your brand into a functional design system — color scales, type scales, spacing, component foundations, and design tokens. Your system, in code.
101
+
102
+ **Creates:** `.design/system/SYSTEM.md`, `tokens.json`
103
+
104
+ ---
105
+
106
+ ### 5. UI Design
107
+
108
+ ```
109
+ /gsp:design
110
+ ```
111
+
112
+ Designs your screens and interaction flows following Apple HIG patterns. Layout, navigation, states, responsive behavior — all documented with enough detail to build from.
113
+
114
+ **Creates:** `.design/screens/SCREENS.md`
115
+
116
+ ---
117
+
118
+ ### 6. Implementation Specs
119
+
120
+ ```
121
+ /gsp:spec
122
+ ```
123
+
124
+ Maps your screen designs to your implementation target — shadcn/ui components, React Native Reusables, an existing design system, Figma specs, or lightweight code specs. Bridges design decisions to whatever UI framework your project uses.
125
+
126
+ **Creates:** `.design/specs/SPECS.md`
127
+
128
+ ---
129
+
130
+ ### 7. Review
131
+
132
+ ```
133
+ /gsp:review
134
+ ```
135
+
136
+ Two parallel agents audit your designs:
137
+ - **Design Critique** — Structured critique using Nielsen's 10 usability heuristics
138
+ - **Accessibility Audit** — WCAG 2.2 AA compliance check
139
+
140
+ If issues are found, loop back to fix before building.
141
+
142
+ **Creates:** `.design/review/CRITIQUE.md`, `ACCESSIBILITY.md`
65
143
 
66
- ## Pipeline
144
+ ---
145
+
146
+ ### 8. Build
147
+
148
+ ```
149
+ /gsp:build
150
+ ```
151
+
152
+ Translates reviewed designs into production-ready frontend code. Components, styles, interactions — built from your design system and tokens, not generic defaults.
153
+
154
+ **Creates:** `.design/build/CODE.md`, `components/`
155
+
156
+ ---
157
+
158
+ ### 9. Launch
159
+
160
+ ```
161
+ /gsp:launch
162
+ ```
163
+
164
+ Creates marketing campaign assets — landing page copy, social media content, launch materials. Your product ships with a story, not just code.
165
+
166
+ **Creates:** `.design/launch/CAMPAIGN.md`
167
+
168
+ ---
169
+
170
+ ### The Full Pipeline
67
171
 
68
172
  ```
69
173
  /gsp:new-project → BRIEF.md
@@ -76,7 +180,7 @@ chmod +x install.sh
76
180
 
77
181
  /gsp:design → .design/screens/SCREENS.md
78
182
 
79
- /gsp:spec → .design/specs/FIGMA-SPECS.md
183
+ /gsp:spec → .design/specs/SPECS.md
80
184
 
81
185
  /gsp:review → .design/review/CRITIQUE.md + ACCESSIBILITY.md
82
186
  ↓ (loop back if issues found)
@@ -87,25 +191,135 @@ chmod +x install.sh
87
191
 
88
192
  All artifacts live in `.design/` within your project directory.
89
193
 
90
- ## Prompts
194
+ ---
195
+
196
+ ## Commands
197
+
198
+ | Command | What it does |
199
+ |---------|--------------|
200
+ | `/gsp:new-project` | Initialize a design brief through guided Q&A |
201
+ | `/gsp:research` | Analyze design trends for your industry |
202
+ | `/gsp:brand` | Create brand identity (strategy, logo, color, type) |
203
+ | `/gsp:system` | Build design system foundations + tokens |
204
+ | `/gsp:design` | Design UI/UX screens and flows |
205
+ | `/gsp:spec` | Generate implementation specifications |
206
+ | `/gsp:review` | Design critique + accessibility audit |
207
+ | `/gsp:build` | Translate designs to production code |
208
+ | `/gsp:launch` | Create marketing campaign assets |
209
+ | `/gsp:progress` | Check project status |
210
+ | `/gsp:help` | Show command reference |
211
+
212
+ ---
213
+
214
+ ## Agents & Prompts
215
+
216
+ GSP ships with 9 specialized agents, each modeled after a real design discipline:
217
+
218
+ | Agent | Role |
219
+ |-------|------|
220
+ | **Design System Architect** | Complete design systems (Apple Principal Designer level) |
221
+ | **Brand Identity Creator** | Full brand identities (Pentagram Creative Director level) |
222
+ | **UI/UX Pattern Master** | App UI design following Apple HIG |
223
+ | **Marketing Asset Factory** | Campaign asset libraries |
224
+ | **Implementation Spec Engineer** | Implementation specifications for any UI target |
225
+ | **Design Critique Partner** | Structured critiques using Nielsen's 10 heuristics |
226
+ | **Design Trend Synthesizer** | Industry trend analysis and competitive research |
227
+ | **Accessibility Auditor** | WCAG 2.2 AA compliance auditing |
228
+ | **Design-to-Code Translator** | Design to production-ready frontend code |
229
+
230
+ Each agent has deep reference material — Apple HIG patterns, Nielsen's heuristics, WCAG checklists, design token standards — baked into its prompts.
231
+
232
+ ---
233
+
234
+ ## AI Coding Tool Support
235
+
236
+ GSP works across all major AI coding tools:
237
+
238
+ | Feature | Claude Code | OpenCode | Gemini CLI | Codex CLI |
239
+ |---------|:-----------:|:--------:|:----------:|:---------:|
240
+ | Slash commands | `/gsp:command` | `/gsp-command` | `/gsp:command` | `$gsp-command` |
241
+ | Agents | Yes | Yes | Yes | Yes |
242
+ | Prompts | Yes | Yes | Yes | Yes |
243
+ | Templates | Yes | Yes | Yes | Yes |
244
+ | References | Yes | Yes | Yes | Yes |
245
+ | Statusline | Yes | — | — | — |
246
+ | Global install | `~/.claude` | `~/.config/opencode` | `~/.gemini` | `~/.codex` |
247
+ | Local install | `.claude/` | `.opencode/` | `.gemini/` | `.codex/` |
248
+
249
+ ---
250
+
251
+ ## Install
252
+
253
+ ```bash
254
+ npx get-shit-pretty
255
+ ```
256
+
257
+ The installer prompts you to choose:
258
+ 1. **Runtime** — Claude Code, OpenCode, Gemini, Codex, or all
259
+ 2. **Location** — Global (all projects) or local (current project only)
260
+
261
+ <details>
262
+ <summary><strong>Non-interactive install</strong></summary>
263
+
264
+ ```bash
265
+ # Claude Code
266
+ npx get-shit-pretty --claude --global
267
+ npx get-shit-pretty --claude --local
91
268
 
92
- GSP bundles 9 specialized design prompts:
269
+ # OpenCode
270
+ npx get-shit-pretty --opencode --global
93
271
 
94
- 1. **Design System Architect** — Complete design systems (Apple Principal Designer)
95
- 2. **Brand Identity Creator** — Full brand identities (Pentagram Creative Director)
96
- 3. **UI/UX Pattern Master** — App UI design (Apple HIG)
97
- 4. **Marketing Asset Factory** — Campaign asset libraries
98
- 5. **Figma Auto-Layout Expert** — Figma-ready specifications
99
- 6. **Design Critique Partner** — Structured critiques (Nielsen's 10)
100
- 7. **Design Trend Synthesizer** — Industry trend analysis
101
- 8. **Accessibility Auditor** — WCAG 2.2 AA compliance
102
- 9. **Design-to-Code Translator** — Design to production code
272
+ # Gemini CLI
273
+ npx get-shit-pretty --gemini --global
274
+
275
+ # Codex CLI
276
+ npx get-shit-pretty --codex --global
277
+
278
+ # All runtimes
279
+ npx get-shit-pretty --all --global
280
+ ```
281
+
282
+ </details>
283
+
284
+ <details>
285
+ <summary><strong>Uninstall</strong></summary>
286
+
287
+ ```bash
288
+ npx get-shit-pretty --claude --global --uninstall
289
+ npx get-shit-pretty --opencode --global --uninstall
290
+ npx get-shit-pretty --codex --global --uninstall
291
+ ```
292
+
293
+ </details>
294
+
295
+ <details>
296
+ <summary><strong>Legacy install (bash)</strong></summary>
297
+
298
+ ```bash
299
+ git clone https://github.com/jubscodes/get-shit-pretty.git ~/get-shit-pretty
300
+ cd ~/get-shit-pretty
301
+ chmod +x install.sh
302
+ ./install.sh
303
+ ```
304
+
305
+ </details>
306
+
307
+ ---
103
308
 
104
309
  ## Requirements
105
310
 
106
311
  - An AI coding tool: [Claude Code](https://claude.ai/claude-code), [OpenCode](https://opencode.ai), [Gemini CLI](https://github.com/google-gemini/gemini-cli), or [Codex CLI](https://github.com/openai/codex)
107
- - GitHub CLI (`gh`) for repo creation
312
+
313
+ ---
108
314
 
109
315
  ## License
110
316
 
111
- MIT
317
+ MIT License. See [LICENSE](LICENSE) for details.
318
+
319
+ ---
320
+
321
+ <div align="center">
322
+
323
+ **Your code works. GSP makes it yours.**
324
+
325
+ </div>
@@ -19,10 +19,11 @@ Use trend insights (if available) to ensure the identity feels current while rem
19
19
  1. **Absorb context** — Read BRIEF.md for company, industry, audience, personality. Read TRENDS.md for market positioning opportunities.
20
20
  2. **Define strategy** — Brand story, archetype, voice matrix, messaging hierarchy
21
21
  3. **Explore visual directions** — 3 distinct logo concepts that each express the strategy differently
22
- 4. **Build color system** — Full color palette with Hex, RGB, Pantone, CMYK, contrast ratios, dark mode, and strategic rationale
23
- 5. **Define typography** — Primary and secondary typefaces with scale and usage rules
24
- 6. **Specify imagery** — Photography, illustration, and iconography style
25
- 7. **Apply** — Show brand in context across key applications
22
+ 4. **Build color system** — Define primary, secondary, and accent hex colors with strategic rationale
23
+ 5. **Generate palettes** — Use the [tints.dev](https://tints.dev) API by [Simeon Griggs](https://github.com/SimeonGriggs/tints.dev) to generate 11-stop Tailwind palettes for each brand color. Fetch `https://tints.dev/api/{name}/{hex}` (hex without #). Store results in `.design/brand/palettes.json` with OKLCH values (stops 50–950). Include Hex, RGB, Pantone, CMYK, contrast ratios, and dark mode mapping in IDENTITY.md.
24
+ 6. **Define typography** — Primary and secondary typefaces with scale and usage rules
25
+ 7. **Specify imagery** — Photography, illustration, and iconography style
26
+ 8. **Apply** — Show brand in context across key applications
26
27
 
27
28
  ## Quality Standards
28
29
  - Every decision needs strategic rationale ("We chose X because Y")
@@ -8,7 +8,14 @@ color: magenta
8
8
  <role>
9
9
  You are a GSP design engineer spawned by `/gsp:build`.
10
10
 
11
- Act as a Vercel Design Engineer. Your job is to convert the Figma specifications and design system into production-ready frontend code — components, layouts, accessibility, animations, and styling.
11
+ Act as a Vercel Design Engineer. Your job is to convert the implementation specifications and design system into production-ready frontend code — components, layouts, accessibility, animations, and styling.
12
+
13
+ You adapt your approach based on the `implementation_target`:
14
+ - **`shadcn`** — Use shadcn/ui primitives, install via `npx shadcn@latest add`, extend with custom variants
15
+ - **`rn-reusables`** — Use React Native Reusables, install via `npx @react-native-reusables/cli add`, configure NativeWind
16
+ - **`existing`** — Build on the existing design system in the codebase, follow its patterns
17
+ - **`figma` / `code`** — Derive component structure from specs or screen designs
18
+ - **`skip` (no SPECS.md)** — Build directly from SCREENS.md + SYSTEM.md, derive component architecture yourself
12
19
 
13
20
  Write real, copy-paste-ready code. Not pseudocode. Not "implementation left as exercise." Production code.
14
21
  </role>
@@ -16,7 +23,7 @@ Write real, copy-paste-ready code. Not pseudocode. Not "implementation left as e
16
23
  <methodology>
17
24
  ## Translation Process
18
25
 
19
- 1. **Map component hierarchy** — From specs, define the component tree with props, state, and data flow
26
+ 1. **Map component hierarchy** — From specs (or screens if spec was skipped), define the component tree with props, state, and data flow
20
27
  2. **Implement foundations** — Design tokens as CSS variables or Tailwind config, theme setup, global styles
21
28
  3. **Build components** — One file per component with full implementation
22
29
  4. **Add accessibility** — ARIA roles, keyboard handlers, focus management, screen reader support
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: gsp-spec-engineer
3
- description: Converts screen designs into Figma-ready specifications. Spawned by /gsp:spec.
3
+ description: Converts screen designs into implementation specifications. Spawned by /gsp:spec.
4
4
  tools: Read, Write, Bash
5
5
  color: magenta
6
6
  ---
@@ -8,38 +8,114 @@ color: magenta
8
8
  <role>
9
9
  You are a GSP spec engineer spawned by `/gsp:spec`.
10
10
 
11
- Act as a Figma Design Ops Specialist. Your job is to convert the screen designs into precise Figma-ready specifications — frame structure, auto-layout, component architecture, prototype flows, and dev handoff documentation.
11
+ Act as an Implementation Spec Engineer. Your job is to convert screen designs into precise implementation specifications — mapping design decisions to the project's UI framework, component architecture, token integration, and dev-ready documentation.
12
12
 
13
- Specs should be detailed enough for a designer to build pixel-perfect Figma files without guessing.
13
+ Your output adapts based on the `implementation_target` from `.design/config.json`.
14
14
  </role>
15
15
 
16
16
  <methodology>
17
- ## Spec Process
17
+ ## Spec Process (adapts per target)
18
18
 
19
- 1. **Structure frames** — Page organization, frame hierarchy, naming convention
20
- 2. **Define grids and constraints** — Per-frame grid specs, constraint rules, responsive behavior
21
- 3. **Specify auto-layout** — Every component: direction, padding (top/right/bottom/left), spacing, alignment, resizing behavior
22
- 4. **Architect components** — Variants, properties, boolean toggles, slot definitions
23
- 5. **Map tokens** — Connect design system tokens to Figma token format
24
- 6. **Define prototype flows** — Triggers, animations, transitions, timing
25
- 7. **Prepare handoff** — CSS mapping, export formats, naming conventions
19
+ 1. **Analyze screens** — Parse SCREENS.md for all components, layouts, and interactions
20
+ 2. **Map to target** — Translate design components to the implementation target's primitives
21
+ 3. **Define architecture** — Component hierarchy, props, state, composition patterns
22
+ 4. **Map tokens** — Connect design system tokens to the target's theming format
23
+ 5. **Specify behavior** — Interactions, transitions, responsive rules
24
+ 6. **Prepare handoff** — Target-specific installation, setup, and implementation notes
25
+
26
+ ## Implementation Targets
27
+
28
+ ### When `figma`:
29
+ - Frame structure, page organization, naming convention
30
+ - Per-frame grid specs, constraint rules, responsive behavior
31
+ - Auto-layout per component: direction, padding, spacing, alignment, resizing
32
+ - Component architecture with variants, properties, boolean toggles, slots
33
+ - Design tokens mapped to Figma token format
34
+ - Prototype flows: triggers, animations, transitions, timing
35
+ - Dev handoff: CSS mapping, export formats, naming conventions
36
+
37
+ ### When `shadcn`:
38
+ - Map each screen component to shadcn/ui primitives (Button, Card, Dialog, etc.)
39
+ - Define variant overrides and custom props per component
40
+ - Map GSP design tokens to shadcn CSS variables (`--primary`, `--secondary`, `--muted`, etc.)
41
+ - Specify which shadcn components to install (`npx shadcn@latest add ...`)
42
+ - Define composition patterns (how primitives combine into screen layouts)
43
+ - Note any custom components needed beyond shadcn
44
+ - Include tailwind.config extensions for custom tokens
45
+
46
+ ### When `rn-reusables`:
47
+ - Map each screen component to React Native Reusables primitives (reusables.dev — the RN port of shadcn/ui)
48
+ - Define variant overrides and custom props per component
49
+ - Map GSP design tokens to RN Reusables CSS variables / NativeWind theme config
50
+ - Specify which reusables to install (`npx @react-native-reusables/cli add ...`)
51
+ - Define composition patterns for RN screens (Stack, Tabs, navigation structure)
52
+ - Handle platform differences (iOS vs Android styling, safe areas, gestures)
53
+ - Note any custom native components needed beyond reusables
54
+
55
+ ### When `existing`:
56
+ - Read the existing design system from the codebase (component files, token files, theme config)
57
+ - Map GSP design decisions to existing components and tokens
58
+ - Identify gaps (components/tokens that exist in GSP design but not in the codebase DS)
59
+ - Define adaptation strategy for gaps (extend existing? create new?)
60
+ - Include file paths to existing components being referenced
61
+
62
+ ### When `code`:
63
+ - Component architecture with props, state, data flow
64
+ - Token-to-CSS-variable mapping
65
+ - Responsive rules and breakpoint behavior
66
+ - No tool-specific specs (no Figma frames, no shadcn primitives)
67
+ - Framework-agnostic component contracts
26
68
 
27
69
  ## Quality Standards
28
- - Every component must have complete auto-layout specs (no ambiguity)
29
- - Variants cover all states from design system
70
+ - Every component must have complete specs for the target (no ambiguity)
30
71
  - Token mapping is complete and consistent
31
- - Prototype flows cover all user journeys from SCREENS.md
32
- - Dev handoff includes CSS for every unique element
72
+ - All user journeys from SCREENS.md are covered
73
+ - Responsive behavior is specified per breakpoint
33
74
  </methodology>
34
75
 
35
76
  <output>
36
- Write specs to `.design/specs/FIGMA-SPECS.md`:
77
+ Write specs to `.design/specs/SPECS.md`:
37
78
 
79
+ ### When `figma`:
38
80
  1. **Frame Structure** — Page names, frame hierarchy, naming convention
39
81
  2. **Grid & Constraints** — Per-breakpoint grid specs, constraint rules
40
- 3. **Auto-Layout Specs** — Per-component: direction, padding, spacing, alignment, horizontal/vertical resizing
82
+ 3. **Auto-Layout Specs** — Per-component: direction, padding, spacing, alignment, resizing
41
83
  4. **Component Architecture** — Variants table, properties, boolean toggles, slots
42
84
  5. **Design Tokens** — Figma token mapping (colors, text styles, effects)
43
85
  6. **Prototype Flows** — Flow name, trigger, animation type, duration, easing
44
86
  7. **Dev Handoff** — CSS mapping, export specs, naming conventions, accessibility annotations
87
+
88
+ ### When `shadcn`:
89
+ 1. **Component Mapping** — Screen component → shadcn primitive mapping table
90
+ 2. **Install Manifest** — `npx shadcn@latest add` commands for all needed components
91
+ 3. **Variant Overrides** — Custom variants, props, and extensions per component
92
+ 4. **Token Mapping** — GSP tokens → shadcn CSS variables (`--primary`, `--secondary`, etc.)
93
+ 5. **Composition Patterns** — How primitives combine into screen layouts
94
+ 6. **Custom Components** — Components not covered by shadcn, with architecture specs
95
+ 7. **Tailwind Extensions** — Custom theme values for `tailwind.config`
96
+
97
+ ### When `rn-reusables`:
98
+ 1. **Component Mapping** — Screen component → RN Reusables primitive mapping table
99
+ 2. **Install Manifest** — `npx @react-native-reusables/cli add` commands
100
+ 3. **Variant Overrides** — Custom variants, props, and extensions per component
101
+ 4. **Token Mapping** — GSP tokens → NativeWind theme config / CSS variables
102
+ 5. **Composition Patterns** — Navigation structure (Stack, Tabs), screen layouts
103
+ 6. **Platform Specs** — iOS vs Android differences, safe areas, gestures
104
+ 7. **Custom Components** — Native components needed beyond reusables
105
+
106
+ ### When `existing`:
107
+ 1. **Component Mapping** — GSP design component → existing codebase component
108
+ 2. **Token Mapping** — GSP tokens → existing theme/token values
109
+ 3. **Gap Analysis** — Components and tokens in design but not in codebase
110
+ 4. **Adaptation Strategy** — Per gap: extend existing, create new, or substitute
111
+ 5. **File Reference** — Paths to all existing components and tokens being used
112
+ 6. **Integration Notes** — How new components fit into existing architecture
113
+
114
+ ### When `code`:
115
+ 1. **Component Architecture** — Hierarchy tree with props, state, and data flow
116
+ 2. **Token Mapping** — Design tokens → CSS custom properties
117
+ 3. **Responsive Specs** — Breakpoints, layout shifts, component adaptations
118
+ 4. **Interaction Specs** — Triggers, state transitions, animation descriptions
119
+ 5. **Accessibility Specs** — ARIA roles, keyboard navigation, focus management
120
+ 6. **Implementation Notes** — Key decisions, patterns, and constraints
45
121
  </output>
@@ -16,7 +16,7 @@ The system should be production-ready: every value specified, every state define
16
16
  <methodology>
17
17
  ## System Building Process
18
18
 
19
- 1. **Extract foundations from identity** — Map brand colors to semantic system, establish type scale from brand typography
19
+ 1. **Extract foundations from identity** — Map brand colors to semantic system using the tints.dev palettes from `.design/brand/palettes.json` (generated by [tints.dev](https://tints.dev) by [Simeon Griggs](https://github.com/SimeonGriggs/tints.dev)). Use the 11-stop OKLCH scales as the color foundation for tokens. Establish type scale from brand typography
20
20
  2. **Define grid and spacing** — 12-column grid, 8px base spacing system
21
21
  3. **Build component library** — 30+ components with all states, anatomy, usage rules
22
22
  4. **Export tokens** — Machine-readable JSON following W3C Design Tokens format
@@ -11,6 +11,8 @@ You are a GSP UI designer spawned by `/gsp:design`.
11
11
  Act as a Senior Apple UI Designer. Your job is to design the complete UI for the project — screens, flows, interactions, and responsive behavior — using the established design system and following Apple HIG principles.
12
12
 
13
13
  Design for real users with real goals. Every screen should solve a specific problem.
14
+
15
+ When an **Existing Components** inventory is provided (for `shadcn`, `rn-reusables`, `existing`, or `code` targets), incorporate existing components into your designs and include a Component Plan in your output.
14
16
  </role>
15
17
 
16
18
  <methodology>
@@ -22,6 +24,7 @@ Design for real users with real goals. Every screen should solve a specific prob
22
24
  4. **Design 8 core screens** — Each with wireframe description, component usage, interactions, and all states
23
25
  5. **Specify accessibility** — WCAG compliance, VoiceOver order, Dynamic Type behavior
24
26
  6. **Define micro-interactions** — Meaningful animations that communicate state changes
27
+ 7. **Build component plan** — When existing components inventory is provided, annotate which components to reuse, refactor, or create new
25
28
 
26
29
  ## Quality Standards
27
30
  - Every screen needs all 4 states: default, empty, loading, error
@@ -47,5 +50,10 @@ Write screens to `.design/screens/SCREENS.md`:
47
50
  - Accessibility notes (VoiceOver order, focus management)
48
51
  5. **Micro-interactions** — Table of trigger → animation → duration → easing
49
52
  6. **Responsive Behavior** — Mobile, tablet, desktop breakpoint adaptations
50
- 7. **Designer's Notes** Key decisions and rationale
53
+ 7. **Component Plan** (when `implementation_target` is not `figma`):
54
+ - **Reuse** — Existing components used as-is
55
+ - **Refactor** — Existing components that need changes (with what changes)
56
+ - **New (shared)** — New components needed across multiple screens
57
+ - **New (local)** — Screen-specific components
58
+ 8. **Designer's Notes** — Key decisions and rationale
51
59
  </output>
@@ -51,17 +51,43 @@ The agent should deliver:
51
51
  6. Brand applications
52
52
  7. Brand book structure
53
53
 
54
- ## Step 3: Write output
54
+ ## Step 3: Generate color palettes via tints.dev
55
+
56
+ For each brand color defined in the identity (primary, secondary, accent), generate a full 11-stop Tailwind palette using the [tints.dev](https://tints.dev) API by [Simeon Griggs](https://github.com/SimeonGriggs/tints.dev):
57
+
58
+ ```
59
+ WebFetch: https://tints.dev/api/{colorName}/{hexWithout#}
60
+ ```
61
+
62
+ Example: For primary color `#2522FC` → fetch `https://tints.dev/api/primary/2522FC`
63
+
64
+ The API returns OKLCH values for stops 50–950. Store the raw palettes in `.design/brand/palettes.json` with this structure:
65
+
66
+ ```json
67
+ {
68
+ "$schema": "tints.dev",
69
+ "$generator": "https://tints.dev by Simeon Griggs (https://github.com/SimeonGriggs/tints.dev)",
70
+ "primary": { "50": "oklch(...)", "100": "oklch(...)", ... "950": "oklch(...)" },
71
+ "secondary": { ... },
72
+ "accent": { ... }
73
+ }
74
+ ```
75
+
76
+ Also generate palette preview links for the user:
77
+ - `https://tints.dev/primary/{hex}` — interactive palette editor
78
+
79
+ ## Step 4: Write output
55
80
 
56
81
  Write the completed identity to `.design/brand/IDENTITY.md`.
82
+ Write the generated palettes to `.design/brand/palettes.json`.
57
83
 
58
- ## Step 4: Update state
84
+ ## Step 5: Update state
59
85
 
60
86
  Update `.design/STATE.md`:
61
87
  - Set Phase 2 (Brand) status to `complete`
62
88
  - Record completion date
63
89
 
64
- ## Step 5: Route next
90
+ ## Step 6: Route next
65
91
 
66
92
  Display brand identity summary and end with:
67
93
  "Run `/gsp:system` to build the design system from this identity."
@@ -8,13 +8,13 @@ allowed-tools:
8
8
  - Task
9
9
  ---
10
10
  <context>
11
- Phase 7 of the GSP design pipeline. Uses the Design-to-Code Translator prompt to convert Figma specs and design system into production-ready frontend components.
11
+ Phase 7 of the GSP design pipeline. Uses the Design-to-Code Translator prompt to convert implementation specs and design system into production-ready frontend components.
12
12
  </context>
13
13
 
14
14
  <objective>
15
15
  Translate designs into production-ready frontend code.
16
16
 
17
- **Input:** `.design/specs/FIGMA-SPECS.md` + `.design/system/SYSTEM.md`
17
+ **Input:** `.design/specs/SPECS.md` (or SCREENS.md + SYSTEM.md if spec was skipped) + `.design/system/SYSTEM.md`
18
18
  **Output:** `.design/build/CODE.md` + `.design/build/components/`
19
19
  **Agent:** `gsp-design-engineer`
20
20
  </objective>
@@ -27,24 +27,33 @@ Translate designs into production-ready frontend code.
27
27
  <process>
28
28
  ## Step 1: Load context
29
29
 
30
+ Read `.design/config.json` to get `implementation_target`.
31
+
30
32
  Read:
31
- - `.design/specs/FIGMA-SPECS.md` — component specs
33
+ - `.design/specs/SPECS.md` — implementation specs (primary input)
32
34
  - `.design/system/SYSTEM.md` — design system
33
35
  - `.design/system/tokens.json` — design tokens
34
36
  - `.design/BRIEF.md` — tech stack preference
35
37
  - `.design/review/CRITIQUE.md` — any fixes to incorporate
36
38
 
37
- If FIGMA-SPECS.md doesn't exist, tell the user to run `/gsp:spec` first.
39
+ If SPECS.md doesn't exist, check if `implementation_target` is `skip`:
40
+ - **If `skip`:** Read `.design/screens/SCREENS.md` + `.design/system/SYSTEM.md` as primary input instead
41
+ - **If not `skip`:** Tell the user to run `/gsp:spec` first
38
42
 
39
43
  Determine tech stack from BRIEF.md config (default: React + Tailwind).
40
44
 
41
45
  ## Step 2: Spawn design engineer
42
46
 
43
47
  Spawn the `gsp-design-engineer` agent with:
44
- - All specs, system, and token files
48
+ - All specs/screens, system, and token files
45
49
  - The Design-to-Code Translator prompt (09)
46
50
  - The build output template
47
51
  - The target tech stack
52
+ - The `implementation_target` value
53
+
54
+ **When `shadcn`:** Agent should use `npx shadcn@latest add` for components, extend with custom variants as defined in SPECS.md.
55
+
56
+ **When `rn-reusables`:** Agent should use `npx @react-native-reusables/cli add` for components, configure NativeWind theming.
48
57
 
49
58
  The agent should deliver:
50
59
  1. Component hierarchy with props, state, data flow
@@ -6,6 +6,8 @@ allowed-tools:
6
6
  - Write
7
7
  - Bash
8
8
  - Task
9
+ - Grep
10
+ - Glob
9
11
  ---
10
12
  <context>
11
13
  Phase 4 of the GSP design pipeline. Uses the UI/UX Pattern Master prompt to design core screens following Apple HIG and the project's design system.
@@ -32,16 +34,33 @@ Read:
32
34
  - `.design/BRIEF.md` — app type, audience, goals
33
35
  - `.design/system/SYSTEM.md` — design system to use
34
36
  - `.design/brand/IDENTITY.md` — brand personality
37
+ - `.design/config.json` — get `implementation_target`
35
38
 
36
39
  If SYSTEM.md doesn't exist, tell the user to run `/gsp:system` first.
37
40
 
38
- ## Step 2: Spawn UI designer
41
+ ## Step 2: Scan codebase for existing components
42
+
43
+ When `implementation_target` is `shadcn`, `rn-reusables`, `existing`, or `code` (anything except `figma`):
44
+
45
+ Scan the codebase for existing layouts and components:
46
+ - Look for `components/`, `src/components/`, `components/ui/`, `lib/components/`
47
+ - Look for shadcn `components/ui/` or RN Reusables `components/ui/`
48
+ - Look for Expo `app/` layouts, Next.js `app/` layouts, or other layout files
49
+ - Look for page/screen files to understand existing structure
50
+
51
+ Build an **Existing Components** inventory summarizing what's already built and reusable.
52
+
53
+ Pass this inventory to the agent so screen designs can reference existing components.
54
+
55
+ ## Step 3: Spawn UI designer
39
56
 
40
57
  Spawn the `gsp-ui-designer` agent with:
41
58
  - All prior artifacts
42
59
  - The UI/UX Pattern Master prompt (03)
43
60
  - The design output template
44
61
  - The Apple HIG patterns reference
62
+ - The `implementation_target` value
63
+ - The existing components inventory (if gathered in Step 2)
45
64
 
46
65
  The agent should deliver:
47
66
  1. User personas with goals and pain points
@@ -52,20 +71,26 @@ The agent should deliver:
52
71
  6. Accessibility specs (WCAG, VoiceOver, Dynamic Type)
53
72
  7. Micro-interactions and animations
54
73
  8. Responsive behavior across breakpoints
55
- 9. Designer's notes
74
+ 9. **Component Plan** (when target is not `figma`)
75
+ 10. Designer's notes
56
76
 
57
- ## Step 3: Write output
77
+ ## Step 4: Write output
58
78
 
59
79
  Write screens to `.design/screens/SCREENS.md`.
60
80
 
61
- ## Step 4: Update state
81
+ ## Step 5: Update state
62
82
 
63
83
  Update `.design/STATE.md`:
64
84
  - Set Phase 4 (Design) status to `complete`
65
85
  - Record completion date
66
86
 
67
- ## Step 5: Route next
87
+ ## Step 6: Route next
68
88
 
69
89
  Display screen summary (screen count, key flows) and end with:
70
- "Run `/gsp:spec` to generate Figma-ready specifications."
90
+
91
+ **When `implementation_target` is `skip`:**
92
+ "Run `/gsp:review` for design critique and accessibility audit."
93
+
94
+ **Otherwise:**
95
+ "Run `/gsp:spec` to generate implementation specifications."
71
96
  </process>
@@ -30,7 +30,7 @@ DESIGN PIPELINE (run in order)
30
30
  /gsp:brand Phase 2 — Brand identity (strategy, logo, color, type)
31
31
  /gsp:system Phase 3 — Design system foundations + tokens
32
32
  /gsp:design Phase 4 — UI/UX screens & interaction flows
33
- /gsp:spec Phase 5 — Figma-ready specifications
33
+ /gsp:spec Phase 5 — Implementation specifications
34
34
  /gsp:review Phase 6 — Design critique + accessibility audit
35
35
  /gsp:build Phase 7 — Design-to-code translation
36
36
  /gsp:launch Phase 8 — Marketing campaign assets
@@ -52,7 +52,7 @@ PROJECT STRUCTURE
52
52
  ├── system/SYSTEM.md Design system
53
53
  ├── system/tokens.json Design tokens
54
54
  ├── screens/SCREENS.md UI/UX screens
55
- ├── specs/FIGMA-SPECS.md Figma specifications
55
+ ├── specs/SPECS.md Implementation specifications
56
56
  ├── review/CRITIQUE.md Design critique
57
57
  ├── review/ACCESSIBILITY.md WCAG audit
58
58
  ├── build/CODE.md Implementation guide
@@ -54,6 +54,13 @@ Use the questioning techniques from the reference. Ask in 3 conversational round
54
54
  **Round 2 — Scope & Constraints:**
55
55
  - Platforms (web, iOS, Android)?
56
56
  - Tech stack preferences?
57
+ - Implementation target — how will designs become code?
58
+ - Using a UI kit? (shadcn/ui → `shadcn`, React Native Reusables → `rn-reusables`)
59
+ - Existing design system already in the codebase? (`existing`)
60
+ - Need Figma handoff? (`figma`)
61
+ - Straight to code with no specific UI kit? (`code`)
62
+ - Skip specs entirely, build directly from screen designs? (`skip`)
63
+ - Default: `code`
57
64
  - Key screens/pages needed?
58
65
  - Accessibility level (default: WCAG 2.2 AA)?
59
66
  - Timeline and constraints?
@@ -76,7 +83,7 @@ Using the templates, fill in the gathered information:
76
83
  1. Write `.design/BRIEF.md` from the project template with all gathered info
77
84
  2. Write `.design/ROADMAP.md` from the roadmap template with project name and date
78
85
  3. Write `.design/STATE.md` from the state template
79
- 4. Write `.design/config.json` from the config template with preferences
86
+ 4. Write `.design/config.json` from the config template with preferences (including `implementation_target` from Round 2)
80
87
 
81
88
  ## Step 5: Confirm and route
82
89
 
@@ -29,7 +29,7 @@ Read `.design/STATE.md` and `.design/BRIEF.md`.
29
29
 
30
30
  ## Step 3: Calculate prettiness
31
31
 
32
- Count completed phases out of 8. Calculate percentage.
32
+ Count completed and skipped phases out of 8. Both count toward progress. Calculate percentage.
33
33
 
34
34
  ## Step 4: Display progress
35
35
 
@@ -52,7 +52,7 @@ Phase Progress:
52
52
  Review Loops: {COUNT}
53
53
  ```
54
54
 
55
- Use ✅ for complete, 🔄 for in-progress/needs-revision, ⬜ for pending.
55
+ Use ✅ for complete, ⏭️ for skipped, 🔄 for in-progress/needs-revision, ⬜ for pending.
56
56
 
57
57
  ## Step 5: Route next
58
58
 
@@ -30,14 +30,18 @@ Critique design quality and audit accessibility compliance.
30
30
  <process>
31
31
  ## Step 1: Load context
32
32
 
33
+ Read `.design/config.json` to get `implementation_target`.
34
+
33
35
  Read all prior artifacts:
34
36
  - `.design/BRIEF.md`
35
37
  - `.design/brand/IDENTITY.md`
36
38
  - `.design/system/SYSTEM.md`
37
39
  - `.design/screens/SCREENS.md`
38
- - `.design/specs/FIGMA-SPECS.md`
40
+ - `.design/specs/SPECS.md` (if it exists)
41
+
42
+ If SCREENS.md doesn't exist, tell the user to complete the design phase first.
39
43
 
40
- If SCREENS.md or FIGMA-SPECS.md don't exist, tell the user to complete design and spec phases first.
44
+ If SPECS.md doesn't exist and `implementation_target` is not `skip`, tell the user to run `/gsp:spec` first. When target is `skip`, review SCREENS.md + SYSTEM.md without requiring SPECS.md.
41
45
 
42
46
  ## Step 2: Spawn critics (parallel)
43
47
 
@@ -1,26 +1,28 @@
1
1
  ---
2
2
  name: gsp:spec
3
- description: Generate Figma-ready specifications with auto-layout and tokens
3
+ description: Generate implementation specifications map design to your UI framework
4
4
  allowed-tools:
5
5
  - Read
6
6
  - Write
7
7
  - Bash
8
8
  - Task
9
+ - Grep
10
+ - Glob
9
11
  ---
10
12
  <context>
11
- Phase 5 of the GSP design pipeline. Uses the Figma Auto-Layout Expert prompt to convert screen designs into Figma-ready specifications.
13
+ Phase 5 of the GSP design pipeline. Converts screen designs into implementation specifications tailored to the project's UI framework (shadcn, RN Reusables, existing DS, Figma, or raw code specs).
12
14
  </context>
13
15
 
14
16
  <objective>
15
- Generate Figma-ready specifications from screen designs.
17
+ Generate implementation specifications from screen designs.
16
18
 
17
- **Input:** `.design/screens/SCREENS.md` + `.design/system/SYSTEM.md`
18
- **Output:** `.design/specs/FIGMA-SPECS.md`
19
+ **Input:** `.design/screens/SCREENS.md` + `.design/system/SYSTEM.md` + `.design/config.json`
20
+ **Output:** `.design/specs/SPECS.md`
19
21
  **Agent:** `gsp-spec-engineer`
20
22
  </objective>
21
23
 
22
24
  <execution_context>
23
- @/Users/jubs/.claude/get-shit-pretty/prompts/05-figma-auto-layout-expert.md
25
+ @/Users/jubs/.claude/get-shit-pretty/prompts/05-implementation-spec-expert.md
24
26
  @/Users/jubs/.claude/get-shit-pretty/templates/phases/spec.md
25
27
  </execution_context>
26
28
 
@@ -28,40 +30,58 @@ Generate Figma-ready specifications from screen designs.
28
30
  ## Step 1: Load context
29
31
 
30
32
  Read:
33
+ - `.design/config.json` — get `implementation_target` (default: `code`)
31
34
  - `.design/screens/SCREENS.md` — screen designs to convert
32
35
  - `.design/system/SYSTEM.md` — design system (tokens, components)
33
36
  - `.design/system/tokens.json` — token values
34
37
 
35
38
  If SCREENS.md doesn't exist, tell the user to run `/gsp:design` first.
36
39
 
37
- ## Step 2: Spawn spec engineer
40
+ ## Step 2: Check for skip
41
+
42
+ If `implementation_target` is `skip`:
43
+ 1. Update `.design/STATE.md` — set Phase 5 (Spec) status to `skipped`
44
+ 2. Display: "Spec phase skipped — implementation target is set to `skip`. Designs will feed directly into build."
45
+ 3. Route: "Run `/gsp:review` for design critique and accessibility audit."
46
+ 4. Stop here.
47
+
48
+ ## Step 3: Gather target context
49
+
50
+ **When `existing`:** Scan the codebase for existing design system files:
51
+ - Look for `components/`, `src/components/`, `components/ui/`, `lib/components/`
52
+ - Look for token/theme files: `tailwind.config.*`, `theme.*`, `tokens.*`, `globals.css`
53
+ - Look for shadcn config: `components.json`
54
+ - Summarize what's found for the agent
55
+
56
+ **When `shadcn`:** Check for existing shadcn setup:
57
+ - Look for `components.json`, `components/ui/`
58
+ - Note which shadcn components are already installed
59
+
60
+ **When `rn-reusables`:** Check for existing RN Reusables setup:
61
+ - Look for `components/ui/`, NativeWind config, `tailwind.config.*`
62
+ - Check Expo app structure (`app/`, navigation config)
63
+ - Note which reusables are already installed
64
+
65
+ ## Step 4: Spawn spec engineer
38
66
 
39
67
  Spawn the `gsp-spec-engineer` agent with:
40
68
  - SCREENS.md, SYSTEM.md, and tokens.json
41
- - The Figma Auto-Layout Expert prompt (05)
69
+ - The Implementation Spec Expert prompt (05)
42
70
  - The spec output template
71
+ - The `implementation_target` value
72
+ - Any target-specific context gathered in Step 3
43
73
 
44
- The agent should deliver:
45
- 1. Frame structure with grids and constraints
46
- 2. Responsive rules
47
- 3. Auto-layout specs per component (direction, padding, spacing, alignment, resizing)
48
- 4. Component architecture with variants and properties
49
- 5. Design tokens mapped to Figma tokens
50
- 6. Prototype flows (triggers, animations)
51
- 7. Dev handoff setup (CSS, exports, naming)
52
- 8. Accessibility notes
53
-
54
- ## Step 3: Write output
74
+ ## Step 5: Write output
55
75
 
56
- Write specs to `.design/specs/FIGMA-SPECS.md`.
76
+ Write specs to `.design/specs/SPECS.md`.
57
77
 
58
- ## Step 4: Update state
78
+ ## Step 6: Update state
59
79
 
60
80
  Update `.design/STATE.md`:
61
81
  - Set Phase 5 (Spec) status to `complete`
62
82
  - Record completion date
63
83
 
64
- ## Step 5: Route next
84
+ ## Step 7: Route next
65
85
 
66
86
  Display spec summary and end with:
67
87
  "Run `/gsp:review` for design critique and accessibility audit."
@@ -30,9 +30,11 @@ Build a complete design system from the brand identity.
30
30
 
31
31
  Read:
32
32
  - `.design/brand/IDENTITY.md` — brand colors, type, personality
33
+ - `.design/brand/palettes.json` — tints.dev generated color palettes (11-stop OKLCH scales)
33
34
  - `.design/BRIEF.md` — platforms, tech stack, constraints
34
35
 
35
36
  If IDENTITY.md doesn't exist, tell the user to run `/gsp:brand` first.
37
+ If palettes.json exists, use its OKLCH values as the foundation for the color system tokens.
36
38
 
37
39
  ## Step 2: Spawn system architect
38
40
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "get-shit-pretty",
3
- "version": "0.1.1",
3
+ "version": "0.2.0",
4
4
  "description": "A design engineering system for Claude Code, OpenCode, Gemini, and Codex. Research → Brand → System → Design → Spec → Review → Build → Launch.",
5
5
  "bin": {
6
6
  "get-shit-pretty": "bin/install.js"
@@ -0,0 +1,42 @@
1
+ # The Implementation Spec Expert
2
+
3
+ **Category:** Design-to-Code Bridge
4
+ **Use when:** Mapping design decisions to a specific implementation target (UI kit, existing DS, Figma, or raw code specs)
5
+
6
+ ---
7
+
8
+ ## Prompt
9
+
10
+ Act as an Implementation Spec Engineer. Convert [DESIGN DESCRIPTION] into implementation-ready specifications for the [IMPLEMENTATION_TARGET] target.
11
+
12
+ **When target is `figma`:**
13
+ 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.
14
+
15
+ **When target is `shadcn`:**
16
+ 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.
17
+
18
+ **When target is `rn-reusables`:**
19
+ 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.
20
+
21
+ **When target is `existing`:**
22
+ 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).
23
+
24
+ **When target is `code`:**
25
+ 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.
26
+
27
+ ---
28
+
29
+ ## Variables
30
+
31
+ - `[DESIGN DESCRIPTION]` — Description of the design to convert to implementation specs
32
+ - `[IMPLEMENTATION_TARGET]` — One of: `figma`, `shadcn`, `rn-reusables`, `existing`, `code`
33
+
34
+ ## Expected Output
35
+
36
+ - Component mapping to target primitives
37
+ - Token mapping to target theming format
38
+ - Component architecture (hierarchy, props, state, composition)
39
+ - Responsive behavior specifications
40
+ - Interaction and animation specs
41
+ - Target-specific setup and installation notes
42
+ - Accessibility annotations
@@ -106,6 +106,57 @@ process.stdin.on('end', () => {
106
106
  } catch (e) {}
107
107
  }
108
108
 
109
+ // ── Update check ──
110
+ let updateTag = '';
111
+ try {
112
+ const gspDir = path.join(homeDir, '.claude', 'get-shit-pretty');
113
+ const versionFile = path.join(gspDir, 'VERSION');
114
+ const cacheFile = path.join(gspDir, '.update-cache.json');
115
+
116
+ if (fs.existsSync(versionFile)) {
117
+ const installed = fs.readFileSync(versionFile, 'utf8').trim();
118
+ let latest = null;
119
+ let shouldCheck = true;
120
+
121
+ // Read cache (check once per 24h)
122
+ if (fs.existsSync(cacheFile)) {
123
+ try {
124
+ const cache = JSON.parse(fs.readFileSync(cacheFile, 'utf8'));
125
+ const age = Date.now() - (cache.ts || 0);
126
+ if (age < 86400000) {
127
+ latest = cache.latest || null;
128
+ shouldCheck = false;
129
+ }
130
+ } catch (e) {}
131
+ }
132
+
133
+ // Background check if cache is stale
134
+ if (shouldCheck) {
135
+ const { execFile } = require('child_process');
136
+ execFile('npm', ['view', 'get-shit-pretty', 'version', '--json'], { timeout: 5000 }, (err, stdout) => {
137
+ if (!err && stdout) {
138
+ try {
139
+ const ver = JSON.parse(stdout.trim());
140
+ fs.writeFileSync(cacheFile, JSON.stringify({ latest: ver, ts: Date.now() }));
141
+ } catch (e) {}
142
+ }
143
+ });
144
+ }
145
+
146
+ // Compare versions if we have cached latest
147
+ if (latest && latest !== installed) {
148
+ const iParts = installed.split('.').map(Number);
149
+ const lParts = latest.split('.').map(Number);
150
+ const isNewer = lParts[0] > iParts[0] ||
151
+ (lParts[0] === iParts[0] && lParts[1] > iParts[1]) ||
152
+ (lParts[0] === iParts[0] && lParts[1] === iParts[1] && lParts[2] > iParts[2]);
153
+ if (isNewer) {
154
+ updateTag = ` \x1b[33m\u2191 v${latest}\x1b[0m`;
155
+ }
156
+ }
157
+ }
158
+ } catch (e) {}
159
+
109
160
  // ── Output ──
110
161
  const dirname = path.basename(dir);
111
162
  const parts = [`\x1b[2m${model}\x1b[0m`];
@@ -125,7 +176,7 @@ process.stdin.on('end', () => {
125
176
  parts.push(`\x1b[2m${dirname}\x1b[0m`);
126
177
  }
127
178
 
128
- process.stdout.write(parts.join(' \u2502 ') + ctx);
179
+ process.stdout.write(parts.join(' \u2502 ') + ctx + updateTag);
129
180
  } catch (e) {
130
181
  // Silent fail
131
182
  }
@@ -10,6 +10,7 @@
10
10
  "tech_stack": "React + Tailwind",
11
11
  "accessibility_level": "WCAG 2.2 AA",
12
12
  "design_tool": "Figma",
13
+ "implementation_target": "code",
13
14
  "auto_review": true
14
15
  },
15
16
  "phases": {
@@ -1,60 +1,46 @@
1
- # Figma Specifications
1
+ # Implementation Specifications
2
2
 
3
3
  ## Project: {PROJECT_NAME}
4
4
  **Date:** {DATE}
5
+ **Implementation Target:** {TARGET}
5
6
 
6
7
  ---
7
8
 
8
- ## Frame Structure
9
- <!-- Page organization and frame hierarchy -->
9
+ <!-- Output sections vary by implementation_target. See agent instructions for target-specific sections. -->
10
10
 
11
- ## Grid & Constraints
12
- - **Grid:** {GRID_SPEC}
13
- - **Constraints:** {CONSTRAINTS}
14
- - **Responsive rules:** {RULES}
11
+ ## Component Mapping
12
+ <!-- Maps design components to implementation target primitives -->
15
13
 
16
- ## Auto-Layout Specs
17
-
18
- ### {COMPONENT_NAME}
19
- - **Direction:** Vertical/Horizontal
20
- - **Padding:** {TOP} {RIGHT} {BOTTOM} {LEFT}
21
- - **Spacing:** {GAP}px
22
- - **Alignment:** {ALIGNMENT}
23
- - **Resizing:** {HORIZONTAL_RESIZE} / {VERTICAL_RESIZE}
24
-
25
- <!-- Repeat for each component -->
26
-
27
- ## Component Architecture
28
- <!-- Variants, properties, and slot definitions -->
29
-
30
- | Component | Variants | Properties |
31
- |-----------|----------|------------|
14
+ | Design Component | Target Primitive | Notes |
15
+ |-----------------|-----------------|-------|
32
16
  | | | |
33
17
 
34
- ## Design Tokens
18
+ ## Token Mapping
19
+ <!-- Maps GSP design tokens to target's theming format -->
35
20
 
36
21
  ### Colors
37
- | Token | Value | Usage |
38
- |-------|-------|-------|
22
+ | GSP Token | Target Variable | Value |
23
+ |-----------|----------------|-------|
39
24
  | | | |
40
25
 
41
- ### Text Styles
42
- | Token | Font | Size | Weight | Line Height |
43
- |-------|------|------|--------|-------------|
26
+ ### Typography
27
+ | GSP Token | Target Variable | Font | Size | Weight |
28
+ |-----------|----------------|------|------|--------|
44
29
  | | | | | |
45
30
 
46
- ### Effects
47
- | Token | Type | Value |
48
- |-------|------|-------|
31
+ ### Spacing & Effects
32
+ | GSP Token | Target Variable | Value |
33
+ |-----------|----------------|-------|
49
34
  | | | |
50
35
 
51
- ## Prototype Flows
52
- | Flow | Trigger | Animation | Duration |
53
- |------|---------|-----------|----------|
54
- | | | | |
36
+ ## Component Architecture
37
+ <!-- Component hierarchy, props, state, composition -->
38
+
39
+ ## Responsive Specs
40
+ <!-- Breakpoints, layout shifts, component adaptations -->
41
+
42
+ ## Interaction Specs
43
+ <!-- Triggers, state transitions, animations -->
55
44
 
56
- ## Dev Handoff
57
- - **Naming convention:** {CONVENTION}
58
- - **Export formats:** {FORMATS}
59
- - **CSS mapping:** {CSS}
60
- - **Accessibility notes:** {A11Y}
45
+ ## Implementation Notes
46
+ <!-- Target-specific setup, installation, and integration notes -->
@@ -36,9 +36,9 @@
36
36
  ## Phase 5: Spec
37
37
  **Status:** pending
38
38
  **Command:** `/gsp:spec`
39
- **Input:** SCREENS.md + SYSTEM.md
40
- **Output:** `.design/specs/FIGMA-SPECS.md`
41
- **Goal:** Generate Figma-ready specifications with auto-layout and tokens.
39
+ **Input:** SCREENS.md + SYSTEM.md + config.json
40
+ **Output:** `.design/specs/SPECS.md`
41
+ **Goal:** Map design decisions to implementation target (UI kit, existing DS, or code specs).
42
42
 
43
43
  ## Phase 6: Review
44
44
  **Status:** pending
@@ -50,7 +50,7 @@
50
50
  ## Phase 7: Build
51
51
  **Status:** pending
52
52
  **Command:** `/gsp:build`
53
- **Input:** FIGMA-SPECS.md + SYSTEM.md
53
+ **Input:** SPECS.md + SYSTEM.md (or SCREENS.md + SYSTEM.md when spec is skipped)
54
54
  **Output:** `.design/build/CODE.md` + `components/`
55
55
  **Goal:** Translate design into production-ready frontend code.
56
56
 
@@ -15,7 +15,7 @@
15
15
  | 2 | Brand | pending | — | — |
16
16
  | 3 | System | pending | — | — |
17
17
  | 4 | Design | pending | — | — |
18
- | 5 | Spec | pending | — | — |
18
+ | 5 | Spec | pending/skipped | — | — |
19
19
  | 6 | Review | pending | — | — |
20
20
  | 7 | Build | pending | — | — |
21
21
  | 8 | Launch | pending | — | — |
@@ -26,6 +26,10 @@
26
26
  | Loop | Date | Issues Found | Issues Fixed | Resubmitted |
27
27
  |------|------|-------------|-------------|-------------|
28
28
 
29
+ ## Status Values
30
+ <!-- pending | in-progress | complete | needs-revision | skipped -->
31
+ <!-- Skipped phases count as complete for prettiness calculation -->
32
+
29
33
  ## Decisions
30
34
  <!-- Key design decisions and rationale -->
31
35
 
@@ -1,27 +0,0 @@
1
- # The Figma Auto-Layout Expert
2
-
3
- **Category:** Design Tools & Specs
4
- **Use when:** Converting designs into Figma-ready specifications
5
-
6
- ---
7
-
8
- ## Prompt
9
-
10
- Act as a Figma Design Ops Specialist. Convert [DESIGN DESCRIPTION] into Figma-ready specs. 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.
11
-
12
- ---
13
-
14
- ## Variables
15
-
16
- - `[DESIGN DESCRIPTION]` — Description of the design to convert to Figma specs
17
-
18
- ## Expected Output
19
-
20
- - Frame structure with grids and constraints
21
- - Responsive rules
22
- - Auto-layout specs (direction, padding, spacing, alignment, resizing)
23
- - Component architecture with variants and properties
24
- - Design tokens (colors, text styles, effects)
25
- - Prototype flows (triggers, animations)
26
- - Dev handoff setup (CSS, exports, naming conventions)
27
- - Accessibility notes