Awesome Claude Code: What It Lists and How to Use It

Awesome Claude Code is a hand-picked GitHub list of resources for Claude Code: skills, subagents, plugins, hooks, status lines, orchestration tools, guides and more. It is maintained by one person, hesreallyhim, with no affiliation to Anthropic. It is curated, not audited, so read what you install. We read the README and contributing guide on 31 October 2026.

Quick facts

What the list is

It is a table of contents over a very large ecosystem. The README opens with a ticker of featured projects and a "Recently Added" strip, then a table of contents. Each entry is one line: the name, the author, and a plain description of what it does.

The maintainer says the current iteration was launched to highlight resources that were not on the previous list, and that earlier entries will be re-incorporated at a reasonable cadence. If something you remember is missing, that is the reason the contributing guide gives.

The sections

The headings below are straight from the README.

Where we would start

We are not going to rank hundreds of third-party projects we have not run. Here is a route through the list that follows its structure.

1. From Anthropic

This section is the safest start because the authors are the vendor. The list points to:

• Agent Skills, Anthropic's repository for the SKILL.md format, a template and examples. See our skills guide.
• The official plugin directory, a curated set of Claude Code plugins you install inside Claude Code. See our plugins guide.
• Claude Code GitHub Action, to run Claude Code in CI by mentioning it in issues and pull requests.
• Claude Code Security Review, an official action that checks pull request diffs for vulnerabilities.
• Best practices, How Claude Code Works, and the cheatsheet, which are Anthropic's own docs. Compare with our cheat sheet.
• Engineering essays on building effective agents and context engineering.

2. Start Here

Guides and essays. The entries described in the list include a single-page Claude Code reference kept in sync with the official changelog, a hooks walkthrough with copy-ready settings.json examples, a chapter-based getting-started guide with a self-assessment quiz, an interactive click-through of an annotated Claude Code project and an essay on writing a good CLAUDE.md. Read one or two. They are free and quick.

3. Skills

The list is large here. Examples named in the README include a drop-in CLAUDE.md of behavioural guidelines, a bundle for software engineering covering planning, reviewing, testing and debugging (Superpowers), SEO skill packs, LinkedIn marketing skills and board-specific skills for microcontroller firmware. Pick by job, not by popularity, and cross-check with the skills install guide.

4. Memory and context

Tools for notes and retrieval across sessions, including a local index of your coding-agent history across Claude Code, Codex, Cursor and Gemini, a privacy-focused context layer and a plugin that tracks token usage. Useful if you run long projects. Mind where your session data gets stored.

5. Agent orchestration

Spec-driven workflows, multi-agent managers and plugin suites for task-to-production automation. This is the section that grows fastest. Use subagents and commands first, and reach for a framework when you can name the gap.

6. Configuration

Entries like Rulesync, which generates rules, ignore files, MCP servers, commands and subagents for several AI coding tools from one source. Handy if your team uses more than one agent.

How the list is curated

From the contributing guide:

• Entry rule. A recommended resource must either be at least 14 days old, counted from its first commit on the default branch, with signs of active development including commits after day one; or have at least 100 stars. Resources that fail are closed automatically.
• One at a time. You may not recommend more than one resource at a time.
• Web form only. Recommendations must use the issue form template. Pull requests are not used, and it is not possible to submit with the gh CLI. The bot that validates the form checks it mechanically and does not review quality.
• Human submissions. The resource itself may be written partly or fully by a coding agent, but the recommendation must be made by a person.
• Open source preferred. The list is not exclusively open source, but closed source is a barrier to review, and anything needing signup or payment is a blocker, per the guide.
• Style. Descriptions should describe, not sell. One line, no emoji, no addressing the reader.
• Selective by design. The maintainer writes that the point of an awesome list is to be selective, and that there is no formal submission and review process beyond this.

This is useful to know. The list's bar is "real and used", not "audited". The maintainer reads and recommends, but does not perform a security review of each entry.

How to vet an entry before you install it

A line on a list is a starting point. Before you add anything to your setup:

1. Open the repo. Check the last commit date, open issues and whether anyone besides the author contributes.
2. Read the licence. No licence means all rights reserved by default.
3. Read the files that run. For plugins, that is plugin.json, hooks/, .mcp.json and any bin/ folder. For skills, SKILL.md plus scripts/. Anthropic's plugin security page states that a plugin can run arbitrary code on your machine with your user privileges.
4. Check tool grants. allowed-tools in a skill or tools in a subagent decides how many permission prompts you skip.
5. Check network behaviour. Does it call a service? Does it phone home? A status line or monitor that sends your usage somewhere is a privacy choice.
6. Install in a scratch repo first. Our templates guide has a safe first-install loop.
7. Pin it. Copy a commit, not a moving branch, and note where it came from.
8. Leave auto-update off for third-party marketplaces.

Reading an entry

Every entry has the same shape: a linked name, a byline, a dash and one description. Under many entries the list shows small badges for when the repository was created and when it last had a commit. Those two badges are worth more than the description. A repository created last month with a commit yesterday is a different bet from one created last year and untouched since.

Look for these signals:

• Verbs in the description. "Generates", "reviews", "tracks" tell you what it does. Vague words such as "powerful" are the author's, not the maintainer's, so skim past them.
• Who it talks to. Anything described as a service, a gateway or a remote control has a network side. Anything described as a skill or a prompt is mostly text.
• What it touches. Status lines read your session. Memory tools write your notes. Orchestrators spawn agents and spend tokens. Each has a different risk.
• Overlap with built-ins. Claude Code adds features often. A tool that fixed a gap last year may now be a built-in command. Check the commands guide and cheat sheet first.

Keeping up without drowning

The list changes often, with a "Recently Added" strip at the top and a ticker of featured projects. You do not need to follow every change.

1. Watch the repository's releases or star it, and look once a month.
2. Keep a short note of what you tried, what you kept, and why.
3. When a section you care about grows, read only the new lines.
4. Prefer a tool that solves a problem you have written down. If you cannot name the problem, skip it.
5. Re-check anything you installed from the list when Claude Code ships a big release, since extension points move.

A one-hour first pass

A list this long is easy to read for an hour and install nothing useful. Spend the hour on a plan.

1. Write down three annoyances from your last week with Claude Code. "It forgets my test command", "I retype the same review prompt", "I cannot see my usage".
2. Match each to a section. Memory and context for the first, skills or commands for the second, status lines for the third.
3. Read only those sections, and open at most two entries per annoyance.
4. Run the vetting steps above on each one. Drop any entry whose last commit is old or whose files you cannot read in ten minutes.
5. Install one thing in a scratch repository, use it for a day, and write one line on whether it solved the annoyance.

If an entry does not fix a problem you wrote down, it is entertainment, and that is fine, but keep it out of your daily setup. Most of the harm from community extensions comes from installing many at once and not knowing which one changed a behaviour.

A scoring sheet for any entry

Score an entry from 0 to 2 on each row before you keep it. These are our criteria, not the maintainer's.

Keep anything scoring 9 or more out of 12, and look hard at anything with a zero in the network or readability rows. The sheet takes five minutes and prevents most of the regret.

When an entry you use goes stale

Community tools are maintained by volunteers, and attention moves on. Plan for that from the start.

• Note the commit you installed, so you know what version you are running if the repository changes.
• Watch for the signs. Unanswered issues, a Claude Code release that breaks it, or a repository archived by its owner.
• Keep the substance local. If a skill or command is mostly text, copy it into your own repository and edit it. Then an upstream change cannot break you, and you can see exactly what it tells the agent.
• Have an exit. For each installed item, know how to remove it and what it changed in your settings, such as hooks and permissions.
• Replace, do not accumulate. When you adopt a better tool for a job, remove the old one the same day.

A short written inventory, kept next to your CLAUDE.md, with the source, commit and purpose of each extension, is the cheapest maintenance system we know. It also makes onboarding a teammate a ten-minute job.

What it does not do

• It is not a ranking. Order inside a section is the maintainer's, not a score.
• It is not a security audit. Entries can change after they are listed.
• It is not complete. The README says earlier resources return over time.
• It is not a package manager. Installation is up to each project.
• It is not Anthropic's. The title page says no affiliation.

For a package-manager-like experience, Claude Code's own plugin system and the Claude Code Templates CLI install items for you, with the caveats we describe on those pages.

Alternatives to the list

Our take

We read the list and the contributing guide. We did not test the entries, and we do not endorse them.

The best thing about it is the structure. Sections that match how people actually work, a one-line description per entry, and a clear rule for getting in. The 14 days or 100 stars rule keeps out the weekend experiments that have not proven they will be maintained.

Its limit is the one all awesome lists share. The rule says a project exists and has been looked at, not that it is safe, tested or right for your stack. A skill with a thousand stars can still be a poor fit, and a plugin that was fine last month can change.

How we would use it: spend ten minutes in "From Anthropic" and "Start Here", pick one idea you will try this week, vet it with the steps above and put it in a scratch repo. Then come back next month. A list like this rewards short, regular visits more than a long read.

Frequently asked questions

What is Awesome Claude Code? A hand-picked GitHub list of Claude Code resources, maintained by hesreallyhim with no Anthropic affiliation.

How are entries chosen? 14 days old with active development, or 100+ stars, submitted through a web form.

Is everything on it safe to install? No. Curated is not audited.

How do I submit a resource? The issue form in the repo. Not by pull request.

Is it only for Claude Code? It focuses on Claude Code, and many entries work with other agents.

*Product names are used descriptively. We are not affiliated with Anthropic or the list's maintainer.*