Addy Osmani's agent-skills
A skill pack built around one failure point: the agent skips steps. Its answer is the full software development lifecycle, run every time. Define, plan, build, verify, review and ship each have a slash command, reviewer personas cover the gates, and every skill carries a table of the excuses an agent gives for skipping a step, with a rebuttal for each. It is the most team-friendly of the three packs, and the only one that runs past the merge into CI, launch and deprecation.
Addy Osmani's agent-skills are the process pack from What it takes to trust an agent, the one that guards against steps that quietly get skipped mid-work. The pack is the software development lifecycle done properly, with no new metaphor to learn.
The README and the adoption guide own the current details.
What it is
A pack of engineering skills for AI coding agents, with lifecycle slash commands, reviewer personas and shared reference checklists. The README credits Google's engineering culture directly, including Software Engineering at Google and Google's engineering practices guide. Those ideas sit inside the step-by-step workflows. Hyrum's Law in API design, the Beyonce Rule and the test pyramid in testing, Chesterton's Fence in code simplification, trunk-based development in git workflow, Shift Left and feature flags in CI/CD, and a deprecation skill that treats code as a liability.
The failure point it guards
The agent skips steps. Every skill is a structured workflow with steps and verification gates, plus an anti-rationalization table: the excuses an agent uses to skip a step, each with a rebuttal. The test-driven-development skill lists the familiar ones, such as "too simple to test", "tested it manually", "tests can come later" and "it's only a prototype", next to the reasons they don't hold. Writing the excuses down ahead of time changes the agent's default. The rule is no longer only "write tests". It is also the exact sentence that will tempt a skip, and the answer to it.
When to use it
Reach for it when:
- A team ships to production and wants a predictable process everyone recognizes.
- The quality gates are wanted without designing them from scratch.
- The work runs past the merge: CI/CD, observability, launch, deprecation.
- A greenfield project can adopt the whole lifecycle from the first commit.
Skip it when:
- A strict lifecycle already exists. Two lifecycles loaded at once add conflicting instructions for the same step, not rigor. The anti-rationalization tables are the part worth borrowing.
- The task is small. A button color does not need a spec, a plan and four reviewers.
- The real risk is building the wrong thing (Matt Pocock's skills) or an unproven claim of success (pstack).
At a glance
The lifecycle and its commands
| Stage | Command | What it does |
|---|---|---|
| Define | /spec |
A PRD covering objectives, commands, structure, code style, testing and boundaries, before any code |
| Plan | /plan |
Small, atomic tasks with acceptance criteria and dependency order |
| Build | /build |
One thin vertical slice at a time |
| Verify | /test |
Tests as proof |
| Review | /review |
Review before merge |
| Ship | /ship |
Pre-launch checklists, staged rollout, rollback |
Extra commands cover constraints (/constraints), web performance (/webperf) and simplification (/code-simplify). Skills also activate on their own when the work matches, for example API design work triggers the API design skill.
Checks worth knowing
/build auto— approve the plan once, and every task runs without a human stepping in between. The checks stay: each task is still test-driven and committed on its own, and the run pauses on a failure or a risky step.- Doubt-driven development — for any non-trivial decision mid-build, a fresh-context review whose only job is to doubt the claim: claim, extract, doubt, reconcile, stop. Scoped to high stakes: production, security, irreversible changes, unfamiliar code.
- Reviewer personas — a senior staff engineer for five-axis code review, a test engineer, a security auditor and a web-performance auditor.
Adoption
The adoption guide splits the path in two. A greenfield project can take the full lifecycle from day one, and /build auto fits well there. An established codebase gets an incremental, verification-first rollout that respects existing conventions and untested areas. Installing everything at once on an old codebase is the path the guide steers away from.
How to install
Any agent, through the open skills CLI:
npx skills add addyosmani/agent-skills
Claude Code, as a plugin:
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
Single skills can be installed with --skill <name>. The README notes that a single-skill install leaves out the shared reference checklists, so a whole-repo install is the safer default. The README has native setup notes for Cursor, Gemini CLI, Codex, Copilot and others.
Related
- What it takes to trust an agent — the essay that frames all three packs as theories of where agent work breaks.
- Matt Pocock's skills — the intent pack: agree on what to build before any code.
- pstack — the evidence pack: a passing build is not proof.
- Claude Code — one of the harnesses it installs into.