The directory groups Claude Code resources by the job they do
Awesome Claude Code is a long, edited directory rather than a tool you run. Its sections cover official material, learning guides, runtime infrastructure, remote control, alternative clients, status lines, security, orchestration, skills, memory, observability, and linting. Each entry links to its source and carries a short description. GitHub projects also receive generated badges for creation date, recent activity, license detection, and stars.
That organization is useful because Claude Code customization now spans several file types and integration points. A new user can begin with official guidance, while an experienced user can jump directly to a session monitor or memory layer. The descriptions often state implementation details such as operating system, runtime, storage, or whether data stays local. They are editorial summaries, so verify those facts against the linked project before installing anything.
Selection starts at 14 days of activity or 100 stars
The contribution policy has a mechanical floor. A submitted resource must be at least 14 days old with development beyond its first day, or have at least 100 stars. Submissions are limited to one resource at a time and must use the GitHub web issue form. The guide says the gh command-line client cannot submit the recommendation, and a bot validates the form rather than judging quality.
Passing that gate does not guarantee inclusion. The maintainer calls review best effort, gives no response promise, and says the directory must remain selective. Paid or signup-only products face a higher bar because they are harder to inspect and need community adoption signals. The guide also prefers projects that use Claude Code's distinct capabilities, even though interoperability with other agents is allowed. That is a coherent editorial position, not an objective ranking of the entire agent-tool market.
What happened when we ran it
Our sandbox installed 51 Python packages in 45 seconds from commit bfe0f0f, occupying 128 MB. The build completed in 9 seconds. Pytest then ran 90 tests in 10 seconds and every one passed. Pip-audit reported zero known vulnerabilities in the installed dependency set. The 3.3 MB repository contained 56 files and about 4,313 lines of source.
We also found five CI workflow files, a tests directory, and no Dockerfile. Those numbers describe the scripts that validate submissions, generate the README, and maintain repository assets. A reader does not need that environment because the finished product is the rendered list. A contributor working on generation can reproduce a small, passing Python setup without deploying a service or obtaining an API credential.
The clean result should not be stretched beyond the repository. It does not mean every linked skill, plugin, MCP server, shell script, desktop app, or hosted service passed the same 90 tests. The security policy says the project does not enforce or investigate third-party security and asks people to report vulnerabilities to each resource's own maintainers. Treat inclusion as a useful editorial signal, rather than a security review.
The current list intentionally omits older entries
The README explains that this iteration launched with resources that did not overlap the previous list. Older entries are being returned gradually, while a README_ALTERNATIVES directory preserves the legacy selection without updates. That means absence can reflect the migration rather than a negative editorial judgment. It also means the current page is not a complete historical map.
This temporary split matters when comparing projects. A maintained older tool may sit in the frozen archive while a recent submission appears in the main list. Search both locations if you are surveying a category, then check each upstream repository's last push, release history, issues, and license. The directory helps build a shortlist; it cannot replace side-by-side testing of the candidates in your environment.
The reuse license is narrower than the public GitHub page suggests
The repository's license file applies Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 to Awesome Claude Code. GitHub's repository API returned no asserted SPDX license, which fits a license text outside the common software-license set. You can read and share the directory under its terms, but modifying it into a commercial catalog or derivative dataset is restricted. The maintainer invites people with a modified-use project to make contact.
Individual linked projects keep their own licenses. A permissive license on a listed skill does not change the directory's terms, and the directory's license does not grant rights to third-party code. Teams creating an internal approved catalog should gather upstream licenses and security evidence directly instead of copying the full list and assuming one license covers everything. This is especially important for entries that require signup or remain closed source.
Same-day submissions show activity without a release stream
GitHub recorded a push on August 27, 2026. The project had 53,043 stars and 934 combined issues and pull requests when fetched. Many recently updated issues were resource submissions carrying validation-passed, while some were still pending or lacked that label. The latest-release endpoint returned no release, so there is no current tag to cite. That absence is not evidence of inactivity because the README and submission queue changed the same day.
A link directory does not need binary releases to serve readers. Its freshness depends on ongoing edits, dead-link cleanup, honest descriptions, and removal or qualification of unsafe projects. The active queue proves demand and creates a burden: 934 combined items can outpace one maintainer's best-effort review. Users should value the curation while retaining their own acceptance checklist.
Awesome Claude Code is worth bookmarking if Claude Code is already part of your work. It is unusually structured for an awesome list, and our 90-test pass gives confidence in the repository's generator. The right workflow is browse, shortlist, inspect upstream, then test with limited permissions. Anyone building a commercial index or expecting verified software should choose a source with compatible reuse terms and an explicit audit process.