Skip to content
Agentic Boilerplate

The first ten minutes

Unzip, install, fill in the env vars, sign in to your own app, run verify, prove the guard hooks still block, and write the first plan.

4 min read

PagesThe first ten minutes

You have a zip, or a folder the CLI wrote. Ten minutes from now you have an app that boots and an agentic layer that works. Go in order. The env vars are the only slow part, and verify tells you which ones are still missing.

1. Unzip and install

bun install

package.json pins packageManager to the one you picked, so everyone on the repo installs with the same tool.

2. Read docs/onboard.md first

It is the one file written for your exact picks, for humans and agents both. It lists every env var your batteries need, where to get each one, and the order to set services up. The order matters: a database before auth, auth before payments.

CLAUDE.md points at it first, so an agent opening the repo cold starts where you do.

3. Fill in the environment

shell

cp .env.example .env.local

.env.example is built from every battery's declared env vars, so nothing is missing by hand. Fill in what you can. You don't need every service live to boot.

4. Boot it

bun run dev

Open http://localhost:3000. You get a landing page for a sample product, plus /terms, /privacy and /llms.txt. All four read one file, src/lib/site.ts. With a payments battery, /pricing renders too, with no keys set.

The app should render. If it doesn't, that's a generator bug. Open an issue and attach your agentic.config.json. It reproduces exactly what you generated.

5. Sign in to your own app

With an auth battery, run the database steps docs/onboard.md lists for your picks (migrations first), then sign up at /sign-up. You land on /dashboard: the signed-in app, with a sidebar, an account menu and settings for your profile and security. Google, GitHub and Microsoft buttons appear once their keys are set.

With the admin panel, make yourself an admin, then open /admin:

bun run admin:grant you@example.com

Then give the landing page your real product. Ask your agent to run /landing-copy with a short brief. It rewrites src/lib/site.ts and nothing else.

6. Run verify

bun run verify

scripts/verify.ts is written for the services you picked. It checks each required variable and pings each configured service, then prints what is missing and where to get it. Green means the repo is wired up, not just compiling.

7. Prove the guard hooks work

bun run verify:hooks

People skip this step. Don't. scripts/verify-hooks.ts runs every installed hook, battery hooks included, with the command from .claude/settings.json and a real hook payload. Each hook gets block cases and allow cases. Block cases run again from src/. A hook that lets a block case through, or blocks an allow case, fails the script.

Run it now, and again after anything touches .claude/. A guard you have never seen fire is a guard you are only assuming is there.

The hooks are wired for Claude Code. Codex doesn't run them. Cursor may, through its third-party hooks setting. See the agentic layer.

8. Typecheck and test

bun run typecheck
bun run test
bun run test:e2e

All three should pass on a fresh repo. test:e2e runs the Playwright specs for the pages your picks ship. A spec whose service isn't set up yet skips and says what to set. Every pair in your pick is in the tested set, and each preset runs whole in the matrix (see how the generator works). So a failure here is worth reporting.

9. Point your agent at the repo, then write the first plan

Open the repo in Claude Code (or Codex, or Cursor). Ask it to read CLAUDE.md and docs/onboard.md. Then, instead of asking for a feature, run:

/ce-plan add team invites to the settings page

You get a plan in docs/plans/: the problem, the approach, the files, how to verify it, the risks. Read it. Argue with it. That argument costs minutes now and would cost a pull request later. When it's right, set status: approved and approved: true in its frontmatter, then run /ce-work.

In team mode this order is enforced: plan-gate refuses edits under src/ until an approved plan exists. In solo mode nothing stops you skipping it. Try it once anyway, on something real, before you decide.

The ten-minute checklist

  • Install finished
  • docs/onboard.md read end to end
  • .env.local created from .env.example
  • dev renders the app
  • Signed up, signed in, and landed on /dashboard
  • verify is green
  • verify:hooks passes: every hook blocks its block cases and allows its allow cases
  • typecheck, test and test:e2e pass
  • One plan written, approved and worked
  • docs/solutions/: the mistakes your batteries are known for, written before you make them. The same docs are public in the cookbook.
  • .claude/rules/: what your agent has been told, scoped to the paths it applies to.
  • Designs and the token contract: before you change how anything looks.