Twenty-four procedures instead of asking it to write well - grafsoul

AI TechJuly 4, 2026 · 8 min

Twenty-four procedures instead of asking it to write well

24 procedures with steps and exit checks, eight lifecycle commands, and tables of the excuses agents use to skip rules. What it gives, what it does not replace, and where installing it piecemeal breaks.

Agent Skills - библиотека инженерных процедур для AI-агентов

Tell an agent to "write production code" and you get precisely what it considers production code. Usually a working function with no specification, no tests, no review and no check that it did not break something next door.

This is not laziness on the model's part. An agent optimises the nearest goal: reach a working result as fast as possible. The shortest road there runs past everything that makes code fit for production.

Addy Osmani's agent-skills tries to close that gap not by persuasion but by structure: twenty-four procedures with steps, exit checks and - the most interesting part - prepared answers to the excuses an agent will use to get around the process.

Eight commands as a map of the lifecycle

The top level is eight commands laid out across six phases: define, plan, build, verify, review, ship.

Command	What it does	Principle
`/spec`	define what we are building at all	spec before code
`/plan`	break the implementation down	small atomic tasks
`/build`	build in slices	one slice at a time
`/test`	prove it works	tests are the proof
`/review`	check before merge	improve code health
`/webperf`	audit web performance	measure before optimising
`/code-simplify`	simplify	clarity over cleverness
`/ship`	prepare the release	faster is safer

The commands are only entry points. Underneath sit procedures that also activate on their own, by the kind of work: design an API and the interface-design procedure comes in, build UI and the frontend one does, write tests and the corresponding one does.

Twenty-four procedures, not twenty-four pieces of advice

A fresh clone holds exactly twenty-four: twenty-three lifecycle procedures plus a meta-procedure that works out which of them fits the current task.

The composition shows in the names: requirements interview, idea refinement, planning and task breakdown, spec-driven development, test-driven development, incremental implementation, code review, code simplification, frontend, interface design, debugging, browser testing through developer tools, security, performance, observability, documentation and architecture decisions, git workflow, continuous integration, deprecation and migration, shipping, context engineering, source-driven development and doubt-driven development.

Each is a working process with steps and completion conditions, not a memo. Plus seven shared references: a definition of done, checklists for testing, security, performance, accessibility and observability, and a catalogue of orchestration patterns. And four agents: a code reviewer, a security auditor, a test engineer and a web-performance auditor.

Advantage one: the excuses are closed in advance

Here is the device that makes this project worth examining on its own.

Almost every procedure - twenty-two of the twenty-four - carries a table of the typical excuses an agent uses to skip a step, with prepared rebuttals. Only the meta-procedure and idea refinement lack one, having nothing to skip. The rule is not merely repeated - the specific phrase the model uses to wriggle out of it gets addressed.

The README's own example: "I'll add tests later." An instruction that simply repeats "write tests" is powerless against that phrase - the model already agrees tests are needed, it is only deferring them. A table answers the excuse itself.

The device is precise because it targets the mechanics. A model rarely breaks a rule outright; it finds a wording under which the rule seems not to apply. Closing that wording in advance works better than restating the rule.

Advantage two: autonomy with an approved boundary

The /build auto mode addresses a question usually settled by extremes: either confirm every step, or let the agent go entirely.

Here is the middle. Once the specification is approved, the agent builds the plan itself and works through every task in one pass - the human approves the plan once rather than confirming each task.

What gets removed matters. What is removed is the human between tasks, not the verification: every task still goes through tests, gets committed individually, and the agent pauses on a failure or a risky step.

That is a sound model of managing autonomy: the human approves the boundaries, and inside them the agent is free.

Advantage three: portability through a third-party installer

The shortest installation route is not the project's own installer but a general CLI for skills:

Bash

# all twenty-four
npx skills add addyosmani/agent-skills

# browse the list before installing
npx skills add addyosmani/agent-skills --list

# a single procedure
npx skills add addyosmani/agent-skills --skill test-driven-development

Per the README, that CLI installs skills into seventy-odd agent environments. For a project made of markdown files that is a sensible bet: rather than writing adapters for every environment, lean on a common format.

Native routes exist too - a plugin for Claude Code, a plugin for Codex, separate layouts for Gemini and OpenCode.

Advantage four: policy and procedure are kept apart

The separate instruction for Cursor deserves attention because it states a general principle.

Procedures go into .cursor/skills/, and only short policies go into the rules. Pasting full procedures into rules is explicitly forbidden.

The difference is that a rule applies always and permanently occupies context, while a procedure loads for a task. Mixing them means keeping the release procedure in the model's window while it fixes a typo in the markup.

Cost one: it does not replace your project's policy

A generic frontend procedure does not know your design system, your service targets, your threat model or your deployment constraints. Until it is told, it works from general notions of good.

Hence the right place for this pack: a base engineering layer with your specifics on top. Not a project constitution.

Cost two: a single-skill install does not bring everything

There is a specific gap here, honestly described in the README.

Installing one procedure through the CLI copies only its directory, not the repository-level shared references. The procedure still works, but the links to the shared checklists - security, testing, performance, accessibility - point nowhere.

The way around it is a whole-repo integration, a clone, or copying the needed checklist into the procedure by hand. The project does not hide the problem: the README links to the open issue tracking it.

A small thing, but an annoying one for exactly the scenario of "I will take the one procedure I am missing" - which is the most attractive way to use a pack like this.

Cost three: packs start conflicting

The problem appears not inside the project but at the seams.

Install several large procedure packs at once and one event starts activating competing instructions. One pack demands strict test-driven development, another brings its own plan format, a third its own review procedure. There is no formal conflict, but in practice the agent chooses, and its choice is unpredictable.

Configuring an agent gradually turns into dependency management for instructions - without versions, without conflict resolution, and without any clear way to tell which one fired.

Who it suits

Anyone needing decent quality gates without writing their own pack. Twenty-four ready procedures with exit checks is a marked saving against assembling the same thing from scratch.

Anyone working across environments. Betting on a common skill format and a third-party installer gives portability that home-grown packs usually lack.

Anyone wanting to migrate gradually. Installing one or two procedures, checking the benefit on real work and then expanding is the intended path, not a workaround.

Anyone assembling their own harness. As a model of how a procedure should be built - steps, exit checks, a table of excuses - this pack is one of the tidiest.

Who it does not suit

Projects with an established strict process. If you already have your own review procedure, your own gates and your own definition of done, a second pack will compete with the first.

Anyone expecting domain knowledge. The procedures give discipline, not an understanding of your product. The specifics still have to be written down by you.

Anyone installing several large packs at once. Before doing that, understand you will be untangling the overlaps by hand.

Conclusion

Eighty-seven thousand stars for a pack of markdown files is a measure less of quality than of a question whose time has come. Instructions for an agent have stopped being one large text and become a set of small pluggable procedures with checks.

What this project gives an agent is not extra knowledge. The model already knows tests are needed and that secrets do not belong in code. What it gives is operational discipline: a sequence that cannot be skipped, and the excuses for skipping it closed in advance.

And it is best taken in parts. Rather than adopting the whole philosophy, take exactly the procedures your own process is missing - all the more so because the project itself suggests that path.

Sources

The material was verified on 14 August 2026 against the project's repository. The composition was counted in a fresh clone rather than taken from the description: twenty-four procedures, eight commands, four agents, seven shared references. Metadata - about 87 thousand stars and 9.3 thousand forks, MIT license. The single-skill installation limitation and the link to the open issue are given as written in the README. Supplemented on 15 August 2026 against a fresh clone: the composition was recounted and held, but the list of procedures in the text was incomplete - planning, code simplification and browser testing have been added; the excuse table is now stated as present in twenty-two of the twenty-four procedures; the seventh reference and the four agents were added.