skills

Before building a feature, state the user-experience it produces (what the person sees, does, and gets, step by step) and get the user to confirm that experience is right before writing code. Use this whenever the user asks to build a feature, flow, or product surface ("build the signup", "add a connect-your-account flow", "make the onboarding") without having specified what the end user should experience. Use it even when the implementation seems obvious, because the obvious implementation often encodes a user-experience the user never actually signed off on. This skill aligns on what the *end user* of the feature will see and do — for teaching the *developer* an unfamiliar standard or protocol before they build on it, use [[teach-the-mechanism]] instead.

When the user is about to build something on an unfamiliar standard, protocol, or architecture, explain the user-visible flow first and map each step to the mechanism underneath before writing any code. Use this whenever the user asks how to implement something they say is new to them ("new standard", "still learning", "I don't fully get it"), asks "can you explain X instead of building it", or asks for the user process / user journey of a system. Use it even when the user originally asked for an implementation and working code would technically answer them, if there's any signal they don't yet hold the mental model. This skill teaches the *developer* an unfamiliar protocol so they can debug what gets built — for aligning on what the *end user* will experience in a feature, use [[align-user-journey]] instead.

Score an existing SKILL.md line-by-line and flag the dead weight using the would-have-anyway and trigger tests. Use this whenever the user wants to audit, review, score, or sanity-check a skill, says "is this skill any good" or "why isn't this triggering", or hands you a skill file expecting a verdict. Use it even when they don't say "audit" — if they're staring at a skill file asking what's wrong with it, this is the job.

Before implementing anything with a design choice in it, lay out 2-3 real approaches with tradeoffs and a recommendation, then wait for the user to pick. Use this whenever the task introduces or reshapes a pattern, references a feature the codebase already has, or asks "how should I build X" — even if the user didn't phrase it as a design question. Use it even when the answer seems obvious; the obvious approach is usually the over-engineered one, and the most expensive mistakes look confident.

Create a new agent skill that actually triggers and actually changes behaviour. Use this whenever the user wants to create, write, build, or rewrite a skill, says "turn this into a skill" or "make this a skill", or describes a repetitive workflow they keep re-explaining to Claude. Use it even when they don't say the word "skill" but are clearly describing a reusable process they want followed consistently.

Generate or update a project's CLAUDE.md file using structured interrogation of the codebase and user. Follows Apple's leaked CLAUDE.md patterns and Anthropic's best practices. Use when user wants to create, update, improve, audit, or rewrite their CLAUDE.md file, or when starting a new project that needs AI context.

Interrogate the user on what unit tests to write for their recent changes. Walks through the diff branch-by-branch, surfacing assumptions, edge cases, and business logic that need test coverage. Use when user says "test interrogate", "interrogate me on tests", or wants to stress-test their testing plan after a PR.