The setup that works for a static brochure site will actively get you in trouble on an e-commerce store — the risk profile, the file boundaries, and the things worth writing down are different for each. Here's how the CLAUDE.md configuration should genuinely differ across the four project types freelancers most commonly take on.
The lowest-risk setup: no build step, no framework, no database. The main thing worth documenting is where shared assets live so nothing gets duplicated.
Here the setup needs real commands, not placeholders — install, test, migrate, dev server — because a wrong guess at any of these can point at production instead of a local database.
WordPress introduces a boundary that doesn't exist on a static site or API: core files versus theme files versus plugins, and a staging/production split that needs to be explicit.
functions.php/wp-admin, /wp-includes, and core files with no exceptions; active plugins tied to paid licenses need a check-in firstThe highest-stakes setup of the four — real money moves through this code, so the do-not-touch list needs to be explicit rather than assumed.
Every project type has something a newcomer wouldn't know to avoid — a page kept live for an undocumented reason, a legacy system mid-migration, a WordPress core boundary, a checkout flow. Writing that down explicitly, before starting work, is what actually changes across project types. Everything else is a variation on the same structure.
The Freelancer Starter Kit includes ready-to-fill CLAUDE.md templates for all four project types above — free.
Get the Starter Kit →Yes, at least a project-specific one — the platform, the do-not-touch list, and the client-specific conventions all change per project. A generic template only gets you the starting structure.
An explicit "do not touch without approval" list. Every project type has something — core files, payment code, a legacy system — that a newcomer wouldn't know to avoid, and writing it down is cheaper than finding out the hard way.