How I Launch New Websites Within Minutes

Starting a new web project used to mean several hours of boilerplate: setting up the design system submodule, writing project-specific CLAUDE.md instructions from scratch, creating the product folder structure, configuring TypeScript paths, wiring up tokens. Every time I missed a step, I'd discover it mid-build when something broke — a missing submodule path, a forgotten ESLint rule, a product folder that didn't match the convention.

I built /init-project to eliminate that entirely. One command, run from the workspace root, and a new project is scaffolded with everything in place — ready for the first feature commit.

What init-project does

/init-project is a Claude Code skill that orchestrates the full project bootstrap. It takes a project name, type, and optional brand, then delegates to three specialized skills in sequence. Each skill handles one layer of the setup, and each reads the workspace CLAUDE.md to understand the conventions it needs to follow.

The orchestrator doesn't do the work itself — it coordinates. This keeps each skill focused, testable, and independently improvable. When I fix a bug in design system setup, every future project benefits without touching the orchestrator.

The three skills

create-claude-md

This skill generates the project's CLAUDE.md — the file that tells Claude Code how to work in this specific codebase. It reads the CLAUDE.md files from three active projects, extracts the patterns that apply (branch naming, import rules, testing conventions, design system integration), and synthesizes a new one tailored to the project type.

The result isn't a template with blanks filled in. It's a context-aware document that references the actual tools, paths, and conventions the project will use. When I start working in the new project, Claude Code already knows the stack, the rules, and the gotchas.

setup-design-system

This skill wires the shared design system into the project as a git submodule. It configures the TypeScript path aliases, adds the submodule to the ESLint ignore list, sets up the token bridge in globals.css, and installs the peer dependencies that design system components need.

The design system is a monorepo with web and native components, shared tokens, and a Storybook setup. Every project consumes the same components and tokens — visual consistency comes from the infrastructure, not from discipline.

init-product-folder

This skill creates the product/ directory with the standard structure: vision doc, PRD template, roadmap, business model canvas, and folders for ideas, tickets, and operations. It populates initial content from the project brief if one exists.

The product folder captures why the project exists and what it should become. Having it from day one means product decisions are documented before the first line of code is written.

What this means in practice

From running /init-project to having a deployable project with a wired design system, complete project instructions, and a product knowledge base takes under five minutes. Every project on sebb.pro — including client sites — was bootstrapped this way.

The consistency matters more than the speed. Every project follows the same conventions, has the same folder structure, and integrates the design system the same way. When I switch between projects, there's no cognitive overhead from different setups. When I onboard a collaborator, the CLAUDE.md is already there.

What's next

The init workflow currently stops at the code layer. Three extensions are on the roadmap:

Automated Vercel setup — creating the Vercel project, linking the GitHub repo, and configuring environment variables as part of the init flow.

Sentry integration — running the Sentry wizard and configuring the GDPR-compliant error tracking setup that every project needs.

CI/CD pipeline — generating the GitHub Actions workflow for lint, type-check, test, and build — currently copied and adapted manually from existing projects.

Each follows the same pattern: a focused skill that the orchestrator calls at the right point in the sequence. The infrastructure is designed for this — adding a new init step is writing a new skill, not refactoring the pipeline.