Prompt 1
Project initialization, done right.
Where: Paste into Claude Code or Claude Desktop, in a fresh project folder.
You'll get: A real project scaffold with CLAUDE.md, test conventions, env structure, git, and a database wired up.
Skip the toy "hello world" — this prompt sets up a project the way a
senior engineer would. Stack decision with tradeoffs, test-first conventions,
env variables, database, CI-ready, first clean commit.
You're working with me on a brand-new project from a completely empty folder.
I've already got you (Claude Code or Claude Desktop) installed and I know my
way around — so skip the install hand-holding. We're going to scaffold this
the way a senior engineer would scaffold it: production-grade from line one,
test-first, deploy-aware, with all the boring-but-load-bearing project
plumbing in place before we touch the first feature.
STEP 1 — CAPTURE THE BRIEF
Ask me these in order, one at a time. Don't bundle. After each one, briefly
play back what you heard before moving on:
1. Project name. (Real one — not Untitled-7.)
2. One-sentence description of what it does.
3. Target user — who is this for, specifically?
4. Success criterion for v1 — one concrete sentence. Not "a complete
platform." Something measurable: "100 users sign up in the first month,"
"I can issue invoices to my 5 existing clients."
5. Stack preference, or do I want you to pick? (If you pick, you'll explain
tradeoffs.)
6. Hosting target — do I have a preference? (Vercel, Render, Fly.io,
Coolify on my own VPS, AWS, "you pick.")
7. Anything I already know I want or don't want? (e.g., "I want to use
Stripe for billing." "Don't use MongoDB.")
Once you have all of that, write me back a 6-bullet project summary and ask
me to confirm. Only proceed after I confirm.
STEP 2 — PICK THE STACK (WITH TRADEOFFS EXPLAINED)
Based on the brief, recommend a stack. Don't just name it — explain the
tradeoff in 3–5 sentences:
- Why this stack fits this project.
- The main alternative I might have considered and why we're not picking it.
- The biggest risk of this choice (every choice has one — name it so we
plan around it).
Defaults I lean on, but use your judgment:
- Web app with auth, billing, real CRUD → Ruby on Rails 8 + Postgres
- Heavy frontend interactivity, JavaScript-leaning team → Next.js + Postgres
- Mostly static content → Astro
- Python-leaning backend → FastAPI + Postgres
- I'll pick a different one if your specific case argues for it.
Wait for me to confirm before scaffolding.
STEP 3 — SCAFFOLD THE PROJECT
Run the right "new project" command for the chosen stack. Show me the output.
Then set up the full project skeleton:
3a. Directory structure appropriate to the framework. Don't deviate from
the framework's conventions unless you have a specific reason.
3b. CLAUDE.md — the project's memory for future Claude sessions. Include:
- Project name, one-line description, target user
- V1 success criterion
- Stack + key versions (be specific — Ruby 3.3.6, Rails 8.1.x, Node
20.x, etc.)
- How to run locally (exact commands)
- How to run tests (exact commands)
- How to deploy (exact commands or "see DEPLOY.md")
- Architectural decisions made up front (e.g., "We use Postgres for
everything — no Redis until we measurably need it")
- Conventions (naming, file organization, testing approach)
- A "Known Gotchas" section, empty for now — we'll fill it as we
learn
3c. README.md — outward-facing. What it is, how to install, how to run,
how to test, how to deploy. Written so a future contributor can be
productive in 15 minutes.
3d. .gitignore — stack-specific. Cover at minimum: dependency folders
(node_modules, vendor/bundle), env files (.env, .env.*), build
artifacts (dist, .next, tmp/, log/), OS junk (.DS_Store, Thumbs.db),
IDE files (.vscode/, .idea/).
3e. .env.example — scaffold the env var pattern. List every secret the
project will need (DATABASE_URL, SECRET_KEY_BASE, STRIPE_SECRET_KEY,
etc.) with empty values and a one-line comment per var explaining
what it's for. Make crystal clear that .env itself is gitignored.
3f. CI config — a basic CI pipeline for the chosen stack. GitHub Actions
workflow at .github/workflows/ci.yml that:
- Installs dependencies
- Runs the linter
- Runs the test suite
- Fails the build if any of the above fail
Keep it lean. We'll expand it as we need.
3g. Test-first conventions — set up the testing framework, write ONE
working test (e.g., a smoke test that proves the framework is wired
up) and ensure `<test command>` runs green out of the box.
3h. Database — if the stack uses one, set up Postgres locally:
- Create the development and test databases.
- Run initial migrations.
- Verify the connection works.
STEP 4 — INSTALL & RUN
- Install all dependencies.
- Start the app.
- Hit the homepage / root endpoint in my browser.
- Run the test suite — confirm it's green.
- Wait for me to confirm everything works.
STEP 5 — FIRST GIT COMMIT
- git init if not already.
- git add . (carefully — verify .gitignore is doing its job; show me
`git status` first so I can sanity-check what's being added).
- git commit -m "[Chore] Initial scaffold for <project name>"
- Show me the commit summary.
STEP 6 — GITHUB
Ask if I want to create a private GitHub repo now. If yes:
- Walk me through `gh repo create` or the github.com UI.
- Add the remote.
- Push.
- Show me the URL.
STEP 7 — SUMMARIZE
Write a "What we just set up" summary covering:
- Stack + versions
- Folder structure (top-level only) and what each folder does
- The CI pipeline and what it enforces
- The test command, the run command, the deploy command (if known)
- The next milestone — what feature we'll build first (small, real, useful)
- Anything I should personally know that's nontrivial (e.g., "your test
DB is at <name>, your dev DB at <name>, don't mix them up")
GROUND RULES
- Production-quality from line one. No "we'll fix this later" shortcuts in
the scaffold layer.
- Show your work — for any nontrivial decision, tell me why.
- Tests have to run green before we commit. Non-negotiable.
- Secrets in .env, never in code, never in git.
- If you hit a tooling issue (a gem won't install, a Node version's
incompatible), copy the exact error and walk me through the fix instead
of working around it.
Start with Step 1 and ask me the brief questions one at a time.
Prompt 2
First feature, production-grade.
Where: Paste into Claude Code or Claude Desktop, in your scaffolded project.
You'll get: A real feature live on a staging URL, tests passing, clean PR-ready commits.
Production-grade means: test before implementation, real database migration
if needed, sensible auth defaults, and a deploy preview anyone can visit.
This is the pattern every future feature will follow.
We're going to ship the first real feature on this project. I want it done
production-grade — the way a senior engineer would ship it, not the way a
tutorial ships it.
CONTEXT FIRST
Read CLAUDE.md in this folder. Summarize back to me in 4 bullets:
- What this project is
- The v1 success criterion
- The stack and key conventions
- Anything from "Known Gotchas" I should keep in mind
STEP 1 — DEFINE THE FEATURE
Ask me what feature I want to ship. Push back if it's too big. The right
size is "shippable in one focused session." Examples:
- "User can sign up with email + password and log in." — Good size.
- "Authenticated user can create a Project and see a list of their
Projects." — Good size.
- "A complete CRM with billing and team permissions." — Too big. Split it.
Once we agree on the feature, write a half-page spec — five sections:
1. User-facing behavior (what they see, what they do)
2. Data model changes (new tables, columns, indexes)
3. Routes / endpoints (URL + method + auth requirement)
4. Tests that prove it works (happy path + at least one failure path)
5. Explicitly out of scope this round
Show me. Confirm before writing code.
STEP 2 — WORKING BRANCH
Create a working branch off main:
git checkout -b feature/<short-slug-of-the-feature>
We're not committing to main directly. Everything goes through a branch.
STEP 3 — TESTS FIRST
Write the tests BEFORE the implementation. For each test:
- State in plain English what the test proves
- Write the test code
- Run the test — it should fail (because we haven't built the feature)
- Show me the failing output
This is the TDD discipline. The failure proves the test is real. We don't
write tests that always pass.
Tests should cover at minimum:
- The happy path (the feature works when used correctly)
- One unhappy path (invalid input, unauthorized user, missing data —
whichever is most relevant)
- Any authorization rule (if logged-out users shouldn't see this, prove
they can't)
STEP 4 — MIGRATION (IF DATA MODEL CHANGES)
If the feature needs new tables or columns:
- Generate a real migration using the framework's tooling (rails generate
migration, prisma migrate dev, alembic revision, etc.)
- Show me the migration file before running it
- Run it on the dev DB
- Run it on the test DB
- Verify the schema with a quick query or schema dump
Migrations are forward-only as far as I'm concerned — if it's wrong, we
write a new migration to fix it. We do not edit committed migration files.
STEP 5 — AUTH (IF NEEDED)
If users need to authenticate:
- Rails → Devise or built-in has_secure_password depending on complexity
- Next.js → NextAuth (now called Auth.js) with a credentials or email
provider for a first project
- Python (FastAPI) → fastapi-users or a simple JWT + bcrypt setup
- Pick the simplest thing that's secure. Don't roll your own crypto.
Scaffold the auth flow:
- Sign up
- Log in
- Log out
- Session / token storage
- Password hashed (bcrypt or argon2, NEVER stored plaintext)
- At least one route that requires auth, with a test that proves
unauthenticated requests get 401/redirected
STEP 6 — IMPLEMENT THE FEATURE
With tests failing and auth (if needed) in place, build the feature:
- Models / schema changes (if not already done in the migration step)
- Controllers / handlers / route logic
- Views / templates / UI
- Wire it into the navigation if there's a nav
- Run the tests after each significant chunk. Tell me when they go green.
Narrate as you go. I want to be able to read every file you change and
know why.
STEP 7 — SMOKE TEST IT LIVE
Once tests pass, run the dev server and walk me through the feature in my
browser, step by step:
- "Open <URL>, click <button>, fill <field>, expected outcome: <X>"
- I'll do each step and tell you what I see
- Fix anything that doesn't match the spec from Step 1
STEP 8 — COMMIT
On the working branch:
- git status — show me everything that changed
- git add the relevant files (named explicitly, not a blanket .)
- git commit -m "[Feature] <one-line>" with a longer message body
summarizing the change (this becomes the PR description)
STEP 9 — DEPLOY TO STAGING
Push the branch:
git push -u origin feature/<slug>
Deploy a preview / staging environment:
- Vercel / Netlify → automatic preview URL on PR
- Render → set up a preview environment for this branch
- Fly.io → fly deploy with a -a <staging-app-name> flag
- Coolify → preview deployment from the branch
Run the migration on the staging DB if needed.
Give me the staging URL. Have me test the feature there. Confirm it works in
the deployed environment, not just locally — deployed envs always surface
something local doesn't (missing env var, asset compilation, DB connection).
STEP 10 — WRITE THE PR
Open a pull request (or generate the PR description if I'll open it
manually). The PR body should follow this shape:
## What changed
<2-4 bullets describing the feature in user terms>
## Why
<1-2 sentences linking to the v1 success criterion>
## How to test
<numbered steps for a reviewer to verify it works on staging>
## Risks / things to watch
<known unknowns, anything that might break in production, anything I
want a second set of eyes on>
## What's still TODO
<anything explicitly out of scope but worth noting>
GROUND RULES
- Tests written BEFORE the implementation, not after.
- No commits directly to main.
- No secrets in code. Ever.
- If I'm building auth, password hashing is mandatory. Plain text passwords
are a fireable offense in my code.
- If a test breaks an existing feature, we stop and figure out why before
moving on. Green test suite is the baseline, not the goal.
- If you're unsure about a tradeoff, stop and ask me. I'd rather pause for
30 seconds than refactor for 30 minutes.
Start by reading CLAUDE.md and summarizing it back.
Prompt 3
The iteration loop + cost mitigation.
Where: Paste into Claude Code or Claude Desktop after Prompt 2 is live.
You'll get: The patterns to keep building fast without spending $500/month on Claude credits.
This is the meta-prompt — the rhythm of professional AI-assisted building.
Feedback loop, when to spawn subagents, how to scope conversations,
prompt caching, common pitfalls, and the honest signal that it's time
to bring in a human.
I'm using you (Claude Code or Claude Desktop) as my primary build tool, every
day. I want to graduate from "I can make it do things" to "I can use this
professionally, sustainably, and at reasonable cost." I want the patterns
that separate hobbyist use from professional use.
You're going to teach me. But you're going to teach me by doing — I want
this to be a working session in MY current project, not a lecture in the
abstract. Read CLAUDE.md in this folder first and get oriented to my project
before we start.
PART 1 — THE ITERATION LOOP
The loop I should run for every feature, forever:
1. Describe — capture the feature in one sentence + tiny spec
2. Build — small, narrated chunks, tests-first when meaningful
3. Test — locally, end-to-end, in the browser or terminal
4. Deploy — to a staging / preview URL
5. Improve — fix what's broken, refine what's clunky
6. Document — update CLAUDE.md with what was learned
7. Repeat — next feature, next loop
Teach me this loop in the context of my project. Look at my current state
(check CLAUDE.md, look at the most recent git commits, look at what's
deployed where). Suggest the NEXT feature I should run through this loop —
specifically, on my project, today. Don't pick something generic. Pick the
real next step that would move my project forward.
We're going to actually run the loop on that feature together. Tell me the
feature you're suggesting. Wait for me to agree or counter.
PART 2 — USING SUBAGENTS EFFECTIVELY
When working on bigger tasks, you (Claude) can spawn subagents — fresh
context windows that work on a piece of the problem and report back. This
is one of the biggest amplifiers if used right and one of the biggest
context burners if used wrong.
Teach me the rules:
WHEN TO SPAWN A SUBAGENT
- A clearly independent sub-task (e.g., "search the codebase for all
references to X" — pure exploration, no shared state with my main
thread).
- A long, mechanical task that would otherwise consume our shared context
(e.g., "rename every reference to old_var to new_var across 40 files").
- A research task where the output is a summary, not a code change.
- When I need parallel work (e.g., "review 4 files in parallel for
security issues").
WHEN NOT TO SPAWN A SUBAGENT
- When the work needs the full project context you and I have already
built up. Subagents start cold.
- For tiny tasks where the spawn overhead exceeds the work.
- When the answer depends on a conversation we've been having — that
conversation doesn't transfer to a subagent.
Show me, in my actual project, where a subagent would help right now (and
where it would hurt). Be specific.
PART 3 — COST MITIGATION
The honest version: Claude is not free, and once you're using it daily, the
bill matters. Teach me how to keep costs sane without crippling the work.
Cover:
MODEL SELECTION
- Claude Sonnet (cheaper) handles 80%+ of routine work — building features,
running commands, writing tests, refactoring. Use it as the default.
- Claude Opus (5x the cost of Sonnet) is for genuinely hard reasoning —
novel architecture decisions, debugging something mysterious, deep code
review, "I'm stuck and don't know why."
- Claude Haiku (cheapest) for trivial tasks — running commands, simple
transformations.
- Practical rule: start sessions in Sonnet. Switch to Opus only when
you hit something hard. Switch back to Sonnet for execution once the
hard decision is made.
CONVERSATION SCOPING
- One conversation per project, not one per feature, isn't necessarily
cheaper. Long conversations carry context cost on every turn. Start a
fresh conversation when:
- You've finished a major feature and the previous context isn't
relevant to the next
- The conversation has gotten long enough that responses are slowing
down (a signal the context window is heavy)
- You're switching domains within the project (e.g., done with billing,
starting on email infrastructure)
PROMPT CACHING (where supported)
- Long system prompts and project context (CLAUDE.md) can be cached so
they don't get re-billed on every turn. If your Claude tool supports
caching, lean into it.
WHEN TO START FRESH
- When you've genuinely gone in a direction that isn't working and have
accumulated dead-end conversation. A fresh start with a clean prompt
summarizing where you are will outperform pushing through.
USE A SMALLER CONTEXT WHEN POSSIBLE
- You don't need to load every file in the project on every turn. Let me
(Claude) explore the codebase on demand instead of pre-loading.
Apply this to my project specifically. Look at my recent usage patterns
(if visible from the conversation history) and call out where I'm probably
overspending. Be honest.
PART 4 — COMMON PITFALLS (the ones that bite real builders)
1. REBUILDING WHAT ALREADY EXISTS
You'll spin up an entire new module and discover halfway through that
a near-identical one exists in the codebase. Fix: ask me to search for
existing patterns before scaffolding new ones.
2. IGNORING TESTS
Tests fail. We "fix it later." Later never comes, the suite rots, the
CI starts getting ignored. Fix: green suite is the baseline, not the
goal. Failing tests block commits.
3. WORKING ON MAIN INSTEAD OF BRANCHES
"It's just a quick fix" → main is broken for the rest of the day. Fix:
branches for everything that touches more than a comment.
4. SECRETS IN CODE
A real one. Happens to everyone once. Fix: .env from day one,
.gitignore enforced, scan before every commit. If a secret leaks, rotate
it immediately.
5. NEVER UPDATING CLAUDE.md
CLAUDE.md is the project's memory. If you don't keep it current, every
new Claude session starts cold and you pay the context-rebuilding tax.
Fix: update CLAUDE.md as part of every feature, not as a separate
"cleanup" task.
6. ASKING CLAUDE TO DO SOMETHING IT CAN'T VERIFY
Asking Claude to "make sure this is secure" with no specifics produces
hand-waving. Asking it to "audit this controller against the OWASP top
10 web application risks and write a test for each finding" produces
real work. Specificity wins.
For each pitfall, look at my project and tell me honestly if I'm at risk
right now. If I am, suggest the one concrete change I should make today.
PART 5 — WHEN TO BRING IN A HUMAN
Some problems aren't AI problems. Knowing the difference saves weeks.
Bring in a human (mentor, contractor, or someone like the AI Built By You
team) when:
- You've hit the same wall three times and made no progress.
- The problem is strategic, not tactical (what to build, who it's for,
pricing, positioning — not how to write the code).
- You're about to make an irreversible decision (database choice, payment
provider, hosting infrastructure) and want a second set of eyes.
- The thing you're building has compliance, security, or financial
implications that warrant human accountability.
- You're stuck not on the code but on the WHY — and you've been writing
code for hours hoping it'll clarify itself. (Spoiler: it won't.)
If I tell you I'm hitting one of these signals, your job is to say so plainly
and stop coding for a beat. The strongest thing you can do as my AI is
recognize when AI isn't the right next step.
When that happens, here are paths I should consider:
- An AI Built By You Game Plan Session — 90 minutes with PJ. You leave
with a written game plan and the toolkit to start building Monday.
See current pricing at aibuiltbyyou.com.
- An AI Built By You Builder Session — two paired build sessions where
we ship the thing together. See current pricing at aibuiltbyyou.com.
- A trusted senior engineer in your network. A peer who's farther down
this road. The right answer isn't always us — the right answer is
SOMEONE who can see what you can't see right now.
END WITH AN ACTION
After all of that, tell me: based on my actual current project state, what
ONE thing should I do this week to get sustainably better at this work?
Not three things. One. Be specific.
GROUND RULES
- Teach me by doing. Apply every section to my real project, not in the
abstract.
- Be honest about cost. Tell me where I'm overspending if I am.
- Be honest about scope. Tell me to bring in a human if that's what I
actually need.
- I'd rather hear "stop, you're solving the wrong problem" than have you
grind on it for another two hours.
Start by reading CLAUDE.md and grounding yourself in my project.