I built a set of 6 skills for Claude Code that encode my approach to the design process; my particular take on the stages every design project should move through. Five cover the core stages of design work; one runs across all of them, focused on communicating with stakeholders. They save time without sacrificing quality. View on GitHub.
AI tools are fast, but they don't have a point of view. Left to their defaults, they produce generic outputs that skip the parts of design that matter most: framing the right problem, navigating tradeoffs, knowing when to push back. The speed is real; the thinking is shallow.
I was skeptical at first. My early experiments followed a pattern: vague prompt, generic output, confirmation that AI wasn't ready for real design work. But the problem wasn't the tool. It was that I was giving it nothing to work with; no context about how I think, what I prioritize, or what good looks like.
That gap was the opportunity. If I could encode my approach to the design process into structured skills, I could turn AI from a shallow generator into a thinking partner that works the way I work; without sacrificing the rigor that makes design outcomes hold up.
I started by asking a question I'd never had to answer explicitly: what does my design process actually look like when it's working well? Not the version I'd put on a slide, but the real sequence of thinking that leads from ambiguity to a grounded decision.
I learned design through the double diamond; that framework shaped how I think about divergence and convergence. But over the years my process evolved into something more specific. The stages I landed on are informed by that foundation, but they reflect how I actually work, not a textbook model.
I identified five stages and one cross-cutting practice. The five stages are sequential; each demands a different mindset, and collapsing them into a single prompt produces noise. The sixth, communication, isn't a step you do after the others. It runs throughout, because design that doesn't get communicated effectively doesn't ship.
Each became a skill for Claude Code; a structured document that encodes not just what to do, but how to think about the work, what tradeoffs to weigh, and what signals to look for. The skills can be used individually for a focused task, or in sequence as a full design process.
Gathering evidence, analyzing the competitive landscape, and building a grounded understanding of users before any design work begins. The depth adapts to the project; the underlying questions stay consistent.
Establishing clarity on the problem, its significance, the criteria for success, and a deliberate plan for the approach. Framing and planning aren't sequential; they evolve together.
Divergent exploration, deliberate convergence, and design decisions that account for user needs, business constraints, and technical feasibility simultaneously. This skill addresses the thinking; it doesn't produce artifacts.
Building interactive prototypes where design principles carry into the artifact, not get abandoned the moment code is written. The context and technology change; the standard stays constant.
Evaluating design work against its stated goals and guiding what comes next: ship, iterate, rethink, or reframe. Connects back to the success metrics from problem framing.
Communicating design work to different audiences at every stage of the process. The format, depth, and framing adapt to the audience and objective of each interaction. This skill is not a step; it can and should be used at any point, because design never happens in isolation.
Skills, not prompts. A prompt is a one-shot instruction. A skill encodes a way of thinking; it tells the AI what to prioritize, what tradeoffs exist, and what good looks like in context. This distinction is what makes the output reliable rather than lucky.
Stages, not roles. I considered structuring the system around design roles (researcher, strategist, visual designer). I chose stages instead because the same person moves through all of them. Roles create handoff points; stages create a continuous thread of thinking that builds on itself.
Communication as a cross-cutting skill. Framing work for engineers is a different skill than framing it for leadership, and both matter enough to be explicit about. Rather than placing it at the end of the sequence, I kept it separate; it's relevant at every stage, not just after the work is done.
The skills are now part of my daily workflow. Strategy documents that used to take days come together in hours. The quality hasn't dropped; if anything, the forced structure catches gaps I'd otherwise skip under time pressure. The boring scaffolding gets automated. The judgment stays mine.
The deeper lesson was personal. Writing these skills forced me to articulate my design process at a level of specificity I'd never attempted. When you have to make your thinking explicit enough for another intelligence to follow, you discover which parts of your process are principled and which are just habit. That exercise alone changed how I work.