From Idea to Monorepo in an Afternoon: Bootstrapping a Blog with an Agent

An idea over coffee, a running monorepo by dinner. The speed doesn't come from typing faster — it comes from handing an agent a sharp target and a repo it can't wander out of. Here's the first afternoon of this blog: from an empty folder to a typed Turborepo skeleton. It's the opening move of a series; the whole 24-day run lives in This Blog Was a Weekend Idea.

Write the spec before the scaffold

I didn't open a terminal first — I opened a doc. A one-page SPEC.md named the stack and the boundaries: a pnpm + Turborepo monorepo, Sanity Studio v6 for authoring, a statically rendered Next.js 16 frontend, and types generated from the schema end to end. A root CLAUDE.md turned that spec into standing orders for every agent that later touched the repo.

The spec is the prompt. An agent with a clear contract scaffolds the right thing; an agent without one scaffolds a thing.

That ten minutes of writing did more for the afternoon's speed than any prompt trick. The agent never had to guess what "done" meant, and I never had to babysit a tool that was quietly inventing a folder layout I'd have to undo. How I split the actual build across scoped subagents is its own story in Layer Contracts.

One command for the skeleton

With the target written down, the skeleton is a single command. The agent ran it, then trimmed the generated workspace down to the packages the spec actually called for:

1pnpm dlx create-turbo@latest blog --package-manager pnpm
2cd blog
3# apps/*  = cms (Sanity Studio) + web (Next.js)
4# packages/* = service (typed data layer), shared config

The workspace globs are the load-bearing part — they tell pnpm and Turborepo where the members live, so every later pnpm add and turbo run resolves without hand-holding:

1packages:
2  - "apps/*"
3  - "packages/*"

Let the layout fall out of the spec

The apps and packages weren't invented on the fly — they mapped straight from SPEC.md. apps/cms is Sanity Studio, apps/web is the Next.js site, and packages/service holds the typed data layer both share. Turborepo's task graph then makes a cold build cheap: typecheck waits on upstream build, nothing runs twice, and a warm cache means the second run is nearly instant.

1{
2  "$schema": "https://turbo.build/schema.json",
3  "tasks": {
4    "build": { "dependsOn": ["^build"], "outputs": [".next/**", "dist/**"] },
5    "typecheck": { "dependsOn": ["^build"] },
6    "dev": { "cache": false, "persistent": true }
7  }
8}

The ^build in that highlighted line is what keeps the graph honest: the web app can't typecheck until the service package it imports has been built, so the agent can't accidentally wire a cycle without the task runner complaining.

The afternoon in one line

That was the whole session: a spec, one scaffold command, a workspace file, and a task graph the agent could build against without me approving each step. Nothing here is exotic — it's the standard Turborepo starter — but front-loading the constraints is what turned "help me set up a repo" into "here's a repo that already knows its own shape."

Front-load the spec, then let the agent do the boring 90%. The afternoon that felt fast was really the ten minutes I spent writing down exactly what "done" looked like. Next in the series: the file that keeps every agent pointed the same way — CLAUDE.md Is the Steering Wheel.