A Claude Code starter kit: one developer's tuned setup, codified so you can pick it up and get the same experience in your own repo. It ships three things — a CLAUDE.md template backed by a rules pack, a first-run interview that installs the toolchain and fills in the blanks, and a researched catalog of the skill and agent packs worth installing. A fourth keeps the other three from rotting: everything vendored or catalogued here records where it came from, and one command says what has moved upstream since.
Nothing here is machine-specific. Clone it, answer the setup questions, and the template becomes your project's.
- Clone or copy this repo.
- Open Claude Code in it. The
TODO(bootstrap)markers in CLAUDE.md trigger the first-run interview in docs/SETUP.md, which asks whether you are solo or a team, what you build with, and what tooling you want, then builds a costed install plan for your approval. - Install the packs you picked. Start from the catalog.
Setup ends by deleting the TODO(bootstrap) markers. After that, sessions
start normally.
| Path | What it holds |
|---|---|
| CLAUDE.md | The template's root instructions: map, commands, non-negotiables, routing table |
| docs/rules/ | The rules pack CLAUDE.md loads on demand — one file per domain |
| docs/SETUP.md | The first-run interview |
| docs/process/ | Lifecycle and tool-stack research: solo vs team, stacked PRs vs trunk, laptop vs server, five costed solo stacks and four team ones |
| docs/frameworks/ | The skill catalog: one file per upstream pack, plus the skills no pack file carries |
| docs/dev-tooling/ | The tools shelf: things you install, including CLI apps, MCP servers, language helpers, and the framework packs whose skills are catalogued above |
| docs/agents/ | Subagent rosters, per pack and deduplicated |
| docs/architecture/, docs/DESIGN.md, docs/STRATEGY.md | Project docs the setup interview fills in |
| .claude/ | Shipped agents, skills, hooks, and settings, plus agent-library/: 33 more agents parked, not loaded |
| .github/ | The gate workflow, the docs-watchdog workflow, the weekly upstream check, and the CODEOWNERS that keeps an agent off them |
| tools/gate.mjs | The gate: every doc path resolves, credentials stay ignored, provenance is recorded, hooks self-check |
| tools/docs-check.mjs, tools/verify-claims.mjs | The watchdog: counts and links measured off disk, and the gate that discards any reviewer finding it cannot reproduce |
| tools/sources.json, tools/skills-update.mjs | Where each vendored skill and pack catalog came from, and what has moved since |
CLAUDE.md stays short and routes to docs/rules/, which is loaded per situation rather than all at once: scope and architecture decisions (PRINCIPLES.md), writing code (CODING.md), tests and evals (TESTING.md), tickets and shipping (WORKFLOW.md), service boundaries (SERVICES.md), subagents and model choice (DELEGATION.md), act-vs-ask (AUTONOMY.md), destructive operations (SAFETY.md), and prose (VOICE.md). Windows setups fold WINDOWS.md into CLAUDE.md directly.
Precedence when they conflict: safety first, then finishing the whole task, then the smallest diff that covers it.
docs/frameworks/ is the catalog — one file per upstream pack, each organized by workflow stage: Product Process, Development Process, Code Architecture, Dev Tooling, Scaffolding and Harness, and Built-in Claude Code. Skills whose source has no pack file, or that their pack file does not list, live in NON-PACK-SKILLS.md. Every individual skill appears in exactly one file here, with no duplication between them.
docs/dev-tooling/ is the other shelf: CLI apps, MCP servers, language helpers, and framework packs, catalogued as things you install rather than as skills you invoke.
A framework pack is a group of skills installed as a unit, so it is listed in both places on purpose: on the tools shelf as the thing you install, and in docs/frameworks/ as the skills it brings. That is not duplication, and it is not a defect to report. The one-file rule is about individual skills, never about the packs that carry them.
| Pack | Upstream | What it is |
|---|---|---|
| ECC | affaan-m/ECC | The broadest general-purpose pack, and the largest agent roster here |
| Han | TheBushidoCollective/han | A marketplace of 161 plugins across 11 categories; discipline personas per engineering domain |
| GSD | open-gsd/gsd-core | Planning-artifact pipeline: every skill paired with a /gsd:* command and an agent that writes a named doc |
| gstack | garrytan/gstack | The browse, QA, review and ship spine this template's workflow assumes |
| Trail of Bits | trailofbits/skills | Security audit pipelines: multi-stage worker and judge clusters for C, Rust, and zeroization |
| CodeMySpec | Code-My-Spec/plugins | Spec-driven development for Phoenix/Elixir, spec through QA |
| Beagle | existential-birds/beagle | 11 plugins spanning planning to review. Skills only |
| Claude MPM | bobmatnyc/claude-mpm-skills | Skills for the Claude MPM multi-agent orchestration framework |
| rsc-harness | ericrisco/rsc-harness | Harness and operations skills. Skills only |
| Mindrally | Mindrally/skills | Converted Cursor rules, in bulk |
| Ruflo | ruvnet/ruflo | An agent meta-harness: skills for building agents, plus domain verticals |
| zcaceres | zcaceres/skills | General utilities plus hook-based safety guards (dotenv, rm -rf, git reset) |
| Matt Pocock | mattpocock/skills | TypeScript-focused. Skills only |
| Superpowers | obra/superpowers | Development-loop skills plus one SessionStart hook |
| Codex Skills Alternative | DKeken/codex-skills-alternative | Vendor-neutral reimplementation of the Codex-only Creative Production and Product Design plugins |
| Taste | Leonxlnx/taste-skill | Design taste and judgment. Experimental |
| Unlazy | Leonxlnx/unlazy | One skill plus a Stop hook enforcing gate ledgers |
| PM Claude Brief | MariaVimer/pm-claude-brief | Brief-writing discipline for PMs: one skill and 12 CLAUDE.md templates |
| Oldhand | berwinsingh/oldhand | Deliberately minimal: one portable skill |
| zg-skills | zacgoodwin/zg-skills | This repo author's ship-and-review gate: the /stack-ship pipeline and the blinded review it cannot talk past |
Not every skill comes from a pack. NON-PACK-SKILLS.md carries the rest. Where each pack file above has a single upstream, this one draws from many that ship no pack file of their own: Aakash Gupta's PM OS, graphify, the context-engineering set, Anthropic's own plugins, roborev, ponytail, and Claude Code's built-ins.
Each file records the upstream commit it was checked against, so you can tell how stale one is before trusting it, and tools/sources.json carries the same pin in a form a script can compare — see Keeping it current. Five files (ECC, Matt Pocock, rsc-harness, Ruflo, zcaceres) never recorded a commit and now say so outright rather than reading as freshly checked.
Installing is uneven, because upstream is uneven. The marketplace table in docs/SETUP.md covers the packs distributed as Claude Code plugins. Four pack files carry their own command (CodeMySpec, Codex Skills Alternative, Trail of Bits, zcaceres). The rest publish no one-line installer — clone the upstream repo and copy the skills you want.
docs/agents/ is the subagent counterpart to the skill
catalog: five packs ship agents, and
docs/agents/README.md indexes them.
docs/agents/IN-REPO-AGENTS.md is a
deduplicated roster of every agent reachable from one mature machine — an
example of where this ends up, not a description of this repo. Fourteen
agents ship loaded, in .claude/agents/: six business
personas, a seven-agent product review panel, and a TypeScript reviewer.
Another 33 sit parked in .claude/agent-library/
— reviewers, build resolvers, planners, a GAN harness trio — costing
no context until you copy one up into .claude/agents/.
node tools/gate.mjs runs in CI on every push and pull request, and is
cheap enough to wire into a pre-commit hook yourself. It is deterministic,
free, and finishes in under two seconds: every repo path referenced in the
docs must resolve, .claude/credentials.md must stay
gitignored, every vendored skill and pack catalog must carry its provenance,
and the shipped hooks and tools must pass their self-checks. Run
node tools/gate.mjs --self-test to check the gate itself.
The gate can be weakened by editing the workflow that runs it, so two
things watch that surface: zizmor
lints the workflows in their own CI job (unpinned actions, over-broad
token scopes), and .github/CODEOWNERS puts a human
on any diff to .github/, tools/, or .claude/. CODEOWNERS is inert
until you turn on branch protection requiring Code Owner review.
It never touches the network, which is why "what moved upstream" is a separate command rather than a gate test.
The setup interview extends it with your project's own tests.
Upstream moves. tools/sources.json records where every
vendored skill and every pack catalog came from and at which commit, and
node tools/skills-update.mjs check says which of them have moved since —
over git ls-remote, so it needs no token and no API quota. The gate holds
the manifest honest offline: a skill vendored with no recorded source, or a
pack header whose pin disagrees with the manifest, fails it.
check reports a state per entry, and two of them are deliberately not
verdicts. moved means the upstream repo head moved, which for a skill
vendored from a monorepo often means nothing changed in our copy —
skills-update.mjs diff <id> scopes it to the files we actually took.
manual covers sources with no public repo to compare, which no automated
check can ever call current; a human has to look.
From there /skills-update is the judgment layer: read the diff, decide
whether the change is wanted, pull a skill or re-run the catalog pass for a
pack, then restamp. pull refuses to overwrite a working copy that was edited
locally, so a local adaptation is never lost to an update.
Nothing about this is automatic. .github/workflows/upstream.yml runs the
check weekly and writes the table into the run summary — it reports, it does
not fail the build and it does not update anything on its own.