The Claude Code skills I actually use

A skill is a markdown playbook the AI loads when a task matches. After a year of building client sites this way, these are the skills that earned a permanent place: what each does, how I use it, why it stays. The AI brain guide covers the three layers; this one opens the skills drawer.

The rule behind all of it: if a skill might apply to the task, load it before doing anything. The skill sets the approach, so nothing is improvised.

Install

Much of sections 3 to 5 now ships as open skills in one repo, molveau/skills: my taste rules and the inspiration index, Impeccable's design references and the GSAP rules, merged into a few skills that credit their authors. All eleven, with the skills CLI (Claude Code, Codex, Cursor and other agents that read SKILL.md):

npx skills add molveau/skills

In Claude Code, as a plugin:

/plugin marketplace add molveau/skills
/plugin install molveau-skills@molveau

The process skills of sections 1 and 2 are not in it: the workflow skill points to Superpowers and Matt Pocock's skills for those. The bundles, what each skill merges and how each compares with other open skills are on the skills page.

1. Process discipline

From a public suite called Superpowers, the skeleton of every feature:

• Brainstorming. Design before code: questions one at a time, approaches with trade-offs, approval on a written spec before anything is built. Why: it kills "confidently built the wrong thing", the most expensive AI failure mode.
• Writing plans. Turns the approved spec into bite-sized tasks with verification steps. Why: a plan in a file survives the end of a session.
• Test-driven development. Red-green-refactor, enforced; no implementation before a failing test. Why: with an AI writing the code, the test is the spec it cannot argue with.
• Systematic debugging. Reproduce, minimize, hypothesize, instrument, then fix. Why: it stops pattern-matched fixes that treat the symptom.
• Subagent-driven development. Each task goes to a fresh sub-session with curated context; the main session orchestrates. Why: long contexts decay, and a fresh one carries only what the task needs.
• Verification before completion. No "done" without running the checks and showing output. Why: the highest-value skill in the stack, since a file written proves nothing about the feature.

2. Thinking partners

The skills I use before and around the code:

• Grill me. The AI interviews me relentlessly about a plan until every branch of the decision tree is resolved. How: before committing to any ambitious spec. Why: it finds the decisions I did not know I had not made.
• Grill with docs. The same interrogation, tested against the project's domain model and past decisions, updating the docs as answers land. How: on codebases with a CONTEXT.md and decision records. Why: the plan gets sharper and the documentation stays true in the same session.
• Design an interface. Parallel subagents produce radically different designs for the same module, then compare. How: whenever a module's shape is genuinely open. Why: the first design is rarely the best one, and paying for three drafts up front is cheaper than one rewrite.
• Zoom out. Forces the AI to stop narrating trees and describe the forest. How: whenever I am lost in an unfamiliar part of a codebase. Why: orientation first, detail second.
• Teach. Explains a concept using this workspace's real code as the material. Why: a lesson built on your own repo sticks better than a generic tutorial.
• Improve. A read-only senior-advisor survey of a codebase that outputs prioritized, self-contained improvement plans for another session to execute. Why: separating diagnosis from surgery keeps both honest.
• Improve codebase architecture. Hunts for consolidation and deepening opportunities, guided by the project's own domain language and decision records. How: a periodic architecture pass, not a daily tool. Why: entropy is constant, so the push back has to be scheduled.
• Request refactor plan. Interviews me about a refactor, then produces a plan of tiny safe commits and files it as a GitHub issue. Why: big-bang refactors stall, while twenty boring commits ship one at a time.
• QA. A conversational bug-reporting session: I describe issues in plain words, the AI explores the code in the background and files proper GitHub issues. Why: friction is what stops bugs from being written down.
• Diagnose. The loop for hard bugs and performance regressions: reproduce, minimize, hypothesize, instrument, fix, regression-test. Why: the last step leaves a test behind, so the bug stays fixed.
• Handoff. Compacts a long session into a document the next session resumes from. Why: the context window ends before the work does.
• Find skills. Searches for installable skills when a need comes up. Why: someone has usually already encoded the workflow.

3. The taste layer

Mine, and the reason two sessions weeks apart produce work that looks the same:

• Design taste. The canonical file: typography rules (65 characters per line, two families), motion rules (transform and opacity only, under 300ms), and per-project design tokens. Invoked before any UI work, no exceptions. Why: taste in a file carries over; taste in my head gets re-explained every session.
• Design inspiration index. A retrieval map from need to source: pricing-page reference, navbar ideas, motion examples. Why: "go to Y for X" beats an hour of doom-scrolling. The sites inside it have their own guide with screenshots.
• Frontend design. Guardrails against the generic AI aesthetic when building new UI. Why: the default AI look is the same everywhere, and this skill overrides it.
• Web design. The broad reference for CSS architecture, typography and accessibility. Why: the generalist backstop when no specific skill fits.
• Teach impeccable. A one-time setup that gathers a project's design context and saves it into the AI's config. Why: every later design pass starts informed.

4. Design verbs: one verb, one pass

A suite of single-purpose design skills. Each does one job, so the pass actually finishes, where a "review everything" prompt reviews nothing in depth.

Review passes I run on nearly every feature:

• Audit. Full interface audit: accessibility, performance, theming, responsiveness, with severity ratings.
• Critique. Design review with reasons: hierarchy, information architecture, emotional resonance.
• Polish. The last pass before shipping: alignment, spacing, consistency details.
• Harden. Error states, text overflow, i18n edge cases; production-proofing.
• Distill. Remove complexity until only the essence is left.

Dials I reach for when a design leans the wrong way:

Skill	Use it for
Arrange	layout, spacing and rhythm when a grid feels monotonous
Adapt	screen sizes, devices, contexts
Animate	purposeful motion and micro-interactions, added after the design works
Bolder / Quieter	opposite dials: amplify a boring design, or calm an aggressive one
Colorize	strategic color for monochromatic interfaces
Clarify	UX copy: labels, errors, microcopy
Delight	the personality touches that make an interface memorable
Onboard	first-run experiences and empty states
Optimize	loading, rendering, bundle size
Overdrive	deliberately ambitious implementations: shaders, spring physics, 60fps virtual tables

I use Overdrive sparingly, on the one moment per site that deserves it.

Two design-system builders keep a component library healthy:

• Extract. Harvests repeated patterns into reusable components and design tokens. How: after a few features ship, mine them. Why: a design system grows by extraction rather than upfront invention.
• Normalize. The reverse direction: makes drifted screens conform to the system again. Why: drift is silent until this pass surfaces and fixes it.

5. Motion: the GSAP suite

Eight official skills, split so the AI loads only the part the task needs:

Skill	Covers
core	tweens, easing, stagger
timeline	sequencing
ScrollTrigger	scroll-linked animation and pinning (this site's scroll story leans on it)
react	useGSAP, cleanup on unmount
plugins	Flip, Draggable, SplitText and friends
performance	transforms only, no layout thrashing
utils	helpers
frameworks	Vue/Svelte

Motion bugs are usually misuse of one specific API, and the specific skill knows that API's rules.

6. Lookups and generation

• UI/UX database. An offline-searchable collection: 67 styles, 161 palettes, 57 font pairings and 99 UX guidelines (project repository). "A palette for a warm healthcare brand" becomes a query you can run.
• Current documentation. Fetches today's docs for the library version actually installed. Why: training data ages, and the installed version is the one that has to work.
• Component search and generation. The 21st.dev family: search the community registry before hand-writing a widget, generate UI variants from a prompt, publish your own components and themes back. Why: the fastest component is the one already built.

What about icons?

Icons come from a source list rather than a skill. Icon sets, fonts, photos and 3D assets live in the free design assets guide; which gallery to open for which need lives in the component and inspiration sites guide. The inspiration index skill above routes between them.

Writing your own

Every skill in sections 3 and 4 started as a correction I gave the AI twice. The template stays small:

---
name: my-skill
description: When to invoke this - be specific, the AI matches on it
---

## Rules
- The things you keep repeating, written once.
- Concrete numbers beat adjectives: "under 300ms", not "fast".

## Checklist
- [ ] The steps that must happen, in order.

Start with one: the checklist you already recite before shipping. Put it in .claude/skills/. If the AI does not load it when it should, sharpen the description line first, since that is what the AI matches on.

If you would rather start from mine, every skill on the skills page is a SKILL.md you can read, fork and trim, and the source is at github.com/molveau/skills.