Agent Skills is a packaged set of engineering workflows and slash commands for AI coding agents, covering every phase from writing a spec to shipping to production. It is aimed at developers who already work with an agent such as Claude Code, Cursor, Codex or Antigravity — the GitHub topics name all four — and who want that agent to follow a repeatable process instead of improvising its way through a task. The repository is MIT-licensed, written mostly in JavaScript, and has picked up roughly 97,000 stars and 10,000 forks since it was created in February 2026.
What it does
The problem the project is built around is simple to state: coding agents tend to skip process. They jump straight to code, produce something that runs, and leave the parts a senior engineer would insist on — a written spec, small atomic tasks, tests as proof, a review gate — undone. Agent Skills encodes those habits as skills the agent loads and follows.
The README organises the work as a pipeline: DEFINE, PLAN, BUILD, VERIFY, REVIEW, SHIP. Each stage has a command attached to it, and each command activates the relevant skills automatically rather than asking you to remember which one applies. The video covering the repository puts the count at 25 skills behind 9 commands.
How it works
The nine commands map one-to-one onto the lifecycle, and the README pairs each with the principle it enforces:
/spec— define what to build; spec before code/plan— plan how to build it, in small atomic tasks/build— build incrementally, one slice at a time/test— prove it works; tests are proof/constraints— set the quality bar once and enforce it everywhere/review— review before merge, to improve code health/webperf— audit web performance; measure before you optimise/code-simplify— simplify, favouring clarity over cleverness/ship— ship to production, on the principle that faster is safer
Two of those are worth singling out. /constraints is the one that makes the rest stick: you decide the quality bar a single time, and the later stages hold the agent to it instead of relitigating standards on every task. And /build auto is the low-friction path — once a spec exists, it generates the plan and implements every task in one approval, with each task still tested before it is committed. That last detail matters, because an agent that plans and builds unattended is only safe if the verification step is not the thing being skipped.
Getting started
The natural entry point is /spec, since almost everything downstream assumes a spec exists: /plan reads it, /build works through the plan slice by slice, and /review checks the result against it. If you want to see the value quickly, run /spec on a small, well-bounded feature, then /build auto, and read what comes back — the plan it produces is the clearest signal of whether the process fits how your team already works. Setup details and the full skill list live in the repository README; the excerpt available here documents the commands rather than the installation steps.
When to use it / when not
This is a good fit when you are letting an agent do substantial work on a real codebase and the output has to survive review. The structure pays off most on multi-step features, on shared repositories where code health matters more than speed on any single change, and on teams that want the same standards applied whoever — or whatever — is typing. The web performance and simplification commands suggest a front-end bias in the skill set, which lines up with the repository's JavaScript primary language.
It is less useful if your agent work is throwaway: a one-line fix, a scratch script, a quick exploration you intend to delete. Writing a spec and a plan for those is pure overhead. It also assumes you are using an agent that supports this kind of skill and slash-command loading; if your tool does not, the commands have nothing to hook into. And it is a process layer, not a replacement for judgement — the gates are only as strong as the constraints you set at the start, and someone still has to read the diff before it merges.
Anyone running an AI coding agent on production code should take this repository seriously. It does not add a new model or a new tool; it adds the discipline that agents most reliably lack, and it does so in a form the agent applies on its own rather than one you have to restate in every prompt. The star count reflects a real gap — plenty of teams have discovered that the bottleneck with coding agents is no longer whether they can write the code, but whether the surrounding process holds up. If you already have opinions about how software should be specified, tested and reviewed, this is a compact way to hand those opinions to your agent and have them enforced consistently.