Every new project starts with the same ritual: create an empty repo, then hunt down the folder structure, the conventions and the workflow files from the last project — and forget half of them. A Claude Code project template can invert that reflex: instead of starting with nothing and building up piece by piece, you start with everything — and let an interview delete what the project doesn’t need.
That is exactly how the open DI² starter kit works: the template ships every skill and every rule, an /init interview captures the project’s framework conditions, records them in one central file — and then tailors the clone to exactly that stack. This article explains the principle behind this Claude Code project template, “start maximal, prune subtractively”, and where its limits are.
Key takeaways:
- Maximal instead of minimal: the template stays complete — what gets pruned is the clone, never the template.
- The
/initinterview: roughly ten questions along the stack axes (runtime, UI, backend, database, auth, deploy, CI, …) before anything is deleted. stack.mdas the single source of truth: one file carries the stack; the skills read it instead of making assumptions.- The pruning matrix: which answer removes which files — until
/initdeletes itself at the end. - The honest boundary: when the maximal approach pays off and when the empty repo remains the better start.
Prerequisite: Claude Code; the examples come from the open DI² starter kit on GitHub. No SQL knowledge is needed for this article.
Contents
- Two Ways to Start a Project
- The Interview: /init Asks Before It Deletes
- stack.md: the Single Truth About the Stack
- The Pruning Matrix: What Gets Deleted When
- When Maximal, When Empty
- FAQ
- Related Articles
Two Ways to Start a Project
The reflex with project templates leans toward minimalism: prescribe as little as possible, because every prescribed file is an opinion that might not fit. The price of that reflex shows up on the third, fourth, fifth project: you rebuild the same structure every time — and whatever gets forgotten doesn’t announce itself. The missing security rule throws no error, the missing QA step breaks no build. The omission only surfaces once it has cost something.
The maximal approach turns the problem around. The template ships everything: every workflow skill, every convention file, the complete rule set for database, deployment and CI. Setting up a project means deleting, not building — and deleting is the easier operation. Whoever deletes decides with the complete picture in view: the list of candidates sits visibly in front of you, every file is a yes/no question. Whoever builds up has to remember what’s missing — and there is no checklist against forgetting when the checklist itself is the thing that’s missing.
The asymmetry holds after setup, too: a clone can always prune further when a rule turns out to be unnecessary. The reverse direction — bringing a deleted skill back — means copying it back from the template. That is why the template itself stays maximal; what gets tailored is always and only the clone.
Between the two extremes sits a third, established family: parameterized generators such as Cookiecutter, Copier or Yeoman — the classic answer to recurring project boilerplate; GitHub template repositories live in the same neighborhood. Generators ask questions as well, but they work additively: from placeholders and conditions they render exactly the project the answers describe, and the template remains a stencil full of templating syntax. The maximal approach differs in two places: every file in the clone exists in its final form from the start — readable, diffable, with no template layer to maintain. And the tailoring doesn’t happen at generation time inside the generator, but as a traceable deletion history in the clone’s git log. If you already maintain a good Cookiecutter template, you lose nothing by keeping it; what the maximal approach mainly saves is the templating layer.
That this pattern works well with a guided agent like Claude Code in particular has two reasons. First, the tailoring itself is a process with questions, rules and checkpoints — exactly the kind of work an agent executes reliably along an instruction file, and exactly the kind a human copying files has no patience for. Second, dead scaffolding has a measurable price in a Claude Code project: rules load fully into the context at every session start (mechanics as of July 2026) — so a rule set that doesn’t apply costs every single session, as the sibling article on skills vs. rules shows in detail. Deleting here isn’t tidiness — it’s context hygiene.
The Interview: /init Asks Before It Deletes
In the starter kit, /init is a one-time bootstrap skill, and it begins with a pre-check: it reads .claude/rules/stack.md and checks whether {{PLACEHOLDER}} values are still present. If none are left, the project is already initialized — /init stops instead of pruning a running project. The uninitialized state is machine-detectable, not a convention held in someone’s head.
Then comes the interview, in two parts. First the product vision — core problem, target users, must-have features — in two or three sentences for the PRD file; the detailed work is done later by the regular workflow. Then the framework conditions of the stack, axis by axis:
Runtime? python-3.12
UI? none
Backend? yes — fastapi
Database? postgres
Test scaffold? keep
Auth? none
Deploy? docker-ssh-vps + github-actions
CI? github-actions
Env stages? dev,prod
Feature prefix? feat
On top of that, /init derives the concrete build, test, run and audit commands for the chosen runtime and has them confirmed. The order is the core of the design: record first, delete second. Every answer is written down before the first file falls — because the answers are what drives the pruning matrix in the next step. And for the uncertain cases there is a clear right-of-way rule: if you can’t answer an axis, you keep the corresponding part — the asymmetry from the beginning settles the doubt.
stack.md: the Single Truth About the Stack
The answers don’t end up in the conversation — they end up in a file: .claude/rules/stack.md. It carries a profile table with the stack axes, the command block and free-form notes — after the interview, roughly like this:
| runtime | python-3.12 |
| ui | none |
| backend | fastapi |
| database | postgres |
| migrations | plain-sql |
| auth | none |
| deploy | docker-ssh-vps + github-actions |
| ci | github-actions |
lint: ruff check .
test: pytest
run: uvicorn app.main:app
audit: pip-audit
This file is the pivot of the whole approach, in two directions. Inward, it is the single source of truth for the skills: the kit’s stack-neutral skills — architecture design, backend implementation, review, deploy, update check, security sweep — name no language, no framework and no hosting provider in their own text. They read stack.md at execution time and follow what it says. One place carries the stack; when it changes, it changes once.
Outward, it drives the pruning: if an axis says none, the corresponding part of the toolkit isn’t merely ignored — it is removed. So stack.md doesn’t just document what the project is; it justifies what the clone lacks. Whoever asks a year later “why don’t we have a /deploy skill?” finds the answer in one table row: deploy: none.
That bundling has a flip side that belongs in the picture: stack.md is also a single point of failure. If a wrong or stale value sits there — a database the project switched away from long ago, a test command that no longer exists —, every skill that reads the file works from the same wrong assumption. The error acts centrally, exactly like the truth does. Whoever changes the stack has to update the file with it; that is the price of the single source.
The Pruning Matrix: What Gets Deleted When
The actual tailoring follows a fixed matrix — every interview answer has defined consequences. The most important rows:
| Answer | Removed |
|---|---|
ui: none | the /ux and /frontend skills, the UI rule tree, cookies.md |
backend: none | the /backend skill, the backend rule |
database: none | the complete SQL rule tree, the db/ directory tree, the DB jobs in CI |
database: postgres | the mssql/ rule tree — only the matching SQL dialect stays |
auth: none | the /auth skill |
deploy: none | the /deploy skill, the infrastructure rule, the SSH deploy workflows |
ci: none | the complete .github/workflows/ tree |
| always | /init deletes itself at the end — a bootstrap runs only once |
Three properties of the matrix matter more than its individual rows.
Deletion happens via git rm, after confirmation. The clone is a git repository; every removal is a traceable, revertible step in the history — not a silent cleanup. Before deleting, /init shows the list of candidates and gets a yes; afterwards it shows the remaining skills and rules for review.
A core always stays. Feature specification, architecture, QA, review, bug filing, update check and security are never removed, and neither are the project’s base rules including stack.md. The matrix trims the stack-dependent edge, not the workflow core.
For variants the kit doesn’t ship, the rule is “port, don’t stack”. The kit ships exactly one UI rule set and two SQL dialects. If a project needs a different variant — another frontend framework, a third SQL dialect —, the shipped rule tree gets copied, adapted, and the original removed. Two variants never sit next to each other in the context, for the same reason anything gets deleted at all.
That things get deleted is a design decision, not a law of nature. With paths:-scoped rules, Claude Code also offers a middle ground between “always loaded” and “gone”: such a rule only loads once a file matching its path pattern is touched. Other templates can do well with deactivating or lazy loading. The kit deliberately passes on that and removes what doesn’t apply entirely — what’s in the clone applies; what doesn’t apply isn’t in the clone. For this template, deleting is the simpler and more robust way.
The last of the three properties shows most concretely in the database row: with database: none, the complete db/ tree disappears — precisely the directory-based deploy approach the sibling article on deploying a SQL schema without a migration tool describes. With database: postgres it stays in full, along with the matching rule tree. The matrix doesn’t decide about feature flags — it decides about files.
When Maximal, When Empty
The maximal approach has one precondition and one boundary — both belong on the table.
The precondition: the pruning must be reliable. If dead scaffolding survives the tailoring — rules for a database that doesn’t exist, a skill for a deployment that never happens —, then the maximal start is worse than the empty repo: the non-applicable rules load into the context every session, and the dead skills sow confusion because they promise capabilities the project doesn’t have. The kit secures this through the matrix and the review list at the end — but a template has to have that property before the approach carries.
The boundary runs along repetition. The maximal approach pays off when project starts recur and share a common workflow core: the same specification steps, the same review practice, changing stacks. Then the template amortizes with every clone, and the interview is cheaper than any manual scavenging. The empty repo stays better for the throwaway script, the single-file experiment, and the case where a workflow of your own simply doesn’t exist yet — whoever adopts the conventions of a foreign Claude Code project template sight unseen adopts foreign opinions as project law.
And a maturity note belongs here: the template form of the kit is young. The conventions inside it grew and proved themselves in daily use in the DI² project — the packaging as a self-pruning template has not yet. Whoever adopts it adopts a well-thought-out idea, not a framework seasoned over years.
FAQ
Two things that must be kept apart. Claude Code ships a built-in /init that analyzes the existing code and generates a CLAUDE.md from it. The starter kit, by contrast, ships its own /init skill: a one-time bootstrap interview that captures vision and stack, fills stack.md and CLAUDE.md, and then deletes the skills and rules the project doesn’t need.
For recurring project starts, the asymmetry argues for maximal: deleting is a decision made with the complete picture in view, building up requires remembering what’s missing — and what’s forgotten doesn’t announce itself. Maximal only carries, though, if the pruning happens reliably; without pruning, the maximal template is just ballast.
The single source of truth for a project’s tech stack in the starter kit: a file under .claude/rules/ with a profile table (runtime, UI, backend, database, auth, deploy, CI, …) and the build, test, run and audit commands. The stack-neutral skills read it at execution time instead of hard-coding a language or framework in their own text.
The same way as during setup, just without the interview: remove the skills and rules you don’t need via git rm — the git history keeps them, and the template holds the original in case something needs to be copied back. What matters is the direction: when in doubt, keep now and delete later rather than the other way around.
No — “start complete, prune subtractively” works with any project template. But it has its biggest lever where unused files carry a running cost: in Claude Code, rules load into the context at every session start, so there the tailoring is immediate context savings, not just tidiness.
Related Articles
- Setting up a Claude Code project with a development workflow and database — the overview of the setup this template is the starting point of.
- Skills vs. rules in Claude Code — the loading mechanics that explain why deleting saves context.
- Deploying a SQL schema without a migration tool — the
db/tree the database row of the pruning matrix decides about. - The open DI² starter kit on GitHub — the maximal template including the
/initskill and the pruning matrix, ready to read.