ai/dot-agents/skills/design/SKILL.md
Design with strong aesthetic direction and intentionality. Use when asked to create, style, or rethink any visual or digital artifact — interfaces, pages, apps, visualizations, diagrams, presentations, or any designed thing.
npx skillsauth add lolwierd/dotfiles designInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
The user believes that everything worth making should have thought behind it — thought that the experiencer can extract if they're motivated enough. This is the single principle that drives everything below.
Every choice must be derived, not defaulted. Typography, color, layout, structure, animation, detail — none of these have correct answers in the abstract. They have correct answers for this specific project, this audience, this medium, this mood. If you find yourself reaching for something because it worked last time or because it's the convention, stop. Ask what THIS project needs and reason from there.
Density with clarity. The user's taste lives in a specific tension: rich information presented through smart architecture so nothing feels overwhelming. Progressive disclosure, thoughtful hierarchy, clever structure. A well-organized bookshelf, not a pile of books and not an empty shelf.
Quiet depth over loud flash. The surface should be approachable. The details should reward attention. Layers reveal themselves to people who look closely. Design for the person who lingers, not just the person who glances.
Personality is non-negotiable, but it's not decoration. The design should have a voice — opinions embedded in the choices themselves. What that sounds like depends entirely on context: an opinionated error message in a CLI, an unexpected detail that breaks a grid, a hand-drawn edge on a diagram, an unconventional axis on a data viz. The principle is that the thing was made by someone with a point of view, and you can feel it without being told.
No house style. If consecutive projects start resembling each other — same type, same palette, same structural patterns — something has gone wrong. Each project should look like it was designed for itself. Before any major choice, ask: am I choosing this because it's right here, or because it's familiar?
The 7/10 test. Before committing to a major decision, ask: if 10 people got this same brief, would 7 of them make this choice? If yes, dig deeper. Find the answer that's still right for the project but isn't the default one. This isn't about being strange for its own sake. It's about thinking past the first idea.
Following the process doesn't guarantee the result is good. You can derive a concept, justify every choice, pass the 7/10 test, and still produce something that's merely correct — thoughtful on paper but lifeless in practice. The skill's process is necessary but not sufficient. What bridges the gap is taste: the ability to evaluate whether your own output has something alive in it, or whether it's just well-reasoned furniture.
Treat your output as evidence, not as a conclusion. The concept is a hypothesis about what this project needs. The first draft is an experiment. Look at the result the way you'd look at data: what is it actually telling you? Does it have energy, or does it just have logic? If the answer is "I followed the process and it all makes sense but something feels inert," trust that feeling over the paperwork. The process is a scaffold, not a guarantee.
The material talks back. A concept might sound right in the abstract and then fall apart when you see it rendered. A color palette that seemed warm on a mood board might feel muddy in context. A type pairing that seemed distinctive might fight the layout. This isn't a failure of planning — it's the artifact giving you information your plan couldn't anticipate. The concept serves the design, not the other way around. If the execution is revealing that the concept needs to shift, shift it. Clinging to a concept that the material has outgrown produces designs that are ideologically coherent but experientially dead.
Build range deliberately. The 7/10 test catches industry defaults, but there's a subtler version: your own defaults. If you tend toward quiet, restrained, warm — and a project genuinely calls for loud, confrontational, cold — the discomfort you feel is a signal to push forward, not retreat to familiar ground. Taste isn't having one mode and executing it well. It's having a wide enough vocabulary that you can match the right register to the right context. When a project calls for something outside your comfort zone, sit with it. The stuckness is where the growth is.
Ask: would I remember this tomorrow? Not "is this well-designed" or "is this thoughtful" — those are process questions. The taste question is simpler and harder: if I saw this for thirty seconds and moved on, would anything stay with me? If the answer is no, the design needs more heat. Not more elements, not more decoration — more conviction. Something that couldn't exist in any other version of this project.
Start with the soul of the project. Before choosing any visual element, identify: what is this thing, who is it for, and what should it feel like? Not "modern and clean" — something with actual texture. Then find the concept (one sentence on why the visual direction serves this project), and the hook (the single memorable thing about this design).
Derive everything from the concept. The typeface should sound like the project's voice. The palette should emerge from the project's mood. The layout should reflect the content's own logic. If any of these feel interchangeable — like they could belong to a different project without anyone noticing — they haven't been thought through.
Scale the ceremony to the stakes. The philosophy always applies; the process flexes. A quick diagram in conversation still deserves intentional choices, but it doesn't need a design system or a rationale document. A landing page does. Use judgment. The soul is constant; the apparatus around it is proportional.
The thought behind a design should be legible within the artifact itself. A motivated person examining the source, the structure, or the details should be able to reconstruct the reasoning without needing a companion explanation.
Name things semantically: --reading-lamp-amber communicates intent, --color-warm-3 communicates nothing. Comment at decision points, not obvious lines — explain why the grid breaks here, not what the code does. Let structure reflect logic so that hierarchy is visible without labels. The artifact should teach you about itself if you pay attention.
When feedback comes — from the user or from the work itself — the key question is: is the concept wrong, or is the execution off?
If the concept is right but a surface treatment isn't landing, adjust within the existing system. Don't blow everything up. If the concept itself isn't holding — the mood feels wrong at a fundamental level, or the material keeps resisting the direction — acknowledge it and rethink from first principles rather than patching your way to a different idea. Either way, identify what's working and protect it.
Be honest about what the feedback is actually saying. "I don't like the color" might mean the color is wrong, or it might mean the color is revealing that the whole mood is wrong. "This feels generic" might mean the execution is too safe, or it might mean the concept wasn't distinctive enough to begin with. Diagnose before you act.
Working, complete output — the real thing, not a description of it. Systematic enough to be tweakable (tokens, variables, whatever the medium's equivalent is). Accessible in whatever way the medium demands: semantic structure, readable contrast, keyboard support, legible type sizes. Non-negotiable.
For designs of substance, include a DESIGN.md alongside the output. This is not documentation — it's the design's inner monologue. Why this and not something else, what it's trying to feel like, what was rejected and why, the stray detail nobody will notice but you put there anyway. This is the deep layer for the truly motivated, but it only matters if the artifact also rewards curiosity on its own.
Every medium has its "default good" — the aesthetic everyone reaches for because it's safe. In web it's SaaS gradient-blur-cards. In slides it's the startup pitch template. In mobile it's Apple's HIG verbatim. Identify what generic good looks like in your medium, then don't do that. Don't use unstyled library defaults. Don't add decoration that doesn't connect to the concept. And never accept "clean and modern" as a design direction — that's the absence of one.
The north star: make something where a stranger would look at it and think "someone really thought about this."
development
Present visual options for architecture, UI, and code decisions with high-fidelity side-by-side previews. For comparing approaches visually — code diffs, diagrams, UI mockups, images — not for gathering structured input (use interview for that). Supports previewBlocks (code, mermaid, image, html), previewHtml, generate-more loops, and plan/PRD-driven flows.
development
Generate beautiful, self-contained HTML pages that visually explain systems, code changes, plans, and data. Use when the user asks for a diagram, architecture overview, diff review, plan review, project recap, comparison table, or any visual explanation of technical concepts. Also use proactively when you are about to render a complex ASCII table (4+ rows or 3+ columns) — present it as a styled HTML page instead.
development
Use when the task asks for a visually strong landing page, website, app, prototype, demo, or game UI. This skill enforces restrained composition, image-led hierarchy, cohesive content structure, and tasteful motion while avoiding generic cards, weak branding, and UI clutter.
devops
Deploy applications and infrastructure to Cloudflare using Workers, Pages, and related platform services. Use when the user asks to deploy, host, publish, or set up a project on Cloudflare.