Twenty-two sections turn a noisy ecosystem into a usable shortlist
The 56-file repository divides the ecosystem into 22 top-level sections, including official material, learning resources, runtime infrastructure, alternative clients, status lines, security, orchestration, skills, memory, observability, testing, and linting. Each entry gets a short editorial description. GitHub projects also carry generated badges for age, recent activity, license detection, and stars. That structure is the main product: you arrive with a job in mind and leave with a few named projects to inspect.
Selection starts at 14 days of activity or 100 stars
A submitted project must be at least 14 days old with commits after its first day, or it must have 100 stars. That rule removes same-day promotional shells without turning stars into the only test. The maintainer still decides what belongs, and the contribution guide says the directory is selective. Closed-source or signup-only products face more scrutiny because their claims are harder to inspect.
Recommendations must contain 1 resource and come through GitHub's web issue form. The guide forbids pull requests for submissions, says the gh CLI route does not work, and requires a human to file the recommendation. A bot checks the form and license discovery, but it does not judge quality. There is no promised reply or decision date, which matters if inclusion is part of somebody's launch plan.
What happened when we ran it
Our sandbox installed commit bafb8ff in 26 seconds, pulling 51 Python packages and occupying 130 MB. The build completed in 6 seconds. Pytest ran 112 tests in 13 seconds and every test passed. Pip-audit reported 0 known vulnerabilities in the installed dependency set. Those are clean results for the code that turns the resource table and configuration into the public README.
The checkout held 56 files, about 4,616 source lines, and 3.4 MB before installation. We found 5 CI workflow files and a tests directory, but no Dockerfile. Readers never need this environment. Maintainers and contributors use it to validate submissions, regenerate the list, update category choices, and produce the ticker and recently added graphics. A separate ticker task needs a GitHub token because it fetches live repository data.
Our test method used a fresh Debian container with 3 CPUs, 8 GB of RAM, no secrets, and no elevated privileges. The successful 112-test run proves that the repository's Python maintenance code passed there. It says nothing about whether a listed plugin asks for broad permissions, whether a skill contains unsafe instructions, or whether a linked service still behaves as described.
Passing 112 tests does not approve the linked projects
All 112 tests cover the repo's own publishing system, while the security policy explicitly leaves third-party investigation to each linked project's maintainers. Awesome Claude Code welcomes reports about unsafe entries, but it does not claim to audit or enforce the security of every skill, MCP server, shell script, desktop app, or hosted service. Inclusion is an editorial signal, not a security certificate.
That boundary should shape how you use the list. Open a candidate's repository, read its install script, check what files and commands it can reach, and look at current issue activity before giving it your source tree or credentials. For skills, read the instructions as carefully as executable code because they direct an agent's actions. The directory saves discovery time. Your own review still decides whether the project enters a work machine.
The 56-file repository carries a frozen archive
The 56-file checkout includes README_ALTERNATIVES, a preserved version of the older list that the README says will not be updated. The current edition deliberately launched with different resources, and maintained legacy entries are being returned gradually. Absence from the main page can therefore mean migration status rather than rejection. Anyone comparing a crowded category should search both the current README and the archive.
This transition weakens completeness. A newer entry can sit on the main page while an older, maintained tool remains in the frozen directory. The remedy is simple but manual: use both lists to make a candidate set, then compare upstream push dates, issues, releases, and licenses. The catalog is strongest as an edited starting point, not as a historical record of every Claude Code project.
CC BY-NC-ND 4.0 permits sharing, not a commercial fork
Awesome Claude Code uses Creative Commons Attribution-NonCommercial-NoDerivatives 4.0. You can share the list under those terms, but you cannot turn it into a modified commercial catalog without separate permission. GitHub's API did not identify a standard SPDX software license, while the license file states the Creative Commons terms plainly and invites prospective derivative projects to contact the maintainer.
Every linked project retains its own license. A permissive license on one skill does not change the directory's reuse terms, and the directory license grants no rights to the code behind its links. A company building an internal approved catalog should record each upstream license and its own security findings rather than copying this dataset and assuming one policy covers the collection.
An October 1 push is current, while 1,197 issues await attention
GitHub showed 54,868 stars, 4,778 forks, and 1,197 open issues on October 1, 2026. The repository was pushed that same day, and the newest issues were fresh resource recommendations. There were 0 open pull requests because submissions intentionally go through issues. Current code activity and same-day intake show that the project is maintained. The four-digit queue shows how much demand one editorial process must absorb.
The latest-release endpoint returned no release. That is a poor abandonment test for a generated directory because readers consume the main branch, not binaries. Fresh pushes and issue handling matter more here. Bookmark Awesome Claude Code if you already use Claude Code, but keep the final gate on your side: browse the list, shortlist a project, inspect its source, and test it with the least access it needs.