@symbo.ls/mcp 1.0.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/.env.example +16 -0
- package/.env.railway +13 -0
- package/LICENSE +21 -0
- package/README.md +184 -0
- package/mcp.json +57 -0
- package/package.json +20 -0
- package/pyproject.toml +25 -0
- package/railway.toml +26 -0
- package/run.sh +17 -0
- package/symbols_mcp/__init__.py +1 -0
- package/symbols_mcp/server.py +1114 -0
- package/symbols_mcp/skills/ACCESSIBILITY.md +471 -0
- package/symbols_mcp/skills/ACCESSIBILITY_AUDITORY.md +70 -0
- package/symbols_mcp/skills/AGENT_INSTRUCTIONS.md +257 -0
- package/symbols_mcp/skills/BRAND_INDENTITY.md +69 -0
- package/symbols_mcp/skills/BUILT_IN_COMPONENTS.md +304 -0
- package/symbols_mcp/skills/CLAUDE.md +2158 -0
- package/symbols_mcp/skills/CLI_QUICK_START.md +205 -0
- package/symbols_mcp/skills/DESIGN_CRITIQUE.md +64 -0
- package/symbols_mcp/skills/DESIGN_DIRECTION.md +320 -0
- package/symbols_mcp/skills/DESIGN_SYSTEM_ARCHITECT.md +64 -0
- package/symbols_mcp/skills/DESIGN_SYSTEM_CONFIG.md +487 -0
- package/symbols_mcp/skills/DESIGN_SYSTEM_IN_PROPS.md +136 -0
- package/symbols_mcp/skills/DESIGN_TO_CODE.md +64 -0
- package/symbols_mcp/skills/DESIGN_TREND.md +50 -0
- package/symbols_mcp/skills/DOMQL_v2-v3_MIGRATION.md +236 -0
- package/symbols_mcp/skills/FIGMA_MATCHING.md +63 -0
- package/symbols_mcp/skills/GARY_TAN.md +80 -0
- package/symbols_mcp/skills/MARKETING_ASSETS.md +66 -0
- package/symbols_mcp/skills/MIGRATE_TO_SYMBOLS.md +614 -0
- package/symbols_mcp/skills/QUICKSTART.md +79 -0
- package/symbols_mcp/skills/SYMBOLS_LOCAL_INSTRUCTIONS.md +1405 -0
- package/symbols_mcp/skills/THE_PRESENTATION.md +69 -0
- package/symbols_mcp/skills/UI_UX_PATTERNS.md +68 -0
- package/windsurf-mcp-config.json +18 -0
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
The Design Trend Synthesizer
|
|
2
|
+
|
|
3
|
+
You are a Design Researcher at frog design, analyzing trends for Fortune 500 clients.
|
|
4
|
+
|
|
5
|
+
Research and synthesize current design trends for [INDUSTRY/SECTOR] in 2026.
|
|
6
|
+
|
|
7
|
+
Deliverables:
|
|
8
|
+
|
|
9
|
+
1. MACRO TREND ANALYSIS (5 trends)
|
|
10
|
+
For each trend:
|
|
11
|
+
- Trend name and definition
|
|
12
|
+
- Visual characteristics (colors, shapes, typography, imagery)
|
|
13
|
+
- Origin (where it started, early adopters)
|
|
14
|
+
- Current adoption phase (emerging/growing/mature)
|
|
15
|
+
- Examples (3 brands using it well)
|
|
16
|
+
- Strategic implications (opportunities and risks)
|
|
17
|
+
|
|
18
|
+
Trend areas to cover:
|
|
19
|
+
• Visual aesthetics (e.g., neomorphism, brutalism, liquid glass)
|
|
20
|
+
• Interaction patterns (e.g., gesture-based, voice-first, AI-assisted)
|
|
21
|
+
• Color trends (e.g., dopamine colors, muted minimalism)
|
|
22
|
+
• Typography trends (e.g., variable fonts, kinetic type)
|
|
23
|
+
• Technology influence (e.g., spatial design, generative UI)
|
|
24
|
+
|
|
25
|
+
2. COMPETITIVE LANDSCAPE MAPPING
|
|
26
|
+
• Map 10 competitors on a 2×2 matrix (Innovative ←→ Conservative × Minimal ←→ Rich)
|
|
27
|
+
• Identify white space opportunities
|
|
28
|
+
• Flag overused patterns to avoid
|
|
29
|
+
|
|
30
|
+
3. USER EXPECTATION SHIFTS
|
|
31
|
+
• How user behaviors have changed (post-AI, post-pandemic, Gen Z influence)
|
|
32
|
+
• New mental models to design for
|
|
33
|
+
• Friction points users no longer tolerate
|
|
34
|
+
|
|
35
|
+
4. PLATFORM-SPECIFIC EVOLUTION
|
|
36
|
+
• iOS 26/visionOS design language updates
|
|
37
|
+
• Material You evolution
|
|
38
|
+
• Web design pattern shifts
|
|
39
|
+
|
|
40
|
+
5. STRATEGIC RECOMMENDATIONS
|
|
41
|
+
• Which trends to adopt (and how to adapt them for our brand)
|
|
42
|
+
• Which trends to ignore (and why)
|
|
43
|
+
• 6-month trend roadmap (what to implement when)
|
|
44
|
+
|
|
45
|
+
6. MOOD BOARD SPECIFICATIONS
|
|
46
|
+
• 20 visual references described in detail (colors, composition, mood)
|
|
47
|
+
• Color palette extraction
|
|
48
|
+
• Typography recommendations based on trend analysis
|
|
49
|
+
|
|
50
|
+
Include citations to real brands, products, and design systems. Be specific, not generic.
|
|
@@ -0,0 +1,236 @@
|
|
|
1
|
+
# DOMQL v2 → v3 Migration Guide
|
|
2
|
+
|
|
3
|
+
This guide covers the key changes when migrating from DOMQL v2 to v3. The main updates focus on flattening object structures, renaming properties, and simplifying the API while maintaining backwards compatibility for most use cases.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Inheritance changes
|
|
8
|
+
|
|
9
|
+
### Flatten `props` and `on`
|
|
10
|
+
|
|
11
|
+
**Before:**
|
|
12
|
+
|
|
13
|
+
```js
|
|
14
|
+
{
|
|
15
|
+
props: {
|
|
16
|
+
position: 'absolute',
|
|
17
|
+
},
|
|
18
|
+
on: {
|
|
19
|
+
frame: (e, t) => {},
|
|
20
|
+
render: e => {},
|
|
21
|
+
wheel: (e, t) => {},
|
|
22
|
+
dblclick: (e, t) => {},
|
|
23
|
+
},
|
|
24
|
+
}
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
**After:**
|
|
28
|
+
|
|
29
|
+
```js
|
|
30
|
+
{
|
|
31
|
+
position: 'absolute',
|
|
32
|
+
onFrame: (e, t) => {},
|
|
33
|
+
onRender: e => {},
|
|
34
|
+
onWheel: (e, t) => {},
|
|
35
|
+
onDblclick: e => {},
|
|
36
|
+
}
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
**Rules:**
|
|
40
|
+
|
|
41
|
+
- Move all `props` entries one level up into the component object
|
|
42
|
+
- Applies to root and nested elements
|
|
43
|
+
- Remove the `on` wrapper
|
|
44
|
+
- Prefix each event with `on` + `CapitalizedEventName`
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
### Merging `props` inside nested elements
|
|
49
|
+
|
|
50
|
+
**Before:**
|
|
51
|
+
|
|
52
|
+
```js
|
|
53
|
+
Box: {
|
|
54
|
+
props: {
|
|
55
|
+
'--section-background': '#7a5e0e55',
|
|
56
|
+
id: 'editorjs'
|
|
57
|
+
}
|
|
58
|
+
}
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
**After:**
|
|
62
|
+
|
|
63
|
+
```js
|
|
64
|
+
Box: {
|
|
65
|
+
'--section-background': '#7a5e0e55',
|
|
66
|
+
id: 'editorjs'
|
|
67
|
+
}
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
- Remove the `props` wrapper and move contents up
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
### All nested objects within `props` stay inline
|
|
75
|
+
|
|
76
|
+
**Before:**
|
|
77
|
+
|
|
78
|
+
```js
|
|
79
|
+
props: {
|
|
80
|
+
style: {
|
|
81
|
+
height: "100%";
|
|
82
|
+
}
|
|
83
|
+
}
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
**After:**
|
|
87
|
+
|
|
88
|
+
```js
|
|
89
|
+
style: {
|
|
90
|
+
height: "100%";
|
|
91
|
+
}
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
## Naming changes
|
|
97
|
+
|
|
98
|
+
### Rename `extend` → `extends`
|
|
99
|
+
|
|
100
|
+
### Rename `childExtend` → `childExtends`
|
|
101
|
+
|
|
102
|
+
**Before:**
|
|
103
|
+
|
|
104
|
+
```js
|
|
105
|
+
extend: SomeComponent,
|
|
106
|
+
childExtend: AnotherComponent
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
**After:**
|
|
110
|
+
|
|
111
|
+
```js
|
|
112
|
+
extends: SomeComponent,
|
|
113
|
+
childExtends: AnotherComponent
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
- Property rename only
|
|
117
|
+
- No behavioral changes
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## Functional changes
|
|
122
|
+
|
|
123
|
+
Child elements are created **only if**:
|
|
124
|
+
|
|
125
|
+
- `children` array is present, **or**
|
|
126
|
+
- Child component keys start with `CapitalCase`
|
|
127
|
+
|
|
128
|
+
Event logic and all other JavaScript behavior remain unchanged.
|
|
129
|
+
|
|
130
|
+
### Element creation rules
|
|
131
|
+
|
|
132
|
+
**Before (v2):**
|
|
133
|
+
|
|
134
|
+
```js
|
|
135
|
+
{
|
|
136
|
+
div: {}, // creates <div>
|
|
137
|
+
Div: {}, // creates <Div>
|
|
138
|
+
}
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
**After (v3):**
|
|
142
|
+
|
|
143
|
+
```js
|
|
144
|
+
{
|
|
145
|
+
div: {}, // treated as a plain property, no rendering
|
|
146
|
+
Div: {}, // only way to create keyed children
|
|
147
|
+
}
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
- `Div` is equivalent to:
|
|
151
|
+
|
|
152
|
+
```js
|
|
153
|
+
Div: { extends: 'Div' }
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
- Rendering behavior:
|
|
157
|
+
- React → `<Div />`
|
|
158
|
+
- HTML → `<div />`
|
|
159
|
+
|
|
160
|
+
---
|
|
161
|
+
|
|
162
|
+
## Summary
|
|
163
|
+
|
|
164
|
+
DOMQL v3 removes DOMQL-specific wrappers and relies on flat, explicit object structures:
|
|
165
|
+
|
|
166
|
+
- Removed: `props`, `on`
|
|
167
|
+
- Events are flattened and prefixed with `onX`
|
|
168
|
+
- `extend` → `extends`
|
|
169
|
+
- `childExtend` → `childExtends`
|
|
170
|
+
- Only `CapitalCase` keys create child elements
|
|
171
|
+
|
|
172
|
+
---
|
|
173
|
+
|
|
174
|
+
## More examples
|
|
175
|
+
|
|
176
|
+
### From (v2)
|
|
177
|
+
|
|
178
|
+
```js
|
|
179
|
+
{
|
|
180
|
+
extend: 'Flex',
|
|
181
|
+
childExtend: 'ListItem',
|
|
182
|
+
props: {
|
|
183
|
+
position: 'absolute',
|
|
184
|
+
},
|
|
185
|
+
attr: {
|
|
186
|
+
'gs-w': 1,
|
|
187
|
+
'gs-h': 1,
|
|
188
|
+
},
|
|
189
|
+
SectionTitle: {
|
|
190
|
+
text: 'Notes',
|
|
191
|
+
},
|
|
192
|
+
Box: {
|
|
193
|
+
props: {
|
|
194
|
+
'--section-background': '#7a5e0e55',
|
|
195
|
+
id: 'editorjs',
|
|
196
|
+
'& a': {
|
|
197
|
+
color: 'blue',
|
|
198
|
+
},
|
|
199
|
+
},
|
|
200
|
+
on: {
|
|
201
|
+
frame: (e, t) => {},
|
|
202
|
+
render: e => {},
|
|
203
|
+
wheel: (e, t) => {},
|
|
204
|
+
dblclick: (e, t) => { e.stopPropagation() },
|
|
205
|
+
},
|
|
206
|
+
},
|
|
207
|
+
}
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
### To (v3)
|
|
211
|
+
|
|
212
|
+
```js
|
|
213
|
+
{
|
|
214
|
+
extends: 'Flex',
|
|
215
|
+
childExtends: 'ListItem',
|
|
216
|
+
position: 'absolute',
|
|
217
|
+
attr: {
|
|
218
|
+
'gs-w': 1,
|
|
219
|
+
'gs-h': 1,
|
|
220
|
+
},
|
|
221
|
+
SectionTitle: {
|
|
222
|
+
text: 'Notes',
|
|
223
|
+
},
|
|
224
|
+
Box: {
|
|
225
|
+
'--section-background': '#7a5e0e55',
|
|
226
|
+
id: 'editorjs',
|
|
227
|
+
'& a': {
|
|
228
|
+
color: 'blue',
|
|
229
|
+
},
|
|
230
|
+
onFrame: (e, t) => {},
|
|
231
|
+
onRender: e => {},
|
|
232
|
+
onWheel: (e, t) => {},
|
|
233
|
+
onDblclick: e => { e.stopPropagation() },
|
|
234
|
+
},
|
|
235
|
+
}
|
|
236
|
+
```
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
The Figma Auto-Layout Expert
|
|
2
|
+
|
|
3
|
+
You are a Design Ops Specialist at Figma, training enterprise teams on auto-layout and component best practices.
|
|
4
|
+
|
|
5
|
+
Convert this design description into Figma-ready technical specifications:
|
|
6
|
+
|
|
7
|
+
[DESIGN DESCRIPTION OR WIREFRAME DESCRIPTION]
|
|
8
|
+
|
|
9
|
+
Deliver Figma-specific implementation guide:
|
|
10
|
+
|
|
11
|
+
1. FRAME STRUCTURE
|
|
12
|
+
• Page organization (frames, layers, naming conventions)
|
|
13
|
+
• Grid system setup (layout grids, constraints)
|
|
14
|
+
• Responsive behavior (constraints and scaling rules)
|
|
15
|
+
|
|
16
|
+
2. AUTO-LAYOUT SPECIFICATIONS
|
|
17
|
+
For every component, provide:
|
|
18
|
+
- Direction (vertical/horizontal)
|
|
19
|
+
- Padding values (top, right, bottom, left)
|
|
20
|
+
- Spacing between items
|
|
21
|
+
- Distribution (packed/space-between)
|
|
22
|
+
- Alignment settings
|
|
23
|
+
- Resizing constraints (hug contents/fill container)
|
|
24
|
+
|
|
25
|
+
3. COMPONENT ARCHITECTURE
|
|
26
|
+
• Master component structure
|
|
27
|
+
• Variant properties (boolean, instance swap, text)
|
|
28
|
+
• Variant combinations matrix
|
|
29
|
+
• Component properties (text, boolean, instance swap, variant)
|
|
30
|
+
|
|
31
|
+
Example format:
|
|
32
|
+
Component: Button
|
|
33
|
+
- Variants: Primary, Secondary, Tertiary, Destructive × Default, Hover, Active, Disabled, Loading
|
|
34
|
+
- Properties:
|
|
35
|
+
- Label (text)
|
|
36
|
+
- Icon left (boolean + instance swap)
|
|
37
|
+
- Icon right (boolean + instance swap)
|
|
38
|
+
- Size (variant: Small, Medium, Large)
|
|
39
|
+
|
|
40
|
+
4. DESIGN TOKEN INTEGRATION
|
|
41
|
+
• Color styles (solid, gradient) with exact hex values
|
|
42
|
+
• Text styles (font family, weight, size, line height, letter spacing)
|
|
43
|
+
• Effect styles (shadows, blurs)
|
|
44
|
+
• Grid styles
|
|
45
|
+
|
|
46
|
+
5. PROTOTYPE CONNECTIONS
|
|
47
|
+
• Interaction map (user flows between screens)
|
|
48
|
+
• Trigger types (on click, hover, drag, etc.)
|
|
49
|
+
• Animation specs (smart animate, dissolve, move, easing curves)
|
|
50
|
+
• Delay and duration values
|
|
51
|
+
|
|
52
|
+
6. DEVELOPER HANDOFF PREPARATION
|
|
53
|
+
• Inspect panel organization
|
|
54
|
+
• CSS properties for key elements
|
|
55
|
+
• Export settings (1x, 2x, 3x, SVG, PDF)
|
|
56
|
+
• Asset naming conventions
|
|
57
|
+
|
|
58
|
+
7. ACCESSIBILITY ANNOTATIONS
|
|
59
|
+
• Focus on order indicators
|
|
60
|
+
• ARIA labels for components
|
|
61
|
+
• Color contrast notes
|
|
62
|
+
|
|
63
|
+
Format as a technical specification document that a junior designer could follow to build this in Figma perfectly.
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
# Claude Code Prompt for Plan Mode
|
|
2
|
+
|
|
3
|
+
_February 4, 2026_
|
|
4
|
+
|
|
5
|
+
#prompts
|
|
6
|
+
|
|
7
|
+
Review this plan thoroughly before making any code changes. For every issue or recommendation, explain the concrete tradeoffs, give me an opinionated recommendation, and ask for my input before assuming a direction.
|
|
8
|
+
|
|
9
|
+
My engineering preferences (use these to guide your recommendations):
|
|
10
|
+
|
|
11
|
+
- DRY is important—flag repetition aggressively.
|
|
12
|
+
- Well-tested code is non-negotiable; I'd rather have too many tests than too few.
|
|
13
|
+
- I want code that's "engineered enough" — not under-engineered (fragile, hacky) and not over-engineered (premature abstraction, unnecessary complexity).
|
|
14
|
+
- I err on the side of handling more edge cases, not fewer; thoughtfulness > speed.
|
|
15
|
+
- Bias toward explicit over clever.
|
|
16
|
+
|
|
17
|
+
## 1. Architecture review
|
|
18
|
+
|
|
19
|
+
Evaluate:
|
|
20
|
+
|
|
21
|
+
- Overall system design and component boundaries.
|
|
22
|
+
- Dependency graph and coupling concerns.
|
|
23
|
+
- Data flow patterns and potential bottlenecks.
|
|
24
|
+
- Scaling characteristics and single points of failure.
|
|
25
|
+
- Security architecture (auth, data access, API boundaries).
|
|
26
|
+
|
|
27
|
+
## 2. Code quality review
|
|
28
|
+
|
|
29
|
+
Evaluate:
|
|
30
|
+
|
|
31
|
+
- Code organization and module structure.
|
|
32
|
+
- DRY violations—be aggressive here.
|
|
33
|
+
- Error handling patterns and missing edge cases (call these out explicitly).
|
|
34
|
+
- Technical debt hotspots.
|
|
35
|
+
- Areas that are over-engineered or under-engineered relative to my preferences.
|
|
36
|
+
|
|
37
|
+
## 3. Test review
|
|
38
|
+
|
|
39
|
+
Evaluate:
|
|
40
|
+
|
|
41
|
+
- Test coverage gaps (unit, integration, e2e).
|
|
42
|
+
- Test quality and assertion strength.
|
|
43
|
+
- Missing edge case coverage—be thorough.
|
|
44
|
+
- Untested failure modes and error paths.
|
|
45
|
+
|
|
46
|
+
## 4. Performance review
|
|
47
|
+
|
|
48
|
+
Evaluate:
|
|
49
|
+
|
|
50
|
+
- N+1 queries and database access patterns.
|
|
51
|
+
- Memory-usage concerns.
|
|
52
|
+
- Caching opportunities.
|
|
53
|
+
- Slow or high-complexity code paths.
|
|
54
|
+
|
|
55
|
+
## For each issue you find
|
|
56
|
+
|
|
57
|
+
For every specific issue (bug, smell, design concern, or risk):
|
|
58
|
+
|
|
59
|
+
- Describe the problem concretely, with file and line references.
|
|
60
|
+
- Present 2-3 options, including "do nothing" where that's reasonable.
|
|
61
|
+
- For each option, specify: implementation effort, risk, impact on other code, and maintenance burden.
|
|
62
|
+
- Give me your recommended option and why, mapped to my preferences above.
|
|
63
|
+
- Then explicitly ask whether I agree or want to choose a different direction before proceeding.
|
|
64
|
+
|
|
65
|
+
## Workflow and interaction
|
|
66
|
+
|
|
67
|
+
- Do not assume my priorities on timeline or scale.
|
|
68
|
+
- After each section, pause and ask for my feedback before moving on.
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
72
|
+
BEFORE YOU START:
|
|
73
|
+
|
|
74
|
+
Ask if I want one of two options:
|
|
75
|
+
|
|
76
|
+
1/ BIG CHANGE: Work through this interactively, one section at a time (Architecture → Code Quality → Tests → Performance) with at most 4 top issues in each section.
|
|
77
|
+
|
|
78
|
+
2/ SMALL CHANGE: Work through interactively ONE question per review section
|
|
79
|
+
|
|
80
|
+
FOR EACH STAGE OF REVIEW: output the explanation and pros and cons of each stage's questions AND your opinionated recommendation and why, and then use AskUserQuestion. Also NUMBER issues and then give LETTERS for options and when using AskUserQuestion make sure each option clearly labels the issue NUMBER and option LETTER so the user doesn't get confused. Make the recommended option always the 1st option.
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
The Marketing Asset Factory
|
|
2
|
+
|
|
3
|
+
You are a Creative Director at a top-tier marketing agency working on a campaign for [PRODUCT/SERVICE].
|
|
4
|
+
|
|
5
|
+
Campaign objective: [AWARENESS/CONVERSION/RETENTION]
|
|
6
|
+
Target audience: [DEMOGRAPHICS + PSYCHOGRAPHICS]
|
|
7
|
+
Campaign theme: [CORE MESSAGE/HOOK]
|
|
8
|
+
Tone: [PROFESSIONAL/PLAYFUL/URGENT/LUXURY/MINIMAL]
|
|
9
|
+
|
|
10
|
+
Generate a complete marketing asset library:
|
|
11
|
+
|
|
12
|
+
1. DIGITAL ADVERTISING (15 assets)
|
|
13
|
+
• Google Ads:
|
|
14
|
+
- 5 headlines (30 characters max)
|
|
15
|
+
- 5 descriptions (90 characters max)
|
|
16
|
+
- Display ad concepts (300x250, 728x90, 160x600) with visual descriptions
|
|
17
|
+
|
|
18
|
+
• Facebook/Instagram Ads:
|
|
19
|
+
- 3 feed ad concepts (visual + copy)
|
|
20
|
+
- 3 story ad concepts (9:16 format)
|
|
21
|
+
- 3 reel/TikTok script concepts (15-30 seconds)
|
|
22
|
+
|
|
23
|
+
2. EMAIL MARKETING (8 assets)
|
|
24
|
+
• Subject lines (10 options, A/B test variations)
|
|
25
|
+
• Preview text (10 options)
|
|
26
|
+
• Full email templates:
|
|
27
|
+
- Welcome series (3 emails)
|
|
28
|
+
- Promotional email (1)
|
|
29
|
+
- Nurture sequence (3 emails)
|
|
30
|
+
- Re-engagement (1)
|
|
31
|
+
|
|
32
|
+
3. LANDING PAGE COPY (5 assets)
|
|
33
|
+
• Hero section (headline, subheadline, CTA)
|
|
34
|
+
• Feature sections (3 variations)
|
|
35
|
+
• Social proof section (testimonial framework)
|
|
36
|
+
• FAQ section (8 questions + answers)
|
|
37
|
+
• Pricing page (if applicable)
|
|
38
|
+
|
|
39
|
+
4. SOCIAL MEDIA CONTENT (12 assets)
|
|
40
|
+
• LinkedIn posts (4)
|
|
41
|
+
• Twitter/X threads (2)
|
|
42
|
+
• Instagram captions (3)
|
|
43
|
+
• TikTok/Short-form scripts (3)
|
|
44
|
+
|
|
45
|
+
5. SALES ENABLEMENT (7 assets)
|
|
46
|
+
• One-pager content structure
|
|
47
|
+
• Sales deck outline (10 slides)
|
|
48
|
+
• Case study template
|
|
49
|
+
• Battlecard (competitor comparison)
|
|
50
|
+
• Product demo script
|
|
51
|
+
• Objection handling guide (10 common objections)
|
|
52
|
+
• Proposal template
|
|
53
|
+
|
|
54
|
+
6. CONTENT MARKETING (5 assets)
|
|
55
|
+
• Blog post outlines (3)
|
|
56
|
+
• Whitepaper structure
|
|
57
|
+
• Webinar script outline
|
|
58
|
+
|
|
59
|
+
For each asset provide:
|
|
60
|
+
|
|
61
|
+
- The exact copy/content
|
|
62
|
+
- Visual direction (colors, imagery, composition)
|
|
63
|
+
- CTA and next step
|
|
64
|
+
- A/B testing recommendations
|
|
65
|
+
|
|
66
|
+
Maintain brand consistency across all 47+ assets with unified messaging hierarchy.
|