You can copy any of these directly into ChatGPT, Claude, Gemini, or whatever model you're using. You can stack multiple ones together - try combining Color, Layout, and Typography when you're building something visual. And if you're using Claude, you can save these as Skills by simply asking Claude. These aren't meant to be perfect for your specific use case - they're meant to show you the pattern so you can build your own.
<use_distinctive_color>
Color palettes instantly communicate design intent. Avoid safe, middle-ground choices.
Never use: Tailwind's purple/blue defaults (#6366f1, #3b82f6), pastel-everything palettes, equal-weight rainbow schemes, generic purple-to-blue gradients
Here are some examples of distinctive, purposeful palettes:
- Bold/energetic: Deep red dominant + electric yellow accent, or saturated orange + cyan
- Professional/trust: Navy + gold, or forest green + cream
- Creative/modern: Ochre + slate, or burgundy + sage
- Technical/precise: Charcoal + neon green, or deep blue + orange
Dominance principle: 70% one color, 20% supporting, 10% accent. One color should clearly own the palette.
Use saturation extremes: Fully saturated primaries OR deeply muted tones, not safety middle-ground. Context drives choice: financial/serious = muted, creative/energetic = bold.
Pick one dominant color, commit to it throughout. Use accent color sparingly for emphasis only.
</use_distinctive_color>
<use_purposeful_layout>
Layout creates visual hierarchy and guides attention. Avoid symmetric, centered-everything defaults.
Never use: every element centered, equal-sized sections, 50/50 splits, uniform card grids, no white space strategy, elements touching edges
Here are examples of purposeful layout approaches:
- Dominant hero: One large element (60-70% viewport) + smaller supporting elements asymmetrically placed
- Editorial: Wide margins (15-20% each side), generous line height, intentional paragraph breaks
- Magazine: Multi-column with varying widths (2:1 ratio, not 1:1), content breaking across columns
- Dashboard: Information density zones - critical data large/sparse, secondary data compact/grouped
Asymmetry principle: 60/40 splits are more interesting than 50/50. Left-heavy or right-heavy, not balanced.
Use white space decisively: Dense clusters separated by generous gaps (3x+ spacing between sections vs within). White space = emphasis.
Create clear visual hierarchy through size dominance: Primary content 3x+ larger than secondary, not 1.5x larger.
</use_purposeful_layout>
<write_direct_prose>
Clear writing comes from confident, direct language. Avoid hedging and corporate filler.
Never use: "It's worth noting that", "However" or "Additionally" starting sentences, "leverage" as a verb, "robust", "seamless", "cutting-edge", passive voice defaults, "one might consider"
Here are examples of direct alternatives:
- Hedged: "It's worth noting that this approach may improve performance" → Direct: "This approach improves performance"
- Formal connectors: "However, this presents challenges. Additionally, we must consider..." → Natural: "But this creates problems. We also need..."
- Corporate jargon: "leverage our robust platform to seamlessly integrate" → Plain: "use our platform to integrate"
- Passive: "The decision was made to..." → Active: "We decided to..."
Clarity principle: One idea per sentence. Subject-verb-object. If you can delete a word without changing meaning, delete it.
Front-load the point: Lead with your claim, then support it. Not "Given A, B, and C, we can conclude X" but "X is true because of A, B, and C."
Write like you're explaining to a smart colleague at lunch, not drafting a memo for legal review.
</write_direct_prose>
<write_clear_documentation>
Good documentation helps users accomplish tasks, not catalog every feature. Avoid exhaustive reference manual defaults.
Never use: features-first organization, walls of text without examples, burying examples at the end, exhaustive parameter lists before showing usage, "documentation should be comprehensive" thinking, linear narratives that assume users read everything
Here are examples of task-oriented structures:
- Quick start: Working example in first 30 seconds, explanation after success
- How-to guides: "To achieve X, do Y" with code snippet, then why it works
- API reference: Example call first, then parameters table, then edge cases
- Troubleshooting: Symptom → diagnosis → solution, not alphabetical error codes
Progressive disclosure principle: Simple case first, then variations, then edge cases. Not "here are all possibilities" upfront.
Show, then explain: Code example or screenshot, then prose about what it does. Not explanation followed by example as proof.
Use scannable structure: Short paragraphs (2-3 sentences), code snippets every 100-150 words, headers that complete the sentence "How do I..."
Write the minimum viable explanation: What does the user need to accomplish their task right now? Advanced details belong in separate sections they can skip.
</write_clear_documentation>
<design_clear_visualizations>
Data visualization should guide insight, not just display numbers. Avoid generic chart types and decoration.
Never use: pie charts (except 2-3 segments), 3D effects, dual Y-axes without clear justification, legends when direct labels work, rainbow categorical colors, chart titles that just label ("Sales Over Time"), unlabeled axes
Here are examples of purposeful chart choices:
- Comparison (few items): Dot plot or bar chart with direct labels, sorted by value
- Comparison (many items): Small multiples showing same metric across categories
- Change over time (2 points): Slope chart connecting before/after
- Change over time (trend): Line chart with annotated inflection points
- Part-to-whole: Stacked bar (if categories matter) or text callout (if one part matters most)
Chart selection principle: Choose the simplest chart that answers the specific question. Bar chart → dot plot for <20 items. Stacked area → small multiples when comparing categories.
Annotation over decoration: Label the insight directly on the chart ("Revenue dropped here due to X"). Remove gridlines, reduce colors, emphasize the finding. Color = emphasis (1-2 colors max).
Direct labels beat legends: Put category names next to bars/lines, not in a box to the side. Let users read naturally left-to-right, not decode a legend.
</design_clear_visualizations>
<analyze_strategically>
Strategic analysis identifies constraints and blockers, not lists of factors. Avoid generic frameworks applied without depth.
Never use: SWOT with vague entries ("competition is a threat"), lists without prioritization, "opportunities" that aren't actionable, analysis that treats all factors equally, strengths/weaknesses without evidence, surface observations without asking "why" twice
Here are examples of insight-driven analysis:
- Constraint identification: "Revenue is capped by sales capacity (4 reps), not demand. Hiring blocks on training time (3 months to productivity)."
- Second-order effects: "Lowering price increases volume but overwhelms support (2-week response times), triggering churn that offsets gains."
- Competitive dynamics: "Competitor X wins on brand, but their 18-month sales cycle creates opening for land-and-expand at SMB."
- Market positioning: "We're positioned as premium but priced as mid-market. This confuses buyers and undermines margin."
Prioritization principle: Identify the one constraint that, if removed, unlocks the most value. Secondary factors matter only after the primary constraint is addressed.
Ask "what blocks progress" not "what are the factors": Constraints beat observations. "Why can't we 10x this?" reveals more than "What are our strengths?"
Synthesize, don't list: "Three blockers, ranked by impact" beats "twelve factors to consider." Make a claim about what matters most.
</analyze_strategically>
<design_task_oriented_flows>
UX patterns should align with user tasks, not generic component libraries. Avoid predictable modal and settings sprawl.
Never use: modal dialogs as default for every action, settings pages with 30+ toggles, forced onboarding tours, tooltip spam, forms as vertical lists of every field, confirmation dialogs for reversible actions, requiring clicks for predictable defaults
Here are examples of task-focused patterns:
- Quick actions: Inline editing (click to edit, auto-save) instead of "Edit" button → modal → "Save" button
- Configuration: Smart defaults with "Change this?" links near where it matters, not settings page with alphabetical list
- Onboarding: Progressive disclosure (show feature when relevant to task) instead of upfront tour of everything
- Data entry: Multi-column forms grouped by logic, conditional fields appearing only when needed, not single column of all possible fields
Task completion principle: Minimize steps between intent and outcome. "Create invoice" should start with the invoice form, not selection screen → configuration → template choice → form.
Use context over configuration: Put controls where users need them (bulk actions above table, filters in sidebar) rather than settings page. If 90% of users want the same thing, make it the default and hide the toggle.
Make actions reversible, not confirmed: Undo beats "Are you sure?" for non-destructive changes. Save confirmation dialogs for actual risk (delete account), not routine actions (save draft).
</design_task_oriented_flows>
<design_pragmatic_systems>
System design should solve actual problems, not showcase patterns. Avoid premature abstraction and architectural complexity.
Never use: microservices as default, "repository pattern" before you have multiple data sources, interface/abstraction before you have second implementation, generic CRUD endpoints without thinking through actual operations, elaborate event-driven architecture for simple workflows, "we might need to scale" as justification
Here are examples of pragmatic architectural choices:
- Monolith first: Single deployable with clear module boundaries. Split to services only when team scaling or deployment independence required.
- Direct database access: Query the database directly in handlers. Add abstraction layer when you actually need to swap data sources or test isolation, not speculatively.
- REST based on operations: "POST /orders/123/cancel" (what users do) not "PATCH /orders/123" (generic update). Name endpoints after business operations.
- Synchronous first: Direct function calls and HTTP requests. Add queues/events only when you need decoupling, retry logic, or load smoothing.
Start simple principle: Build the straightforward solution. Add patterns only when you feel pain from not having them. Premature abstraction is harder to remove than missing abstraction is to add.
Optimize for change velocity: Three files that are easy to understand beats ten files with perfect separation of concerns. Duplication is cheaper than wrong abstraction.
Scale when it hurts: Performance optimization and horizontal scaling only matter when current system is measurably inadequate. "Might need to scale" is not a reason to complicate today.
</design_pragmatic_systems>
Notice this offers no help with plot. I’d use this as a seed to help work through editing a piece of text you wrote. I still don’t trust models worth a darn on actual fiction.
<write_compelling_stories>
Strong stories create tension through specific details and build to earned resolution. Avoid generic descriptions and explaining emotions.
Never use: telling emotions directly ("she was nervous"), generic descriptions ("nice day", "beautiful sunset"), flat dialogue where everyone sounds the same, linear "and then" narratives, rushing to resolution, explaining the theme explicitly, conflict that resolves too easily
Here are examples of specific, immersive techniques:
- Show don't tell: Not "He was angry" but "He slammed the folder on the desk, papers scattering"
- Sensory details: Not "beautiful garden" but "roses the color of dried blood, thorns catching afternoon light"
- Distinct voices: Teenager: "Whatever, I'm fine." vs Corporate exec: "Let's circle back on that." vs Professor: "Well, actually, the research suggests..."
- Story structure: Status quo → inciting incident → escalating complications → crisis → resolution (not just sequence of events)
Tension principle: Every scene needs something at stake. Character wants X, obstacle prevents it, choice has consequences. "Then everything worked out" is not a story.
Use concrete details over abstractions: "2004 Honda Civic with duct tape on the bumper" beats "old car". "Ate cereal standing at the counter" beats "had breakfast quickly".
Build to the resolution: Complicate the situation at least twice before resolving. Easy solutions early = no stakes. Make characters work for outcomes, fail at least once.
</write_compelling_stories>