The Claude Code skills I actually use

In the AI brain guide I explained the three layers: instructions, memory, skills. This one opens the skills drawer completely. A skill is a markdown playbook the AI loads when a task matches; after a year of building client sites this way, here is every skill that earned a permanent place — what it does, how I use it, and why it stays.

One rule powers all of it: if a skill might apply to the task, load it before doing anything. The skill sets the approach. Improvisation is what skills exist to prevent.

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: 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: plans survive session boundaries; vibes do not.
• 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 — before any fix. Why: 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; fresh ones do not.
• Verification before completion — no "done" without running the checks and showing output. Why: the single highest-value skill in the stack. A file written is not a feature working.

2. Thinking partners

The skills I use before and around the code — planning, architecture, understanding:

• 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, but 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 documentation stays true while the plan gets sharper — two chores, one 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; 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: lessons anchored in your own repo stick; generic tutorials do not.
• 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; this is the scheduled push back.
• 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 die; twenty boring commits survive.
• 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 disciplined loop for hard bugs and performance regressions: reproduce, minimize, hypothesize, instrument, fix, regression-test. Why: hard bugs do not yield to vibes.
• Handoff — compacts a long session into a document the next session resumes from. Why: context windows end; work does not.
• 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 the same-looking work:

• 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 kept in a file compounds; taste kept in my head evaporates per 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; defaults are the enemy.
• Web design — the broad reference for CSS architecture, typography, 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: run once per project so every later design pass starts informed.

4. The design verbs — one verb, one pass

A suite of single-purpose design skills. Because each does exactly one job, the pass actually finishes — a "review everything" prompt reviews nothing.

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:

• 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. Used sparingly, on the one moment per site that deserves it.

Design-system builders — the pair that keeps 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, not by upfront invention.
• Normalize — the reverse direction: makes drifted screens conform to the system again. Why: drift is silent; this makes it visible and fixes it.

5. Motion — the GSAP suite

Eight official skills, split so the AI loads only the part the task needs: 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, and frameworks (Vue/Svelte). Why a suite matters: 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: 84 styles, 161 palettes, 73 font pairings, 99 UX guidelines. "A palette for a warm healthcare brand" becomes a query, not a vibe.
• Current documentation — fetches today's docs for the library version actually installed. Why: training data ages; your dependency versions do not care.
• 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?

Not a skill — a source list. 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 is what 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/, and stop reciting.