The addyosmani/agent-skills plugin for Claude Code: spec to ship

The moment it pays off

You are about to change something other people depend on: a payments path, an auth flow, a public API. The easy move is to open the editor and start typing. This plugin gets in the way of that on purpose. A spec has to exist before code does. A plan has to exist before the spec turns into files. A review has to happen before anything merges, and a checklist has to run before anything ships.

That is the whole shape of addyosmani/agent-skills: 36 components, 24 skills, 8 commands and 4 agents, that turn one software change into a sequence of gates instead of a single freehand session.

What is inside

The 8 commands are the entry points you type. Six of them line up with a single pipeline, one command per stage: spec writes down what to build before any code exists, plan breaks that spec into small ordered tasks, build implements one slice at a time, test treats a passing test as proof rather than a description, review runs a pass before merge, and ship is the last gate before production.

The other 24 are skills: structured workflows with their own steps and verification requirements, several of which the plugin's own author says activate automatically once you are doing the kind of work they cover, because Claude Code can match a skill's description to what you are asking for. The 4 remaining components are agent personas, standing reviewers you call in for a specific angle rather than a pipeline stage.

Two commands outside the main line

code-simplify reduces complexity in code that already works, without changing its behavior. webperf audits page performance and is the command that drives the web-performance-auditor agent described below. Neither sits in the spec-to-ship sequence; you reach for them when the code already exists and either needs to get simpler or needs its performance checked.

The four agent personas

Where the commands are pipeline stages, the agents are reviewers you bring in for one angle at a time:

• code-reviewer reads as a senior staff engineer running a five-axis review.
• test-engineer reads as a QA specialist: test strategy and coverage gaps, asking a change to prove itself.
• security-auditor reads as a security engineer running vulnerability detection and an OWASP-style pass.
• web-performance-auditor reads as a web performance engineer, and is the persona behind the webperf command.

Which of the 24 skills you would reach for directly

Most of the skills back one of the six commands rather than standing alone, but a few are worth knowing by name. using-agent-skills is the meta-skill: it maps whatever you are doing to the right workflow, which matters once you are choosing among two dozen of them. interview-me and idea-refine turn a vague ask into something concrete before spec-driven-development writes it down as a PRD.

On the build side, test-driven-development, source-driven-development and frontend-ui-engineering cover red-green-refactor discipline, grounding decisions in official documentation, and accessible interface work. On the review side, security-and-hardening and performance-optimization are measure-first passes rather than opinions about the code. And on the ship side, documentation-and-adrs and shipping-and-launch cover the parts that are easy to skip under deadline pressure: writing down why a decision was made, and having a rollback plan before you need one.

When you should not use it

If you want one skill, say test-driven-development on its own, installing all 36 components to get it is more surface than you need. The listing page linked at the top of this guide shows what is available and how much of it you would be pulling in.

And if your team already runs its own spec, review and release process, the value here is narrower. This plugin is a written, repeatable version of a discipline some teams already practice by habit. It is not a replacement for a process that already works, and it will not tell you that your existing one is wrong.