moicle 2.3.0 → 3.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/README.md +36 -47
- package/assets/commands/marketing.md +6 -6
- package/assets/skills/docs/sync/SKILL.md +195 -157
- package/assets/skills/feature/build/SKILL.md +891 -0
- package/assets/skills/feature/track/SKILL.md +157 -0
- package/assets/skills/fix/bug/SKILL.md +449 -0
- package/assets/skills/fix/incident/SKILL.md +6 -6
- package/assets/skills/marketing/brand/SKILL.md +304 -0
- package/assets/skills/marketing/content/SKILL.md +199 -141
- package/assets/skills/research/explore/SKILL.md +392 -0
- package/assets/skills/review/code/SKILL.md +622 -0
- package/dist/commands/install/usage.js +2 -2
- package/dist/commands/install/usage.js.map +1 -1
- package/package.json +1 -1
- package/assets/skills/docs/write/SKILL.md +0 -274
- package/assets/skills/feature/api/SKILL.md +0 -277
- package/assets/skills/feature/deprecate/SKILL.md +0 -276
- package/assets/skills/feature/new/SKILL.md +0 -273
- package/assets/skills/feature/refactor/SKILL.md +0 -269
- package/assets/skills/fix/hotfix/SKILL.md +0 -233
- package/assets/skills/fix/pr-comment/SKILL.md +0 -186
- package/assets/skills/fix/root-cause/SKILL.md +0 -276
- package/assets/skills/marketing/logo/SKILL.md +0 -252
- package/assets/skills/marketing/seo-blog/SKILL.md +0 -367
- package/assets/skills/marketing/video/SKILL.md +0 -258
- package/assets/skills/research/onboarding/SKILL.md +0 -225
- package/assets/skills/research/spike/SKILL.md +0 -228
- package/assets/skills/research/web/SKILL.md +0 -204
- package/assets/skills/review/architect/SKILL.md +0 -274
- package/assets/skills/review/branch/SKILL.md +0 -277
- package/assets/skills/review/pr/SKILL.md +0 -231
- package/assets/skills/review/tdd/SKILL.md +0 -245
|
@@ -1,276 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: fix-root-cause
|
|
3
|
-
description: Deep bug investigation workflow for hard-to-trace errors. Systematic root cause analysis — no guessing, no blind fixes. Use when user says "deep debug", "deep-debug", "trace bug", "find root cause", "hard bug", "investigate bug".
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Deep Bug Investigation
|
|
7
|
-
|
|
8
|
-
For bugs that have been "fixed" multiple times and keep coming back, intermittent bugs, or errors deep inside vendor code. **Do not guess** — trace step by step.
|
|
9
|
-
|
|
10
|
-
## When to use this skill
|
|
11
|
-
|
|
12
|
-
- ✅ Same bug returns after multiple "fixes"
|
|
13
|
-
- ✅ "Sometimes works, sometimes doesn't" — likely hidden state
|
|
14
|
-
- ✅ Error inside vendor / framework internals
|
|
15
|
-
- ✅ Local vs production behavior differs
|
|
16
|
-
- ✅ Race condition / concurrency suspected
|
|
17
|
-
- ❌ Bug is well understood, just needs a fix → `/fix-hotfix`
|
|
18
|
-
- ❌ Production is down with user impact → `/fix-incident` first, then this skill
|
|
19
|
-
|
|
20
|
-
---
|
|
21
|
-
|
|
22
|
-
## Workflow
|
|
23
|
-
|
|
24
|
-
```
|
|
25
|
-
COLLECT → VERIFY → TRACE → ROOT CAUSE → CHECK HIDDEN STATE → FIX → VERIFY
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
**Time budget:** if you've traced for >2 hours with no convergence → stop, write down what you know, ask a teammate. Rabbit holes are real.
|
|
29
|
-
|
|
30
|
-
---
|
|
31
|
-
|
|
32
|
-
## Step 1: COLLECT — capture evidence exactly
|
|
33
|
-
|
|
34
|
-
Record **verbatim**, do not interpret:
|
|
35
|
-
|
|
36
|
-
- Exact error message (copy-paste, don't paraphrase)
|
|
37
|
-
- Stack trace: file, line, full call chain
|
|
38
|
-
- Affected environment (prod / staging / local)
|
|
39
|
-
- Frequency: always / intermittent / specific input / specific user
|
|
40
|
-
- Timing: started exactly when? aligns with a deploy / cron / data change?
|
|
41
|
-
|
|
42
|
-
### Gate
|
|
43
|
-
- [ ] Error captured verbatim
|
|
44
|
-
- [ ] Stack trace captured (or noted absent)
|
|
45
|
-
- [ ] Frequency known
|
|
46
|
-
- [ ] Timing noted (helps narrow "what changed")
|
|
47
|
-
|
|
48
|
-
---
|
|
49
|
-
|
|
50
|
-
## Step 2: VERIFY — running code = local code?
|
|
51
|
-
|
|
52
|
-
Do NOT assume prod = local.
|
|
53
|
-
|
|
54
|
-
- Identify the deployed commit
|
|
55
|
-
- `git diff` deployed vs local
|
|
56
|
-
- If they differ → read the deployed version before reasoning further
|
|
57
|
-
- Container / image involved? Verify the image tag, not just the source
|
|
58
|
-
|
|
59
|
-
### Gate
|
|
60
|
-
- [ ] Deployed commit identified
|
|
61
|
-
- [ ] Local checkout matches OR differences understood
|
|
62
|
-
|
|
63
|
-
---
|
|
64
|
-
|
|
65
|
-
## Step 3: TRACE — entry to failure, every step
|
|
66
|
-
|
|
67
|
-
The single most important step. Skip nothing.
|
|
68
|
-
|
|
69
|
-
### 3a. Entry → error line
|
|
70
|
-
- Where does the request / event / job enter? (route, listener, cron, queue handler)
|
|
71
|
-
- Which function calls which? Follow stack trace exactly
|
|
72
|
-
- How does data flow between layers?
|
|
73
|
-
|
|
74
|
-
### 3b. Where does faulty data come from?
|
|
75
|
-
- Created locally or loaded from DB / API / cache / session?
|
|
76
|
-
- Goes through serialize / deserialize?
|
|
77
|
-
- Goes through any transform / map / cast?
|
|
78
|
-
|
|
79
|
-
### 3c. Type + state at the moment of failure
|
|
80
|
-
- Actual runtime type (use a debugger or log)
|
|
81
|
-
- Expected type
|
|
82
|
-
- Why do they differ?
|
|
83
|
-
|
|
84
|
-
### 3d. Vendor / framework internals
|
|
85
|
-
- Open the vendor source at the EXACT line from the stack trace
|
|
86
|
-
- Trace backwards: who calls this method, with what args?
|
|
87
|
-
- What condition routes execution into the failing branch?
|
|
88
|
-
|
|
89
|
-
### Debugging tools
|
|
90
|
-
|
|
91
|
-
Use the right tool, not just `console.log`:
|
|
92
|
-
|
|
93
|
-
| Tool | When |
|
|
94
|
-
|------|------|
|
|
95
|
-
| **Debugger breakpoint** | Step through suspect code, inspect locals |
|
|
96
|
-
| **Conditional breakpoint** | Stop only when `x == nil` / `id == 42` |
|
|
97
|
-
| **Logpoint** (debugger) | Inject log without modifying source — useful in prod-like envs |
|
|
98
|
-
| **Memory / heap profiler** | Suspected memory leak or unbounded growth |
|
|
99
|
-
| **CPU profiler** | Slow path / hot loop |
|
|
100
|
-
| **Network trace** (Wireshark, browser devtools) | Wire-level issue with external API |
|
|
101
|
-
| **strace / dtruss** | Syscall-level (file, network) on Unix |
|
|
102
|
-
| **Time-travel debugger** (rr, Replay) | Hard non-determinism, race conditions |
|
|
103
|
-
| **Distributed tracing** (OpenTelemetry, Jaeger) | Cross-service latency or error origin |
|
|
104
|
-
|
|
105
|
-
### Gate
|
|
106
|
-
- [ ] Full call chain documented
|
|
107
|
-
- [ ] Source of faulty data identified
|
|
108
|
-
- [ ] Actual vs expected type / state recorded
|
|
109
|
-
|
|
110
|
-
---
|
|
111
|
-
|
|
112
|
-
## Step 4: ROOT CAUSE — answer 3 questions
|
|
113
|
-
|
|
114
|
-
1. **Why does it fail?** — the specific technical cause
|
|
115
|
-
2. **Why didn't it fail before?** — what changed (deploy, dep, data shape, config, traffic)
|
|
116
|
-
3. **Reproduction conditions?** — exact inputs / state that trigger it
|
|
117
|
-
|
|
118
|
-
If you cannot answer all 3 → return to Step 3.
|
|
119
|
-
|
|
120
|
-
### Gate
|
|
121
|
-
- [ ] All 3 questions answered with **evidence**, not speculation
|
|
122
|
-
|
|
123
|
-
---
|
|
124
|
-
|
|
125
|
-
## Step 5: HIDDEN STATE — check 6 sources
|
|
126
|
-
|
|
127
|
-
"Sometimes works, sometimes doesn't" bugs live here.
|
|
128
|
-
|
|
129
|
-
### 5a. Cache / serialization
|
|
130
|
-
- Cached object lost transient fields / lazy-loaded properties?
|
|
131
|
-
- Stale cache has OLD shape; new code expects NEW shape?
|
|
132
|
-
- Serialize / deserialize changes types? (int↔float, null handling, enum↔string, date timezone)
|
|
133
|
-
|
|
134
|
-
### 5b. Database / storage
|
|
135
|
-
- Collation / encoding affecting comparisons (e.g., case-insensitive collation hiding duplicates)?
|
|
136
|
-
- DB default values mismatch with code expectations (null vs empty string)?
|
|
137
|
-
- Schema on prod vs schema in code (migration not applied)?
|
|
138
|
-
- **Read replica lag** — write to primary, read from replica returns stale data?
|
|
139
|
-
|
|
140
|
-
### 5c. Concurrency / async
|
|
141
|
-
- **Race condition** — two requests modifying shared state simultaneously
|
|
142
|
-
- **Deadlock / livelock** — lock acquired but never released
|
|
143
|
-
- **Goroutine / async leak** — handler returned but background work continues
|
|
144
|
-
- **Request context cancelled** while async work depended on it
|
|
145
|
-
- **Channel / queue overflow** — messages dropped silently
|
|
146
|
-
- Use logs with nanosecond timestamps + request IDs to reconstruct the timeline
|
|
147
|
-
|
|
148
|
-
### 5d. Runtime / compiled cache
|
|
149
|
-
- OPcache / bytecode cache serving old file
|
|
150
|
-
- Compiled config / routes / views not cleared after deploy
|
|
151
|
-
- CDN / proxy cache serving stale asset
|
|
152
|
-
- Browser cache / service worker
|
|
153
|
-
|
|
154
|
-
### 5e. Environment
|
|
155
|
-
- Env vars on prod correct + complete?
|
|
156
|
-
- Runtime version (Node 20 vs 18, Go 1.22 vs 1.21) differs from local?
|
|
157
|
-
- Dependency versions differ (lockfile drift, transitive update)?
|
|
158
|
-
|
|
159
|
-
### 5f. Multi-tenancy (SaaS-specific)
|
|
160
|
-
- **Tenant ID leak** — query missing `WHERE tenant_id = ?`
|
|
161
|
-
- Cache key missing tenant prefix → tenant A sees tenant B's data
|
|
162
|
-
- Background job inherits wrong tenant context
|
|
163
|
-
- Connection pool reused across tenants without reset
|
|
164
|
-
|
|
165
|
-
### Gate
|
|
166
|
-
- [ ] All 6 categories considered (write N/A if not applicable)
|
|
167
|
-
- [ ] At least one category identified as the hidden state source (or explicitly ruled out)
|
|
168
|
-
|
|
169
|
-
---
|
|
170
|
-
|
|
171
|
-
## Step 6: FIX
|
|
172
|
-
|
|
173
|
-
Only after Step 4 is answered. The fix MUST:
|
|
174
|
-
|
|
175
|
-
- Address **root cause**, not symptom
|
|
176
|
-
- Be defensive at **trust boundaries** (cache, DB, external API, user input) — NOT in internal logic
|
|
177
|
-
- Handle the specific edge case found, without breaking the normal path
|
|
178
|
-
- Be small + reviewable
|
|
179
|
-
- Land in the correct layer (per `~/.claude/architecture/ddd-architecture.md`)
|
|
180
|
-
|
|
181
|
-
### Boundary defense pattern
|
|
182
|
-
For data-shape bugs from external sources: validate / coerce at the adapter, not inside business logic.
|
|
183
|
-
|
|
184
|
-
### Gate
|
|
185
|
-
- [ ] Fix targets root cause
|
|
186
|
-
- [ ] Defended at the boundary
|
|
187
|
-
- [ ] Normal code path not regressed
|
|
188
|
-
|
|
189
|
-
---
|
|
190
|
-
|
|
191
|
-
## Step 7: VERIFY
|
|
192
|
-
|
|
193
|
-
- Reproduce the Step 4 conditions → confirm fix works
|
|
194
|
-
- Normal code path still works
|
|
195
|
-
- Cache-related → test fresh load AND cached load
|
|
196
|
-
- Concurrency-related → reproduce under **load test** (10-100x normal concurrency)
|
|
197
|
-
- Verify against the deployed version (repeat Step 2)
|
|
198
|
-
- Add a **regression test** in the appropriate layer
|
|
199
|
-
|
|
200
|
-
### Gate
|
|
201
|
-
- [ ] Original failure no longer reproducible
|
|
202
|
-
- [ ] Normal flow works
|
|
203
|
-
- [ ] Cached / serialized paths both work (if applicable)
|
|
204
|
-
- [ ] Load-tested if concurrency-related
|
|
205
|
-
- [ ] Regression test added
|
|
206
|
-
|
|
207
|
-
---
|
|
208
|
-
|
|
209
|
-
## Final Report
|
|
210
|
-
|
|
211
|
-
```markdown
|
|
212
|
-
## Bug: {short description}
|
|
213
|
-
|
|
214
|
-
### Root Cause
|
|
215
|
-
{Specific technical cause from Step 4 Q1}
|
|
216
|
-
|
|
217
|
-
### Why it didn't fail before
|
|
218
|
-
{What changed: deploy / dependency / data shape / config / traffic / runtime}
|
|
219
|
-
|
|
220
|
-
### Reproduction
|
|
221
|
-
{Exact steps + data + environment}
|
|
222
|
-
|
|
223
|
-
### Hidden state source
|
|
224
|
-
{Cache / DB / Concurrency / Runtime / Env / Multi-tenant — or "none"}
|
|
225
|
-
|
|
226
|
-
### Fix
|
|
227
|
-
- File: `path/to/file:line`
|
|
228
|
-
- Layer: {handler / usecase / infra adapter}
|
|
229
|
-
- Approach: {boundary defense / type coercion / locking / cache invalidation / etc.}
|
|
230
|
-
- Why this is root-cause, not symptom: {explanation}
|
|
231
|
-
|
|
232
|
-
### Regression test
|
|
233
|
-
- File: `path/to/test:line`
|
|
234
|
-
- Reproduces the original failure when fix removed
|
|
235
|
-
|
|
236
|
-
### Verification
|
|
237
|
-
- [x] Original failure no longer reproducible
|
|
238
|
-
- [x] Normal path works
|
|
239
|
-
- [x] Cached path works (if applicable)
|
|
240
|
-
- [x] Load tested (if concurrency-related)
|
|
241
|
-
```
|
|
242
|
-
|
|
243
|
-
---
|
|
244
|
-
|
|
245
|
-
## Hard Rules
|
|
246
|
-
|
|
247
|
-
- **DO NOT GUESS** — trace evidence, never infer from variable names
|
|
248
|
-
- **DO NOT FIX BEFORE UNDERSTANDING** — premature fix = new bug
|
|
249
|
-
- **VERIFY DEPLOYED CODE** — never assume prod = local
|
|
250
|
-
- **CHECK CACHE FIRST** for intermittent bugs
|
|
251
|
-
- **CHECK MULTI-TENANCY** if SaaS-style
|
|
252
|
-
- **ONE ROOT CAUSE per bug** — if multiple possibilities remain, trace further
|
|
253
|
-
- **TIME-BOX investigation** — if >2 h without convergence, ask for help
|
|
254
|
-
- **REGRESSION TEST required** — fix without test = bug returns
|
|
255
|
-
|
|
256
|
-
---
|
|
257
|
-
|
|
258
|
-
## Related Skills
|
|
259
|
-
|
|
260
|
-
| When | Use |
|
|
261
|
-
|------|-----|
|
|
262
|
-
| Bug is understood, just needs a fix | `/fix-hotfix` |
|
|
263
|
-
| Production is down | `/fix-incident` (then this skill after mitigation) |
|
|
264
|
-
| Write regression test after fix | `/review-tdd` |
|
|
265
|
-
| Research how others solved similar bugs | `/research-web` |
|
|
266
|
-
|
|
267
|
-
## Recommended Agents
|
|
268
|
-
|
|
269
|
-
| Phase | Agent | Purpose |
|
|
270
|
-
|-------|-------|---------|
|
|
271
|
-
| Trace | `@code-reviewer` | Independent reading of call chain |
|
|
272
|
-
| Hidden state — DB | `@db-designer` | Schema, indexes, collation, replication |
|
|
273
|
-
| Hidden state — concurrency | `@perf-optimizer` | Race, deadlock, async leak |
|
|
274
|
-
| Hidden state — security/tenancy | `@security-audit` | Tenant isolation, auth context |
|
|
275
|
-
| Fix | Stack-specific dev agent | Boundary-defensive fix |
|
|
276
|
-
| Verify | `@test-writer` | Regression test |
|
|
@@ -1,252 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: marketing-logo
|
|
3
|
-
description: Generate comprehensive logo design specifications, brand identity guidelines, and visual concepts. Use when user says "design logo", "create logo", "brand identity", "logo concept", "visual identity".
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Logo Design Skill
|
|
7
|
-
|
|
8
|
-
Produce a logo + brand identity **specification** that a designer can execute (or you can use as a direct prompt to a generative tool). Output is a brand guidelines doc, not finished art.
|
|
9
|
-
|
|
10
|
-
## When to use this skill
|
|
11
|
-
|
|
12
|
-
- ✅ Brand new identity (no existing logo)
|
|
13
|
-
- ✅ Rebrand / refresh of an existing logo + guidelines
|
|
14
|
-
- ✅ Need a deliverable spec for a designer to execute
|
|
15
|
-
- ❌ Just need a quick icon variation → use a design tool directly
|
|
16
|
-
- ❌ Full marketing plan (logo + content + video) → use `/marketing`
|
|
17
|
-
- ❌ Video-specific visuals → use `/marketing-video`
|
|
18
|
-
|
|
19
|
-
---
|
|
20
|
-
|
|
21
|
-
## Workflow
|
|
22
|
-
|
|
23
|
-
```
|
|
24
|
-
DISCOVER → CONCEPT → DESIGN → REFINE → DELIVER
|
|
25
|
-
```
|
|
26
|
-
|
|
27
|
-
---
|
|
28
|
-
|
|
29
|
-
## Phase 1: DISCOVER (30 min)
|
|
30
|
-
|
|
31
|
-
**Goal:** capture brand intent before sketching.
|
|
32
|
-
|
|
33
|
-
### Discovery brief
|
|
34
|
-
|
|
35
|
-
Ask the user (skip what's known):
|
|
36
|
-
|
|
37
|
-
| Field | Example |
|
|
38
|
-
|-------|---------|
|
|
39
|
-
| Name + tagline | "Acme — DevOps for indie teams" |
|
|
40
|
-
| 3-5 personality adjectives | "modern, technical, irreverent, sharp, friendly" |
|
|
41
|
-
| Primary audience | "Solo / small-team backend engineers" |
|
|
42
|
-
| Industry | "Developer tools / SaaS" |
|
|
43
|
-
| Competitors (3-5) | + 1 line each on what their logo says about them |
|
|
44
|
-
| Style direction (pick 1-2) | minimal / wordmark / monogram / abstract mark / illustrative / mascot |
|
|
45
|
-
| What to AVOID | "no cliché cloud icons, no gradients on the mark" |
|
|
46
|
-
| Where it lives | favicon + GitHub avatar + landing hero + dark / light themes + print |
|
|
47
|
-
| Color hints | "must work in single-color print + on dark UI" |
|
|
48
|
-
| Budget for the brand | "MVP — logo + 1 palette + 2 fonts" vs "full system" |
|
|
49
|
-
|
|
50
|
-
### Gate
|
|
51
|
-
- [ ] Personality adjectives captured (forces concept differentiation)
|
|
52
|
-
- [ ] Competitor scan done (don't accidentally copy)
|
|
53
|
-
- [ ] Style direction narrowed to 1-2
|
|
54
|
-
- [ ] Avoid-list captured
|
|
55
|
-
|
|
56
|
-
---
|
|
57
|
-
|
|
58
|
-
## Phase 2: CONCEPT — propose 3 directions
|
|
59
|
-
|
|
60
|
-
**Goal:** present 3 *distinct* concepts. Same concept in 3 colors ≠ 3 concepts.
|
|
61
|
-
|
|
62
|
-
Each concept must have:
|
|
63
|
-
|
|
64
|
-
```markdown
|
|
65
|
-
## Concept {N}: {short name}
|
|
66
|
-
|
|
67
|
-
**Direction:** {wordmark / monogram / abstract mark / etc.}
|
|
68
|
-
**Rationale:** Why this matches the brand personality + audience. Cite 2-3 adjectives.
|
|
69
|
-
**Differentiation:** What competitor it does NOT look like, and why that matters.
|
|
70
|
-
**ASCII sketch** (rough — describes shape, not pixel-perfect):
|
|
71
|
-
```
|
|
72
|
-
___________
|
|
73
|
-
| A C M E |
|
|
74
|
-
|___________|
|
|
75
|
-
```
|
|
76
|
-
**Inspiration:** 2-3 reference links (existing logos, styles)
|
|
77
|
-
**Risks:** What could go wrong (e.g., "monogram unreadable below 24px")
|
|
78
|
-
```
|
|
79
|
-
|
|
80
|
-
### Concept variety rules
|
|
81
|
-
- Different *form* (wordmark vs mark vs combination)
|
|
82
|
-
- Different *feel* (geometric vs hand-drawn vs typographic)
|
|
83
|
-
- Different *complexity* (minimal vs detailed)
|
|
84
|
-
|
|
85
|
-
### Gate
|
|
86
|
-
- [ ] 3 concepts presented
|
|
87
|
-
- [ ] Each has rationale + differentiation + risk
|
|
88
|
-
- [ ] **User selected ONE** (or asked for hybrid — repeat phase)
|
|
89
|
-
|
|
90
|
-
---
|
|
91
|
-
|
|
92
|
-
## Phase 3: DESIGN — flesh out the chosen concept
|
|
93
|
-
|
|
94
|
-
**Goal:** produce specifications a designer can build.
|
|
95
|
-
|
|
96
|
-
### 3.1 Logo construction
|
|
97
|
-
|
|
98
|
-
```markdown
|
|
99
|
-
### Logo: {name}
|
|
100
|
-
|
|
101
|
-
**Lockup**
|
|
102
|
-
- Primary: {wordmark / mark / mark + wordmark side-by-side / stacked}
|
|
103
|
-
- Secondary (when primary doesn't fit): {variant}
|
|
104
|
-
- Icon-only (favicon, avatar): {variant}
|
|
105
|
-
|
|
106
|
-
**Geometry**
|
|
107
|
-
- Grid: {e.g., "8-unit grid, mark fits in 8x8 square"}
|
|
108
|
-
- Proportions: {e.g., "wordmark cap-height = 5 units; mark = 8 units; gap = 2 units"}
|
|
109
|
-
|
|
110
|
-
**Clear space**
|
|
111
|
-
- Minimum: {e.g., "1 cap-height on all sides"}
|
|
112
|
-
|
|
113
|
-
**Minimum size**
|
|
114
|
-
- Digital: {e.g., "24px height"}
|
|
115
|
-
- Print: {e.g., "8mm height"}
|
|
116
|
-
```
|
|
117
|
-
|
|
118
|
-
### 3.2 Color palette
|
|
119
|
-
|
|
120
|
-
Pick a primary + secondary + neutrals. Provide every color in:
|
|
121
|
-
- HEX, RGB, HSL
|
|
122
|
-
- CMYK (for print)
|
|
123
|
-
- WCAG AA contrast against white and against black (note pass / fail)
|
|
124
|
-
- Tailwind variable name (if relevant)
|
|
125
|
-
|
|
126
|
-
```markdown
|
|
127
|
-
| Token | HEX | RGB | HSL | Use |
|
|
128
|
-
|-------|-----|-----|-----|-----|
|
|
129
|
-
| `--brand-primary` | #0F172A | 15,23,42 | 222 47% 11% | logo, headlines |
|
|
130
|
-
| `--brand-accent` | #14B8A6 | 20,184,166 | 173 80% 40% | CTA, links |
|
|
131
|
-
| `--neutral-fg` | #1F2937 | 31,41,55 | 220 26% 14% | body text |
|
|
132
|
-
| `--neutral-bg` | #F8FAFC | 248,250,252 | 210 40% 98% | page bg |
|
|
133
|
-
```
|
|
134
|
-
|
|
135
|
-
### 3.3 Typography
|
|
136
|
-
|
|
137
|
-
Pick 1 display + 1 body font (or 1 font in 2 weights). Note:
|
|
138
|
-
- Family + fallback stack
|
|
139
|
-
- Weights used (display, body, light)
|
|
140
|
-
- Pairing rationale (1 line)
|
|
141
|
-
- License (open / Google Fonts / commercial)
|
|
142
|
-
|
|
143
|
-
### 3.4 Voice
|
|
144
|
-
- 3 voice attributes (e.g., "direct, witty, never corporate-speak")
|
|
145
|
-
- 3 do / 3 don't examples (1 line each)
|
|
146
|
-
|
|
147
|
-
### Gate
|
|
148
|
-
- [ ] All lockup variants specified
|
|
149
|
-
- [ ] Palette has WCAG contrast notes
|
|
150
|
-
- [ ] Typography choice has rationale + license
|
|
151
|
-
- [ ] Voice has do/don't examples
|
|
152
|
-
|
|
153
|
-
---
|
|
154
|
-
|
|
155
|
-
## Phase 4: REFINE
|
|
156
|
-
|
|
157
|
-
**Goal:** test the design against real use, iterate.
|
|
158
|
-
|
|
159
|
-
### Test scenarios (write down result for each)
|
|
160
|
-
- [ ] Favicon at 16×16 — still recognizable?
|
|
161
|
-
- [ ] On dark background — does it still work?
|
|
162
|
-
- [ ] Single-color print (black-only fax test) — still readable?
|
|
163
|
-
- [ ] Next to 2-3 competitor logos — does it stand out?
|
|
164
|
-
- [ ] At 100% scale on hero — does it carry the page?
|
|
165
|
-
|
|
166
|
-
### Feedback loop
|
|
167
|
-
- Present to user with each scenario
|
|
168
|
-
- Capture changes requested
|
|
169
|
-
- If >2 rounds of changes → consider re-concepting (Phase 2)
|
|
170
|
-
|
|
171
|
-
### Gate
|
|
172
|
-
- [ ] All 5 scenarios tested
|
|
173
|
-
- [ ] User approved final version
|
|
174
|
-
|
|
175
|
-
---
|
|
176
|
-
|
|
177
|
-
## Phase 5: DELIVER — brand guidelines doc
|
|
178
|
-
|
|
179
|
-
**Goal:** ship a single doc + asset list a designer / dev can use.
|
|
180
|
-
|
|
181
|
-
### `brand-guidelines.md` skeleton
|
|
182
|
-
|
|
183
|
-
```markdown
|
|
184
|
-
# {Brand} Brand Guidelines
|
|
185
|
-
|
|
186
|
-
## Logo
|
|
187
|
-
- {Primary, secondary, icon lockups as files: SVG + PNG}
|
|
188
|
-
- Clear space + min size rules
|
|
189
|
-
- Wrong uses (with examples: don't recolor, don't squish, don't add effects)
|
|
190
|
-
|
|
191
|
-
## Color
|
|
192
|
-
- Token table from Phase 3.2
|
|
193
|
-
- Usage rules (when primary vs accent)
|
|
194
|
-
- Accessibility (contrast notes)
|
|
195
|
-
|
|
196
|
-
## Typography
|
|
197
|
-
- Stack from Phase 3.3
|
|
198
|
-
- Hierarchy: H1/H2/H3/body sizes
|
|
199
|
-
- Web vs print
|
|
200
|
-
|
|
201
|
-
## Voice
|
|
202
|
-
- From Phase 3.4
|
|
203
|
-
- Sample headline + body + CTA copy
|
|
204
|
-
|
|
205
|
-
## Examples
|
|
206
|
-
- 1 hero, 1 card, 1 button shown with the brand applied
|
|
207
|
-
```
|
|
208
|
-
|
|
209
|
-
### Asset checklist (what to hand to designer / dev)
|
|
210
|
-
|
|
211
|
-
- [ ] `logo-primary.svg` + `logo-primary.png` (1x, 2x, 4x)
|
|
212
|
-
- [ ] `logo-secondary.svg` + `.png`
|
|
213
|
-
- [ ] `logo-mark.svg` + `.png`
|
|
214
|
-
- [ ] `favicon.ico` (16, 32, 48), `apple-touch-icon.png` (180×180), `og-image.png` (1200×630)
|
|
215
|
-
- [ ] Social avatars: square 400×400 + cover per platform (Twitter 1500×500, LinkedIn 1128×191, etc.)
|
|
216
|
-
- [ ] Color tokens: `colors.css` (CSS variables) + `tailwind.config.js` snippet (if Tailwind)
|
|
217
|
-
- [ ] Brand guidelines PDF or `.md`
|
|
218
|
-
|
|
219
|
-
### Gate
|
|
220
|
-
- [ ] Guidelines doc written
|
|
221
|
-
- [ ] Asset checklist exists (even if generation is by a designer)
|
|
222
|
-
- [ ] Developer-ready tokens included (CSS / Tailwind)
|
|
223
|
-
|
|
224
|
-
---
|
|
225
|
-
|
|
226
|
-
## Hard Rules
|
|
227
|
-
|
|
228
|
-
- **3 *distinct* concepts in Phase 2** — same concept in 3 colors = lazy
|
|
229
|
-
- **WCAG AA contrast minimum** on text colors
|
|
230
|
-
- **Mark must read at 16px** — if it doesn't, redesign, don't compromise
|
|
231
|
-
- **No gradient on the primary mark** — gradients don't print, don't fax, don't embroider well
|
|
232
|
-
- **License-clean fonts only** — no "found on the internet" type
|
|
233
|
-
|
|
234
|
-
---
|
|
235
|
-
|
|
236
|
-
## Related Skills
|
|
237
|
-
|
|
238
|
-
| When | Use |
|
|
239
|
-
|------|-----|
|
|
240
|
-
| Full marketing plan (logo + content + video) | `/marketing` |
|
|
241
|
-
| Write content with the brand | `/marketing-content` |
|
|
242
|
-
| Create video with the brand | `/marketing-video` |
|
|
243
|
-
| Document brand guidelines as a doc | `/docs-write` |
|
|
244
|
-
|
|
245
|
-
## Recommended Agents
|
|
246
|
-
|
|
247
|
-
| Phase | Agent | Purpose |
|
|
248
|
-
|-------|-------|---------|
|
|
249
|
-
| DISCOVER | `@docs-writer` | Capture brand brief |
|
|
250
|
-
| CONCEPT | `@clean-architect` | Structure the system |
|
|
251
|
-
| DESIGN | `@docs-writer` | Spec documents |
|
|
252
|
-
| DELIVER | `@docs-writer` | Brand guidelines doc |
|