Claude Code Projects Index, a catalogue of agent workspaces rather than code templates

An index of repositories, not a repository of code

Claude-Code-Projects-Index is described as a curated collection of Claude Code projects, agent workspace blueprints and related resources, organized by use case, and the README adds an important note that most of the patterns adapt to other agentic AI command line tools and frameworks.

The repository itself is an Astro site. The package.json is minimal, with astro and the sitemap integration as the only dependencies, and the scripts show how the site is assembled: a Python script builds the data, astro build produces the site, and a second Python script checks the links. The build runs all three in sequence:

  "scripts": {
    "build": "npm run build:data && npm run build:site && npm run check:links",
    "dev": "astro dev",

So the repository you are reading is a catalogue with a website on top of it, and the interesting content is the list of links and the explanatory notes, not the code. The site is published at claude.danielrosehill.com, with a documentation portal at docs.bydanielrosehill.com, and the index links out to a Plugins Marketplace repository, a notes file on templates and workspaces, and a page explaining what Claude Spaces are.

The home page is the online version of the README, and the README itself is the full table of contents, grouped into workspaces by domain, configuration and tooling, extensions and scaffolds, and miscellaneous.

The workspace pattern: a repository as an environment

The conceptual core is stated in the About This Index section, and it is the part worth taking seriously.

The author describes using Claude Code daily for about six months, for development but also audio editing, legal research, SEO analysis, health documentation and systems administration, and calls the index the result. The common thread is treating Claude Code less as a coding assistant and more as a general-purpose agent workspace that happens to run in a terminal.

The pattern behind it is that a Git repository need not be only for code. It can serve as a complete, self-contained workspace for any activity, and each workspace uses a defined folder structure, a CLAUDE.md for agent instructions, slash commands, MCP configurations and subagent definitions to create a purpose-built environment.

The index applies badges to make the taxonomy explicit. An Agent Workspace is a pre-configured repo using Claude as a conversational interface for a domain-specific workflow. A Template is a forkable starting point you can customise. And a Non-Code entry is an application beyond software development.

The domain list shows how far the idea has been pushed: systems administration, productivity and planning, legal, health and wellbeing, communications and writing, financial planning, career, business, privacy and anonymity, technology and hardware, marketing, research, and a section on argument and perspective exploration. There is also a separate sysadmin sub-index, and the entries in it are recognisable, such as a bash alias manager workspace with YADM synchronisation support, a collection of bash aliases for common Claude Code operations on Linux, a GUI concept for Claude-driven LAN management covering device discovery and network operations, and a planning workspace for managing a Linux desktop through a refine, analyse and workflow pipeline.

Plugins over templates: primitives once, scaffolds on demand

The author has since consolidated the approach, and the change is worth understanding before you fork anything.

The tooling is now consolidated into 28 cluster plugins, each shipping the domain primitives, meaning commands, skills and agents for its cluster, and provisioning a project scaffold on demand. The stated consequence is that rather than forking a separate template repo for each new workflow, you install the relevant cluster plugin once and ask Claude Code to provision a scaffold wherever you need one.

That is a different maintenance model from a template gallery. A template repository is a fork, and forks drift, and every workflow you adopt is a separate copy to keep in sync. A plugin is an installation, so the primitives live in one place and the per-project artifact is generated. The plugin set is described as covering workflows across sysadmin, research, media, writing, planning and more, and it lives in its own repository, the Claude Code Plugins marketplace.

Under the extensions section of the contents, templates and scaffolds are marked as the recommended way to spin up a new workspace, with plugins, slash commands and MCP listed alongside. The index still keeps the older per-workflow template repositories, so the catalogue is a mix of both generations, and the plugin route is the one the author points you at.

Running the site locally, and what the scripts actually do

Working on the index itself is a small job, since it is a static Astro site with a Python data step.

The three scripts are the whole build. `build:data` runs python3 scripts/build_site.py, `build:site` runs astro build, and `check:links` runs python3 scripts/check_links.py, with the build script running them in that order. The link check as a mandatory build step is the notable choice, since an index of this kind is mostly links, and a stale one is worse than a short one.

For local development, `npm run dev` runs astro dev, and `npm run preview` serves the built site. The repository layout matches the script names, with scripts/ holding the two Python files, data/ holding the source data, categories/ the grouping, src/ the Astro pages and components, public/ the static assets, charts/ the generated chart images and images/ the rest of the artwork.

There is also a vercel.json at the root, which tells you the site is deployed on Vercel, and a .claude/ directory alongside a CLAUDE.md at the root, so the index follows its own pattern and documents itself to an agent in the same way the workspaces it catalogues do.

A personal collection, and what that means for reuse

The README addresses the obvious question directly. It records that the author is a real human, with a link to their personal site, and that the repos and workspaces in the index are generated with Claude Code but human-designed and refined. The praise quoted in the index comes from the awesome-claude-code list, which describes it as an index of 75 or more Claude Code repositories, and the author notes the joke about whether the work is by a prolific genius or a very clever bot before pointing to the human-design claim.

That honesty is the key thing to weigh. This is a curated personal collection with an explanation of the pattern behind it, not a maintained framework with a compatibility policy. The repository publishes no GitHub releases, the licence field is one GitHub cannot classify, and the entries point to separate repositories, each with its own state.

So the durable value is the structure and the vocabulary, not the links. The badge taxonomy of agent workspace, template and non-code is a useful way to think about what a Claude Code setup can be, the workspace pattern section describes the moving parts in enough detail to build your own, and the two linked notes files on templates and workspaces and on what agent workspaces are are the deeper explanation.

The site is also the best example of the thing it indexes, since the repository itself carries a CLAUDE.md and a.claude/ directory, and the last push to main was on 2026-10-22.

Editorial conclusion

Adopt the patterns in this index if you are setting up a Claude Code workspace for a non-coding task and want a concrete folder structure, a CLAUDE.md and a set of slash commands to copy rather than design yourself. Do not adopt it as a software dependency, because it is a personal catalogue and an Astro documentation site, with no published releases and no installable package, and the individual repositories it points to are the actual projects. Before you start, read the notes on templates and workspaces and the explanation of agent workspaces, and check the plugin marketplace entry, since the author now recommends installing a cluster plugin once and provisioning scaffolds from it instead of forking a separate template per workflow.

Frequently asked questions

Official sources

1. danielrosehill/Claude-Code-Projects-Index on GitHub
2. Issues
3. Project website
4. README