Skills as
Design Ops
Some parts of my work repeat. Grounding a design decision in the right archetype. Kicking off a discovery project so the phases don’t drift. Preparing for a hard conversation with a specific stakeholder. Instead of running each one from scratch, I build Claude Code skills — small, reusable prompt systems that encode the workflow once and run it on demand.
Encode the workflow, not the answer
A Claude Code skill is a small markdown file with a name, a trigger, and a set of instructions. When the trigger fires — a keyword, a filename, a slash command — Claude Code loads the instructions and follows them. It’s an old idea: codify the procedure so the outcome is repeatable. What’s new is that the procedure can be written in prose and executed by an assistant.
For me as a designer, that unlocks something specific. Every workflow I run more than twice — every diagnostic, every review lens, every framing move — is a candidate for a skill. Instead of remembering to invoke it, I let the trigger invoke it. Instead of the workflow drifting between projects, the skill holds it steady.
What each one solves
Three examples that cover the range — a research skill, a project-shape skill, and a communication skill.
- Problem
- Personas that live in a research report get consulted at the start of a project and forgotten by week three. When they resurface, it’s often as designer-remembered caricatures — the version of the archetype most convenient for the direction the design is already going.
- What the skill does
- Loads a set of research-grounded archetypes (pains, JTBDs, activation triggers, maturity level) and lets me activate one as a diagnostic lens for the task in front of me. It refuses first-person roleplay — the skill is a lens, not a puppet — and it will not invent persona data. When evidence is thin, it says so.
- Where it fires
- Problem framing, design critique, PDD review, usability planning, research synthesis, stakeholder communication — any point in the PDLC where a design decision needs to be pressure-tested against the right archetype.
- Why it matters
- It closes the gap between research owning the personas and design using them. The evidence stays connected to the decision, at the moment the decision is being made.
- Problem
- Discovery projects sprawl. Six weeks in, it’s easy to forget what the initial hypothesis was, which phase we’re actually in, and which artifacts are next-in-line versus done. Momentum decays into to-do triage.
- What the skill does
- On session start, it loads the project context, orients to the current phase, asks for anything missing, and — if no phase plan exists — proposes one and generates a navigable HTML plan document that reads at a glance. Every subsequent session picks up from the plan rather than from scratch.
- Where it fires
- Every time I open Claude Code inside a discovery project folder. The skill is scoped to the folder — it doesn’t leak into unrelated work.
- Why it matters
- Discovery quality is a function of continuity. A skill that reboots the project’s shared brain every session buys back the ten minutes I used to spend re-orienting — and, more importantly, stops me from skipping that step and drifting.
- Problem
- Every round of moderated testing leaves a pile of raw material in different shapes — Gemini exports, plain markdown, video transcripts, Google Docs. Turning that into a Miro board of color-coded stickies, and then again into a slide deck to walk stakeholders through, is where an hour of real synthesis quietly becomes half a day of copy-paste. The tax means it doesn’t always get done.
- What the skill does
- Takes session notes in any of those formats, extracts the moments that matter, and produces two artifacts in one pass: a Miro board of color-coded sticky notes (per-session frames or a multi-session synthesis layout), and a companion slide deck ready to present to stakeholders — key findings, verbatims, and per-hypothesis verdicts already laid out. Triggered by a Miro URL, a source, or phrases like "synthesize these sessions".
- Where it fires
- Right after a testing session — one link, one input, both outputs populated. Or at the end of a testing round, when 4–6 sessions need to be pulled onto one synthesis surface and then walked in front of a leadership audience the same week.
- Why it matters
- The bottleneck between raw evidence and a decision-grade artifact is manual transcription-and-re-layout. The skill removes that tax at both ends — the analysis surface and the stakeholder surface — so the sessions that would have been left as raw notes make it all the way to the walkthrough where they actually change the direction.
What I’ve learned about writing them
Building useful skills is a design problem — the same rules that make a good component make a good skill.
- Refuse the wrong thing loudly. Every skill I’ve written has an explicit list of what it will not do — invent data, roleplay in first person, execute silently on a task it doesn’t fit. The refusals are what make it trustworthy.
- Small, versioned, opinionated. A skill that tries to do everything ends up doing nothing well. Each one does one thing and holds an opinion about how. When the opinion turns out wrong, the skill is a markdown file — I edit it.
- Scope carefully. Skills that only apply inside one project folder stay there. Skills that apply everywhere live in the global config. Getting the scope right prevents cross-project bleed.
- Delight: 2 moments (progress framing, plain-language language toggle)
- Friction: 3 moments (assumption of prior sustainability vocab in Step 2)
- Pain: 1 moment (upgrade prompt density in the free-tier scorecard)
Skills as portable design ops
The reason I invest time in skills — instead of just running the workflow — is that they compound. A skill written once serves every future project. A well-scoped skill can be shared with a team so the workflow becomes a team practice, not a personal one. And a skill that captures a hard-won lesson turns into a piece of institutional memory that survives the next re-org.
Want to know more?
Let’s talk about how I built these — without the sensitive company details. The examples above are illustrative, and the details of each one stay inside the org that owns them.