24 public agents from 9 publishers, placed on the delivery lifecycle. These run their own loop — hand one a job and it keeps going without you.
The registry calls everything a skill. That flattens the distinction that matters most when you are deciding what to install. A skill is knowledge the model reads and applies to whatever it was already doing — it loads, it shifts the output, you move on. An agent takes the wheel: it spawns subagents, drives a browser, writes artifacts, and runs a multi-step loop of its own.
That difference is a budget. An agent costs tokens and wall-clock time, and it needs a task actually worth handing over — a test suite to generate, a codebase to audit, a browser flow to exercise. Installing one you never invoke costs you nothing but context; invoking one casually costs real money. The 59 entries on the skills page are the cheap half.
24 agents
Ordered by delivery phase. Anything that spans two phases is listed under both — the phase chips on each card say which.
Plan & specify 2
Turning an intention into something an agent can execute without inventing the requirements as it goes.
Anthropic's own tool for writing a new skill in the format agents actually load.
Reach for it when You have internal knowledge worth encoding and want it to match the house format.
Metaany
npx skills add anthropics/skills
Installs all of skills, not this one alone.
Installing
Same CLI as skills — there is no separate agent installer, because the registry does not distinguish them. The split on this site is ours:
terminal
$npx skills add obra/superpowers
!
An agent you install is an agent your model can invoke. The unit is the repository, so one command can add several autonomous loops at once. That is fine — they only cost you when something calls them — but it is worth knowing what arrived. Read the entry before you hand it a job, not after.
Before you hand one a job
Agents fail differently from skills. A skill that misses the mark leaves you with a slightly worse diff; an agent that misses the mark can spend twenty minutes and a lot of tokens producing confident, wrong work. Three things worth doing every time:
Give it a task with a checkable result. “Write tests for this module” has an obvious pass/fail. “Improve the architecture” does not, and you will not know when it is done.
Run it where you can throw the result away. A branch or a worktree, never a dirty main checkout.
Read what it wrote before you read its summary. The summary is the agent's own account of its work, and it is the least reliable artifact it produced.
What this page is not
ℹ
Nothing on this page is ours. Redline does not vendor, fork, host or modify any of these. Each entry links to the publisher's repository, and the install command pulls from them directly. If a publisher changes an agent, you get their change — this is a map, not a mirror.
The skill/agent split is a judgement we made, not a field the registry publishes. An entry is an agent here if it runs a multi-step loop of its own rather than informing one you are already running. Reasonable people would draw a couple of these differently.
Where this stops
An agent writing code is still code arriving in a pull request, and nothing on this page reviews it. That is the half Redline does — see the output contract and the merge gate. The more autonomous the thing writing the diff, the more the gate is the only thing standing between it and main.