Claude Blueprint: Why I Packaged 33 Days Into One Install

The Problem: Every New Project Starts From Zero

Every time I started a new project with Claude Code, I went through the same ritual. Create a folder. Write a CLAUDE.md file explaining the project, the rules, the voice. Wire up a handful of slash commands for the tasks I repeat constantly. Add some guardrails so a careless prompt could not undo an afternoon of work. Then build a way to actually remember what I had set up, because a folder full of commands and skills is useless if I cannot find them three weeks later.

None of that is glamorous work. It is plumbing. But it is plumbing that has to exist before the actual building can start, and I was redoing it, project after project, with small variations each time. A command I wrote for one app would almost work for the next one, except for one assumption baked in that made it subtly wrong. A hook that caught a mistake in one codebase would miss an equivalent mistake in another because the wording was too specific.

I tracked the actual time this cost me across projects, and it added up to something close to 33 days spread over months of evenings and weekends. Not 33 days in a row. Thirty three days of the exact same setup tax, paid again and again, every time I wanted to start something new. That number is what finally made the pattern impossible to ignore.

I looked at what already existed before deciding to build anything. There are CLAUDE.md examples scattered across blog posts and repos, and a few command snippets shared here and there. None of it was assembled. Nobody had packaged the folder structure, the business logic file, the commands, the skills, and the enforcement hooks into one coherent kit that actually worked together instead of being loose pieces you had to reconcile yourself. That gap, more than any single missing feature, is why Claude Blueprint exists.

The closest things I found fell into two camps, and both had the same flaw. The first camp was a single CLAUDE.md gist, usually good, occasionally excellent, but a rules file on its own does nothing to stop a careless prompt from touching something it should not, and it does not remember your workflow for you. The second camp was a grab bag of individual commands shared without any surrounding structure, so you would copy one file into a project and discover it referenced a skill or a hook you did not have, silently failing in a way that took real debugging time to trace back to a missing dependency. Neither camp treated the setup as a single system with parts that depend on each other. Blueprint had to be built as one thing, tested as one thing, and shipped as one thing, or it would just become one more loose piece for someone else to reconcile.

What Claude Blueprint Actually Ships

Claude Blueprint is a Claude Code setup kit. You run one install script, and it builds an entire workspace: folder structure, a CLAUDE.md template, six commands, six skills, three enforcement hooks, and an interactive dashboard, all in about two minutes.

The CLAUDE.md template is the anchor. It is not a blank file with a few example headers, it is a working business OS: rules, voice guidelines, and a decision framework already filled in with the structure I actually use, so you replace the specifics with your own brand and keep the skeleton that makes the rest of the kit function correctly.

On top of that sit six commands that cover the tasks I found myself repeating across nearly every project: `/repurpose` for turning one piece of content into several, `/brief` for scoping new work before touching code, `/trends` for a quick pulse check, `/weekly-debrief` for a recurring review, `/deploy`, and `/qa`. Each one is production ready the moment the install finishes, not a stub you have to finish writing yourself.

The six skills auto trigger on matching tasks rather than requiring you to remember a command name: debugging, a content audit skill, a session start skill, a humanizer pass, a rough-idea capture skill I call napkin, and a stale-check skill that flags work that has quietly gone out of date. The three enforcement hooks run automatically before tool use: a brand check, an accessibility check, and a spacing check, catching the kind of small mistake that is cheap to fix immediately and expensive to fix after it has shipped.

Everything is documented in a searchable interactive dashboard, an HTML file you open locally, covering every tool, the order they chain together in, keyboard shortcuts, and a decision matrix for which tool to reach for in a given situation. The dashboard is the part that made the whole kit feel finished to me. Commands and hooks are only useful if you remember they exist.

The Hardest Part Was Deciding What to Leave Out

Building the individual commands was the easy part. I already had working versions of most of them from real projects. The hard part was deciding what belonged in a general-purpose kit versus what was specific enough to my own workflow that it would confuse anyone else trying to use it.

An early version of Blueprint had nine commands, not six. Three of them were cut entirely, not simplified, cut, because they encoded assumptions about my own project structure that would not transfer. A command that assumes a specific folder layout is a trap for anyone whose project does not match that layout exactly. I would rather ship six commands that work everywhere than nine where three quietly fail depending on your setup.

The same filtering happened with the hooks. I use more than three automated checks in my own projects day to day, but most of them are too narrow to generalize, tuned to specific patterns in my own codebase that would produce false positives anywhere else. Brand, accessibility, and spacing survived that cut because they are close to universal concerns for anyone shipping a public-facing project, regardless of what that project actually is.

Deciding what to cut meant sitting with each command and hook and asking a single question honestly: would this still make sense to someone who has never seen my codebase, reading it for the first time. If the answer required an explanation longer than the command itself, it did not belong in a kit meant to work in two minutes with zero hand holding. That question cut harder than I expected. A few of my personal favorites did not survive it, including one command I genuinely missed for weeks after cutting it, because it solved a problem specific enough to my own content pipeline that explaining it to someone else would have taken longer than just writing the command from scratch themselves.

This is the same discipline I wrote about when covering the .claude folder and how to set it up for any project: the value is rarely in having more automation, it is in having automation that actually fires correctly instead of nagging you with false alarms until you disable it. A hook nobody trusts gets turned off within a week. A kit that tries to do everything ends up doing nothing reliably.

Why a One-Time Kit, Not a Subscription

I considered wrapping Blueprint as a recurring subscription, the way a lot of tooling in this space works. I decided against it, and the reasoning mattered enough that it shaped the entire product.

A setup kit is, by its nature, something you use most intensely in the first week after buying it and then reach for occasionally after that, whenever you start a new project or need to remember how a command chains into another. That usage pattern does not fit a subscription. Charging monthly for something you touch heavily once and then lightly forever felt like the wrong trade for the person buying it, even if it would have been the easier choice on my end.

So Blueprint is a one-time purchase at 49EUR, delivered instantly, yours to customize with no ongoing dependency on me or on my server staying online. You get the install script, you run it once, and everything it creates belongs entirely to your own machine and your own repo from that point forward. If I disappeared tomorrow, everything already installed would keep working exactly as it does today, because none of it phones home or depends on anything I control.

That decision connects directly to something I have written about before: the tooling I trust most, and the tooling I want to build, is the kind that respects the person using it enough to not need permission to keep working. I carried the same instinct into the free Claude Code skills and plugins I have documented, and into how I structure the repos behind multiple products in one monorepo. A tool someone pays for once should not quietly turn into a tool they have to keep paying for just to keep the lights on.

Bottom Line

Claude Blueprint started as an honest accounting of a cost I kept paying without noticing: roughly 33 days, spread across months, spent rebuilding the same Claude Code setup from scratch for every new project. Packaging that into a single install script, a CLAUDE.md template, six commands, six skills, three enforcement hooks, and a dashboard turned a recurring tax into a two-minute step.

The real lesson was not about the individual commands or hooks. It was that a good setup kit is defined more by what got cut than by what got included. Nine commands became six because three did not generalize. More than three hooks became three because the rest were too narrow to trust anywhere but my own codebase. Restraint, more than volume, is what made the kit something other people could actually pick up and use correctly on day one.

If you have ever felt the specific friction of starting a new Claude Code project and rebuilding the same folder structure, the same rules file, and the same handful of commands you know you will need eventually, that is exactly the gap Blueprint exists to close. It is not a subscription and it does not ask for anything back once it is installed. It just saves you the 33 days I already spent finding out what belongs in it.