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 +274 -60
- package/agents/gsp-brand-strategist.md +5 -4
- package/agents/gsp-design-engineer.md +9 -2
- package/agents/gsp-spec-engineer.md +93 -17
- package/agents/gsp-system-architect.md +1 -1
- package/agents/gsp-ui-designer.md +9 -1
- package/commands/gsp/brand.md +29 -3
- package/commands/gsp/build.md +14 -5
- package/commands/gsp/design.md +31 -6
- package/commands/gsp/help.md +2 -2
- package/commands/gsp/new-project.md +8 -1
- package/commands/gsp/progress.md +2 -2
- package/commands/gsp/review.md +6 -2
- package/commands/gsp/spec.md +42 -22
- package/commands/gsp/system.md +2 -0
- package/package.json +1 -1
- package/prompts/05-implementation-spec-expert.md +42 -0
- package/scripts/gsp-statusline.js +52 -1
- package/templates/config.json +1 -0
- package/templates/phases/spec.md +27 -41
- package/templates/roadmap.md +4 -4
- package/templates/state.md +5 -1
- package/prompts/05-figma-auto-layout-expert.md +0 -27
package/README.md
CHANGED
|
@@ -1,69 +1,173 @@
|
|
|
1
|
-
|
|
1
|
+
<div align="center">
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
# GET SHIT PRETTY
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
**Design engineering for AI coding tools.**
|
|
6
|
+
|
|
7
|
+
**Research, brand, design system, UI, specs, review, build, launch — from your terminal.**
|
|
8
|
+
|
|
9
|
+
[](https://www.npmjs.com/package/get-shit-pretty)
|
|
10
|
+
[](https://www.npmjs.com/package/get-shit-pretty)
|
|
11
|
+
[](https://github.com/jubscodes/get-shit-pretty)
|
|
12
|
+
[](LICENSE)
|
|
13
|
+
|
|
14
|
+
<br>
|
|
6
15
|
|
|
7
16
|
```bash
|
|
8
17
|
npx get-shit-pretty
|
|
9
18
|
```
|
|
10
19
|
|
|
11
|
-
|
|
20
|
+
**Works on Mac, Windows, and Linux.**
|
|
12
21
|
|
|
13
|
-
|
|
14
|
-
# Claude Code (global)
|
|
15
|
-
npx get-shit-pretty --claude --global
|
|
22
|
+
<br>
|
|
16
23
|
|
|
17
|
-
|
|
18
|
-
npx get-shit-pretty --all --global
|
|
24
|
+
*"Vibe-coded apps work. They also all look the same. GSP fixes that."*
|
|
19
25
|
|
|
20
|
-
|
|
21
|
-
|
|
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
|
-
|
|
25
|
-
|
|
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
|
-
```
|
|
28
|
-
|
|
29
|
-
cd ~/get-shit-pretty
|
|
30
|
-
chmod +x install.sh
|
|
31
|
-
./install.sh
|
|
72
|
+
```
|
|
73
|
+
/gsp:research
|
|
32
74
|
```
|
|
33
75
|
|
|
34
|
-
|
|
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
|
-
|
|
78
|
+
**Creates:** `.design/research/TRENDS.md`
|
|
37
79
|
|
|
38
|
-
|
|
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
|
-
|
|
82
|
+
### 3. Brand
|
|
51
83
|
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
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
|
-
|
|
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/
|
|
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
|
-
|
|
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
|
-
|
|
269
|
+
# OpenCode
|
|
270
|
+
npx get-shit-pretty --opencode --global
|
|
93
271
|
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
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
|
-
|
|
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** —
|
|
23
|
-
5. **
|
|
24
|
-
6. **
|
|
25
|
-
7. **
|
|
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
|
|
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
|
|
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
|
|
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
|
-
|
|
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. **
|
|
20
|
-
2. **
|
|
21
|
-
3. **
|
|
22
|
-
4. **
|
|
23
|
-
5. **
|
|
24
|
-
6. **
|
|
25
|
-
|
|
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
|
|
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
|
-
-
|
|
32
|
-
-
|
|
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/
|
|
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,
|
|
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
|
|
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. **
|
|
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>
|
package/commands/gsp/brand.md
CHANGED
|
@@ -51,17 +51,43 @@ The agent should deliver:
|
|
|
51
51
|
6. Brand applications
|
|
52
52
|
7. Brand book structure
|
|
53
53
|
|
|
54
|
-
## Step 3:
|
|
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
|
|
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
|
|
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."
|
package/commands/gsp/build.md
CHANGED
|
@@ -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
|
|
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/
|
|
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/
|
|
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
|
|
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
|
package/commands/gsp/design.md
CHANGED
|
@@ -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:
|
|
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.
|
|
74
|
+
9. **Component Plan** (when target is not `figma`)
|
|
75
|
+
10. Designer's notes
|
|
56
76
|
|
|
57
|
-
## Step
|
|
77
|
+
## Step 4: Write output
|
|
58
78
|
|
|
59
79
|
Write screens to `.design/screens/SCREENS.md`.
|
|
60
80
|
|
|
61
|
-
## Step
|
|
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
|
|
87
|
+
## Step 6: Route next
|
|
68
88
|
|
|
69
89
|
Display screen summary (screen count, key flows) and end with:
|
|
70
|
-
|
|
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>
|
package/commands/gsp/help.md
CHANGED
|
@@ -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 —
|
|
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/
|
|
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
|
|
package/commands/gsp/progress.md
CHANGED
|
@@ -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
|
|
package/commands/gsp/review.md
CHANGED
|
@@ -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/
|
|
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
|
|
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
|
|
package/commands/gsp/spec.md
CHANGED
|
@@ -1,26 +1,28 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: gsp:spec
|
|
3
|
-
description: Generate
|
|
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.
|
|
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
|
|
17
|
+
Generate implementation specifications from screen designs.
|
|
16
18
|
|
|
17
|
-
**Input:** `.design/screens/SCREENS.md` + `.design/system/SYSTEM.md`
|
|
18
|
-
**Output:** `.design/specs/
|
|
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-
|
|
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:
|
|
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
|
|
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
|
-
|
|
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/
|
|
76
|
+
Write specs to `.design/specs/SPECS.md`.
|
|
57
77
|
|
|
58
|
-
## Step
|
|
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
|
|
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."
|
package/commands/gsp/system.md
CHANGED
|
@@ -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.
|
|
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
|
}
|
package/templates/config.json
CHANGED
package/templates/phases/spec.md
CHANGED
|
@@ -1,60 +1,46 @@
|
|
|
1
|
-
#
|
|
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
|
-
|
|
9
|
-
<!-- Page organization and frame hierarchy -->
|
|
9
|
+
<!-- Output sections vary by implementation_target. See agent instructions for target-specific sections. -->
|
|
10
10
|
|
|
11
|
-
##
|
|
12
|
-
|
|
13
|
-
- **Constraints:** {CONSTRAINTS}
|
|
14
|
-
- **Responsive rules:** {RULES}
|
|
11
|
+
## Component Mapping
|
|
12
|
+
<!-- Maps design components to implementation target primitives -->
|
|
15
13
|
|
|
16
|
-
|
|
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
|
-
##
|
|
18
|
+
## Token Mapping
|
|
19
|
+
<!-- Maps GSP design tokens to target's theming format -->
|
|
35
20
|
|
|
36
21
|
### Colors
|
|
37
|
-
| Token |
|
|
38
|
-
|
|
22
|
+
| GSP Token | Target Variable | Value |
|
|
23
|
+
|-----------|----------------|-------|
|
|
39
24
|
| | | |
|
|
40
25
|
|
|
41
|
-
###
|
|
42
|
-
| Token | Font | Size | Weight |
|
|
43
|
-
|
|
26
|
+
### Typography
|
|
27
|
+
| GSP Token | Target Variable | Font | Size | Weight |
|
|
28
|
+
|-----------|----------------|------|------|--------|
|
|
44
29
|
| | | | | |
|
|
45
30
|
|
|
46
|
-
### Effects
|
|
47
|
-
| Token |
|
|
48
|
-
|
|
31
|
+
### Spacing & Effects
|
|
32
|
+
| GSP Token | Target Variable | Value |
|
|
33
|
+
|-----------|----------------|-------|
|
|
49
34
|
| | | |
|
|
50
35
|
|
|
51
|
-
##
|
|
52
|
-
|
|
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
|
-
##
|
|
57
|
-
-
|
|
58
|
-
- **Export formats:** {FORMATS}
|
|
59
|
-
- **CSS mapping:** {CSS}
|
|
60
|
-
- **Accessibility notes:** {A11Y}
|
|
45
|
+
## Implementation Notes
|
|
46
|
+
<!-- Target-specific setup, installation, and integration notes -->
|
package/templates/roadmap.md
CHANGED
|
@@ -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/
|
|
41
|
-
**Goal:**
|
|
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:**
|
|
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
|
|
package/templates/state.md
CHANGED
|
@@ -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
|