|
1
|
--- |
|
2
|
name: mockup-graduate |
|
3
|
description: "Use when the user approves a mockup on the canvas and wants it integrated into their main app. Reads the approved mockup component, analyzes the main app's patterns, transforms the mockup to match, installs dependencies, and verifies the integration. Activate when the user says 'use this one', 'put this in my app', 'I like variant B, integrate it', 'graduate this mockup', or approves a design for production." |
|
4
|
--- |
|
5
|
|
|
6
|
# Mockup Graduate Skill |
|
7
|
|
|
8
|
Move an approved mockup from the mockup sandbox (`mockup`) into the main app. Transform the self-contained prototype into production code that matches the app's conventions. |
|
9
|
|
|
10
|
## When to Use |
|
11
|
|
|
12
|
Activate this skill when the user: |
|
13
|
|
|
14
|
- Approves a mockup variant ("I like this one", "go with the bold version") |
|
15
|
- Asks to integrate a mockup ("put this in my app", "use this design") |
|
16
|
- Wants to graduate a prototype to production |
|
17
|
- Says "ship it" or "let's go with this" |
|
18
|
|
|
19
|
## Subagent Guidance |
|
20
|
|
|
21
|
If you need to parallelize graduation (e.g., graduate multiple pages at once), use a **GENERAL** subagent — never a DESIGN subagent. Graduation is an engineering task (understanding app architecture, transforming mockup code to production patterns, wiring routing and state) that requires codebase navigation, not creative visual output. |
|
22
|
|
|
23
|
## Prerequisites |
|
24
|
|
|
25
|
- The mockup sandbox must be running ({{skill("mockup-sandbox")}}) |
|
26
|
- The user must have identified which mockup to graduate (if multiple variants exist, ask which one) |
|
27
|
|
|
28
|
## Process |
|
29
|
|
|
30
|
### Step 1: Identify the approved mockup |
|
31
|
|
|
32
|
Confirm which mockup the user wants. Read the mockup component file and extract key design decisions: colors, gradients, shadows, typography, layout approach, icons, and animations. |
|
33
|
|
|
34
|
### Step 2: Analyze the main app's patterns |
|
35
|
|
|
36
|
Understand how the main app handles routing, state management, data fetching, styling, and component structure. Read a few existing components to understand conventions. |
|
37
|
|
|
38
|
### Step 3: Plan the transformation |
|
39
|
|
|
40
|
Map each part of the mockup to the main app's equivalent: |
|
41
|
|
|
42
|
| Mockup | Main App | |
|
43
|
|---|---| |
|
44
|
| Hardcoded mock data | API call or data hook | |
|
45
|
| Inline sub-components | Existing shared components where they exist | |
|
46
|
| Direct `className` styling | App's styling approach (may be the same) | |
|
47
|
| `@/components/ui/*` (sandbox shadcn) | App's UI component library (may differ) | |
|
48
|
| Static images from `mockup/` | App's asset directory or CDN | |
|
49
|
|
|
50
|
### Step 4: Install missing dependencies |
|
51
|
|
|
52
|
Compare the mockup's imports against the main app's `package.json`. Install anything missing using the `packager_install_tool`. Add font links to `index.html` if needed. |
|
53
|
|
|
54
|
### Step 5: Transform and place the component |
|
55
|
|
|
56
|
Create the production component in the main app. Replace mock data with real data fetching, wire up navigation, connect to app state, and adapt UI components to the app's library. Copy any assets from `mockup/` to the main app's asset directory. |
|
57
|
|
|
58
|
### Step 6: Update routing and verify |
|
59
|
|
|
60
|
Add a route if the graduated component is a new page. If it replaces an existing component, update the import. Run the main app's linter, restart the workflow, and confirm it renders correctly. |
|
61
|
|
|
62
|
### Step 7: Clean up (optional) |
|
63
|
|
|
64
|
Ask the user if they want to remove the graduated mockup from the sandbox, keep it for reference, or remove the canvas iframes. Don't clean up automatically. |
|
65
|
|
|
66
|
## When Graduation Is Complex |
|
67
|
|
|
68
|
Most graduations are straightforward — just proceed. Only pause and check with the user when the main app uses a fundamentally different design system than the mockup (requiring a full visual translation), or when the graduation would require a complete refactor of the existing backend to support the new design. |
|
69
|
|
|
70
|
## What to Preserve |
|
71
|
|
|
72
|
These elements from the mockup should transfer exactly to production: |
|
73
|
|
|
74
|
- **Visual design:** Colors, gradients, shadows, border radius, spacing |
|
75
|
- **Typography:** Font families, weights, sizes, line heights |
|
76
|
- **Layout:** Grid/flex structure, responsive breakpoints, spacing |
|
77
|
- **Animations:** Transitions, hover states, entry animations |
|
78
|
- **Icons:** Same icon library and icon choices |
|
79
|
|
|
80
|
## What to Transform |
|
81
|
|
|
82
|
These elements need adaptation for production: |
|
83
|
|
|
84
|
- **Data:** Static mock data → real API calls or state |
|
85
|
- **Navigation:** No-op handlers → real router navigation |
|
86
|
- **State:** Local constants → app state management |
|
87
|
- **Auth:** Stubbed user objects → real auth context |
|
88
|
- **Error handling:** Add loading states, error boundaries, empty states |
|
89
|
- **Accessibility:** Add ARIA labels, keyboard navigation, focus management |
|
90
|
|
|
91
|
## Common Mistakes |
|
92
|
|
|
93
|
- **Losing visual fidelity during transformation.** Ship what was approved — don't "improve" the design during graduation. |
|
94
|
- **Forgetting loading and error states.** Mockups show the happy path. Production needs skeletons, error messages, and empty states. |
|
95
|
- **Not checking the UI component library.** If the main app uses different components than shadcn/ui, translate — don't just copy imports. |
|
96
|
- **Breaking existing functionality.** If replacing an existing component, ensure all existing features still work. |
|
97
|
- **Skipping responsive behavior.** If the mockup was designed at a single viewport, ensure it works at other breakpoints. |