get-shit-pretty 0.1.1 → 0.3.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-critic.md +54 -0
- package/agents/gsp-design-engineer.md +11 -2
- package/agents/gsp-spec-engineer.md +156 -17
- package/agents/gsp-system-architect.md +65 -1
- package/agents/gsp-ui-designer.md +78 -1
- package/commands/gsp/brand.md +29 -3
- package/commands/gsp/build.md +40 -5
- package/commands/gsp/design.md +65 -9
- package/commands/gsp/help.md +2 -2
- package/commands/gsp/new-project.md +67 -10
- package/commands/gsp/progress.md +2 -2
- package/commands/gsp/review.md +19 -2
- package/commands/gsp/spec.md +62 -21
- package/commands/gsp/system.md +61 -3
- package/package.json +1 -1
- package/prompts/01-design-system-architect.md +35 -3
- package/prompts/03-ui-ux-pattern-master.md +11 -1
- package/prompts/05-implementation-spec-expert.md +42 -0
- package/prompts/09-design-to-code-translator.md +9 -0
- package/references/chunk-format.md +35 -0
- package/scripts/gsp-statusline.js +52 -1
- package/templates/codebase-inventory.md +71 -0
- package/templates/config.json +4 -0
- package/templates/exports-index.md +69 -0
- package/templates/phases/spec.md +27 -41
- package/templates/phases/system.md +28 -0
- package/templates/project.md +6 -0
- 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")
|
package/agents/gsp-critic.md
CHANGED
|
@@ -53,3 +53,57 @@ Write critique to `.design/review/CRITIQUE.md`:
|
|
|
53
53
|
8. **Alternative Directions** — 2 redesign approaches with descriptions
|
|
54
54
|
9. **What Works Well** — Specific strengths to preserve
|
|
55
55
|
</output>
|
|
56
|
+
|
|
57
|
+
<chunked-exports>
|
|
58
|
+
## Chunked Exports
|
|
59
|
+
|
|
60
|
+
After writing CRITIQUE.md, generate an agent-consumable fix list.
|
|
61
|
+
|
|
62
|
+
### Output
|
|
63
|
+
|
|
64
|
+
Write `.design/review/exports/review-fixes.md` (~50-100 lines):
|
|
65
|
+
|
|
66
|
+
```markdown
|
|
67
|
+
# Review Fixes
|
|
68
|
+
|
|
69
|
+
> Phase: Review | Source: [CRITIQUE.md](../CRITIQUE.md) | Generated: {DATE}
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## Critical Fixes
|
|
74
|
+
|
|
75
|
+
- **[Screen/Component]:** {Issue} → {Concrete fix}
|
|
76
|
+
|
|
77
|
+
## Important Fixes
|
|
78
|
+
|
|
79
|
+
- **[Screen/Component]:** {Issue} → {Concrete fix}
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Related
|
|
84
|
+
|
|
85
|
+
- [CRITIQUE.md](../CRITIQUE.md) — full critique with heuristic scores
|
|
86
|
+
- [accessibility-fixes.md](./accessibility-fixes.md) — WCAG violations
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
### Rules
|
|
90
|
+
|
|
91
|
+
- Only include Critical and Important severity — skip Polish items
|
|
92
|
+
- Every fix must name the specific screen or component affected
|
|
93
|
+
- Every fix must include a concrete remediation (not just "improve X")
|
|
94
|
+
- Preserve exact issue descriptions from CRITIQUE.md
|
|
95
|
+
- See `references/chunk-format.md` for standard header, footer, naming, and size rules
|
|
96
|
+
|
|
97
|
+
### Update INDEX.md
|
|
98
|
+
|
|
99
|
+
Replace `<!-- BEGIN:review -->` … `<!-- END:review -->` in `.design/exports/INDEX.md` with:
|
|
100
|
+
|
|
101
|
+
```markdown
|
|
102
|
+
<!-- BEGIN:review -->
|
|
103
|
+
| Section | File |
|
|
104
|
+
|---------|------|
|
|
105
|
+
| Review Fixes | [review-fixes.md](../review/exports/review-fixes.md) |
|
|
106
|
+
| Accessibility Fixes | [accessibility-fixes.md](../review/exports/accessibility-fixes.md) |
|
|
107
|
+
<!-- END:review -->
|
|
108
|
+
```
|
|
109
|
+
</chunked-exports>
|
|
@@ -8,15 +8,24 @@ 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.
|
|
21
|
+
|
|
22
|
+
**Chunk-aware mode:** When chunked exports are provided instead of full monoliths (screen chunks, spec chunks, component chunks), work with the focused context. Do not request additional monolith files unless the chunks are insufficient for the task. This keeps your context lean and focused on the specific screen being built.
|
|
14
23
|
</role>
|
|
15
24
|
|
|
16
25
|
<methodology>
|
|
17
26
|
## Translation Process
|
|
18
27
|
|
|
19
|
-
1. **Map component hierarchy** — From specs, define the component tree with props, state, and data flow
|
|
28
|
+
1. **Map component hierarchy** — From specs (or screens if spec was skipped), define the component tree with props, state, and data flow
|
|
20
29
|
2. **Implement foundations** — Design tokens as CSS variables or Tailwind config, theme setup, global styles
|
|
21
30
|
3. **Build components** — One file per component with full implementation
|
|
22
31
|
4. **Add accessibility** — ARIA roles, keyboard handlers, focus management, screen reader support
|