Skills

A skill is a folder of instructions that an agent loads when it decides the instructions are relevant. That is the whole idea. The interesting part is that it lets you install a workflow rather than describe one: instead of typing “write the test first, then the implementation” into every session, you install a skill that makes the agent do it without being asked.

Skills usually arrive bundled as a plugin, which is a package that can also carry slash commands, subagents, hooks, and MCP servers. In practice you install plugins and get skills.

The list below is short on purpose. Every skill you install competes for the agent’s attention, and a machine with fifty half-relevant skills is worse than one with five good ones. Install these when you hit the problem each one solves, not all at once on day one.

superpowers

github.com/obra/superpowers

What it does. Teaches the agent a development methodology rather than a trick. The headline skills are brainstorming (interrogate what you actually want before any code exists), writing-plans (turn that into a written plan), test-driven-development (red, green, refactor, enforced), systematic-debugging (find the root cause before proposing a fix), and subagent-driven-development (farm independent tasks out to subagents with code review built in). There are also skills for requesting and receiving code review, verifying work before claiming it is done, and authoring new skills of your own.

Why it earns its place. It is the single highest-leverage install on this page, because it attacks the failure mode that costs you the most: an agent that starts typing code thirty seconds after a vague request. The brainstorming and writing-plans skills front-load the conversation you were going to have anyway, except now it happens before the diff exists instead of after. And verification-before-completion is a direct answer to “tests pass” claims that turn out to mean “I did not run them”.

Install.

/plugin install superpowers@claude-plugins-official

beads

github.com/gastownhall/beads

What it does. A git-backed issue tracker that lives inside your repo and is designed to be read and written by agents. Issues are files under version control, so they branch, merge, and travel with the code. The CLI is bd. An agent can ask what work is ready, pick something up, close it, and record decisions, all without you opening a browser tab.

Why it earns its place. Agent sessions forget. Repos do not. Once work lives in beads, “what was I doing” survives a context compaction, a closed terminal, and a machine reboot, and a fresh agent can answer it by running bd ready instead of asking you. It also gives you somewhere to put the out-of-scope work an agent surfaces mid-task, so you can capture it and move on rather than derailing the thing you were doing.

Install.

brew install beads

Then, from inside a repo:

bd init
bd setup claude

bd init creates the issue database and updates AGENTS.md so agents discover the workflow. bd setup claude installs the Claude Code hooks that prime the agent with your ready work at the start of each session.

gstack

github.com/garrytan/gstack

What it does. A large, opinionated suite of slash commands that stand in for the roles around an engineer: /plan-ceo-review, /plan-eng-review and /plan-design-review critique a plan from three different chairs before you build it; /qa and /design-review test a running site and fix what they find; /investigate does root-cause debugging; /ship, /land-and-deploy and /canary cover the release path; and /careful, /freeze and /guard add safety rails around destructive commands and stray edits.

Why it earns its place. It is the review layer. Where superpowers improves how a single task gets done, gstack is what you run to have the work looked at by something with a different set of priorities than the agent that wrote it. The design and QA skills in particular catch the class of problem you would otherwise only find by opening the site yourself: spacing that drifted, a hierarchy that stopped making sense, an interaction that got slow.

Install. It installs into your skills directory rather than through a marketplace:

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack \
  && cd ~/.claude/skills/gstack \
  && ./setup

It expects Claude Code, git, and Bun v1.0 or newer.

This one is big

gstack installs a lot of commands at once, which is the opposite of the “install what you need” advice above. It is worth it, but give it a session or two of using two or three commands before you try to hold the whole menu in your head.

last30days

github.com/mvanhorn/last30days-skill

What it does. Research on what people have actually been saying about a topic in the last month. It pulls posts and engagement from Reddit, X, YouTube, Hacker News, TikTok, GitHub, Polymarket and the open web, then ranks by real signals (upvotes, likes, money at stake) rather than by whatever an SEO page decided to publish.

Why it earns its place. It answers a question search engines are bad at: “is this library actually good, or does everyone quietly hate it?” Model training data is stale by definition and blog posts are written by people with something to sell. Sentiment from the last thirty days is a different input, and it is the right one for “should we adopt this”, “did that release break everyone”, and “what is the current consensus workaround”.

Install.

/plugin marketplace add mvanhorn/last30days-skill
/plugin install last30days@last30days-skill

The research stack

Two habits matter more than any single research skill.

The first is that your agent should be allowed to search the web. An agent working from training data alone will confidently write against an API that changed nine months ago, and it will not flag the uncertainty, because from the inside stale memory feels exactly like knowledge.

The second is a docs lookup path, so that “what is the current signature of this function” gets answered from the library’s actual documentation rather than from recall. Context7 is the usual choice: it indexes up-to-date, version-specific docs for a large set of libraries and serves them into the agent’s context on request. Register it as an MCP server:

claude mcp add --transport http context7 https://mcp.context7.com/mcp

A free API key from context7.com raises the rate limits, and is passed as a CONTEXT7_API_KEY header.

Then add a line to your CLAUDE.md so the agent reaches for it without being told:

Always use Context7 for library and API documentation, code generation, and
setup or configuration steps. Do not answer from memory.

Why this pairing matters

Search and docs lookup solve different halves of the same problem. Docs tell you what the API is; search tells you what happens when people use it. An agent with neither is writing plausible code against remembered APIs, which is the most expensive kind of wrong: it compiles, it reads fine in review, and it fails at runtime.

Installing skills and plugins generally

Most plugins come from a marketplace, which is just a git repo containing a catalogue. Claude Code registers Anthropic’s curated marketplace, claude-plugins-official, automatically. To browse and install interactively, run:

/plugin

To add a third-party marketplace and install from it, the flow is two commands:

/plugin marketplace add <owner>/<repo>
/plugin install <plugin-name>@<marketplace-name>

There is also a public community marketplace, which you add the same way:

/plugin marketplace add anthropics/claude-plugins-community

For skills you write yourself, the shortest path is your own skills directory. Running claude plugin init <name> scaffolds ~/.claude/skills/<name>/ with a manifest and a starter SKILL.md, and it loads on the next session with no marketplace and no install step. Anything you drop under ~/.claude/skills/ is personal to your machine and available in every project, which makes it the right home for the small workflow skills that are specific to how you work. Project specific skills live in the repo instead, under .claude/skills/, where your collaborators get them too.

The current reference for all of this is Anthropic’s documentation on plugins, plugin marketplaces, and skills.

Read what you install

A plugin can ship hooks and MCP servers, not just instructions, which means installing one is closer to running someone’s shell script than to reading their blog post. Everything on this page is widely used and open source, but the general rule holds: look at the repo before you install it, and be more careful with a plugin you found through a link than with one from a marketplace that reviews submissions.