7 Things to Set Up Before Writing a Single AI Prompt

Open a fresh project, type your first prompt, and watch Claude Code pick a database you don't use, a folder layout you'll have to undo, and a commit style that fights your repo. That is what happens when you skip setup. Not because the model is bad. Because it has nothing to go on.

Seven things change that. None of them is a prompt. They are the scaffolding that sits underneath every prompt you'll ever write: a repo, your keys, a CLAUDE.md, docs that update themselves, the right plugins, MCP servers, and a few slash commands. Spend twenty minutes here and you stop re-explaining your project at the start of every session.

_AI-assisted: drafted with Claude Code, then edited and fact-checked by hand against a real working repo (versions and config shown below are real)._

Here's the whole list, in the order I'd do them:

1. Create a GitHub repository
2. Set up environment variables
3. Write a CLAUDE.md file
4. Set up automated documentation
5. Install plugins
6. Configure MCP servers
7. Create slash commands and sub-agents

They are not equally important. If you only ever do one, do number three. More on why at the end.

What does skipping setup actually cost you? Concrete things, not vibes:

• Claude reaches for a stack it has seen a million times instead of yours. You asked for Convex, you get Prisma and Postgres.
• Fixing that choice burns the context window. Every correction is tokens you don't get back.
• A missing API key stops the run cold, usually three files into a feature.
• Generated code ignores your conventions, so you rewrite it to match the rest of the codebase.
• Next session, Claude has forgotten all of it. You start over.

The last one is the killer. Without persistent context, every session is day one. The seven steps below are mostly about making day one happen once.

Do this before the first line of code. Not because you're precious about the prototype. Because the moment Claude makes a confident change that breaks three files, git checkout . is the difference between a five-second undo and twenty minutes of un-asking.

What the repo actually buys you:

• Undo that works. Revert a bad change without arguing with the model about what it just did.
• Branches per feature. Keep half-finished work off main.
• Deploy previews. Vercel and friends hand you a URL per branch.
• CLI integration. Claude can open issues and PRs through the gh tool instead of you context-switching to the browser.

Create it in one line. I ran this on the machine I'm writing from. gh reports version 2.94.0:

gh repo create my-project --private --clone
cd my-project

This is the step everyone treats as boring and then loses an hour to. Claude can't call Stripe without a Stripe key. It will happily write the integration, run it, and hand you a 401.

Ask Claude to scaffold the template for your exact stack instead of hunting through five docs sites:

"Generate a .env.example file for a Next.js app using Clerk auth,
Convex database, Stripe payments, and Resend email."

You'll get something like:

# Authentication (Clerk)
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_...
CLERK_SECRET_KEY=sk_test_...

# Database (Convex)
CONVEX_DEPLOYMENT=dev:your-deployment-id
NEXT_PUBLIC_CONVEX_URL=https://your-deployment.convex.cloud

# Payments (Stripe)
STRIPE_SECRET_KEY=sk_test_...
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_...

# Email (Resend)
RESEND_API_KEY=re_...

Copy that to .env.local, fill in the real values, and add .env.local to .gitignore before your first commit. The committed file is .env.example with empty values. The filled one never leaves your machine. Reverse those two and you've published your secret keys to a public repo. It happens constantly.

This is the one that matters most. A CLAUDE.md is a plain markdown file at your repo root that Claude Code reads automatically at the start of every session. It is the persistent memory the model otherwise doesn't have.

Without it, you re-explain your project every time. With it, Claude already knows your stack, your rules, and the three things you never want it to do.

What to put in it:

• What you're building and why. One paragraph.
• Stack and architecture. The actual choices, named.
• Hard rules. "Never push directly to main." "Use the logger, not console.log."
• Conventions. Branch names, commit format, where files live.
• Commands. Build, test, deploy. The exact strings.

Keep it tight. The file I work in daily on this project is 167 lines, and most of that is hard rules and command references, not prose. Long CLAUDE.md files get skimmed by the model the same way long onboarding docs get skimmed by humans.

A skeleton to start from:

# My Project — Claude Code Guide

## Stack
- Next.js 15, TypeScript, Tailwind, shadcn/ui
- Database: Convex
- Auth: Clerk
- Payments: Stripe

## Key Rules
- Use cn() for className merging
- Use lib/logger.ts, not console.log, in production code
- Validate all mutation inputs
- Never commit .env files

## Commands
- npm run dev      — start dev server
- npm run typecheck — TypeScript validation
- npm run test:safe — run tests with cleanup

One tip that keeps it maintainable: link out instead of duplicating. If you have an architecture.md, reference it from CLAUDE.md rather than pasting it in. The file stays short, and the model follows the link when it needs the detail.

• Next.js 15, TypeScript, Tailwind CSS, Shadcn UI
• Database: Convex (modest-lobster-37)
• Auth: Clerk
• Payments: Stripe

• Use cn() for className merging
• Use lib/logger.ts not console.log in production code
• All mutations must validate inputs with Zod
• Never commit .env files

• npm run dev — start dev server
• npm run typecheck — TypeScript validation
• npm run test:safe — run tests with cleanup

Once a project outgrows a single CLAUDE.md, you want a few living docs that Claude updates itself instead of you remembering to. Three earn their keep:

1. architecture.md — system design and how the pieces connect.
2. changelog.md — what changed, in plain entries.
3. A status doc — current milestones and where the last session stopped.

The trick is to write the instruction once, in CLAUDE.md, so the model knows the routine:

After completing any feature:
1. Update architecture.md if the system design changed
2. Add an entry to changelog.md
3. Update the status doc with current progress

Better still, wrap that in a slash command (Step 7) so it's one keystroke instead of a paragraph you retype. This is the step you can safely skip on a weekend project and absolutely should not skip on anything you'll come back to in a month.

Plugins add prebuilt commands and workflows to Claude Code so you're not rebuilding common ones by hand. A few worth a look:

• A frontend plugin for cleaner UI component generation.
• A feature-dev plugin that gives you a structured plan-build-test loop.
• Compound-engineering utilities for ongoing codebase cleanup.

Open the browser with:

/plugins

Search, preview, install. This is the lowest-stakes step on the list. Install one, see if you reach for it, add more only when you feel a gap. Don't install ten on day one because a blog told you to.

MCP (Model Context Protocol) servers connect Claude Code to tools outside the chat: your database, a browser, your deploy platform. Think of each one as a bridge to an API you already use.

Pick servers that match your stack:

| Use case | MCP server | What it does |

|---------------------|-----------------------------|--------------------------------------|

| Database | Supabase / MongoDB MCP | Query and inspect schema directly |

| Browser / testing | Playwright or Chrome DevTools MCP | Drive a real browser, verify UI |

| Deployment | Vercel MCP | Manage deploys and preview URLs |

| Project management | Linear MCP | Read and update tickets |

You wire them up in a .mcp.json at the project root. Here is a real one. This is the actual file from the repo I'm writing in, lightly trimmed. Each server is a stdio command Claude launches:

{
  "mcpServers": {
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@playwright/mcp"]
    }
  }
}

One gotcha that cost me real time: if a server's command is a node binary, use the absolute path (/home/you/.nvm/.../bin/node), not bare node. Under some launchers the bare command silently resolves to the wrong version and the server just never starts, with no error you'd notice. Start with one server that matches your stack and add the rest as you need them.

This is where setup starts paying you back every day. A slash command is a saved prompt you trigger with /name. A sub-agent is a separate worker Claude can hand a job to in its own context.

Built-in commands cover the basics:

/commit   — generate a commit message and commit
/pr       — open a pull request with a summary

The payoff is the custom ones. Drop a markdown file at .claude/commands/update-docs.md:

Review all recent changes and update:
1. architecture.md — if system design changed
2. changelog.md — add an entry for this feature
3. The status doc — update milestones and progress
Commit the documentation updates.

Now /update-docs does all of that in one keystroke. This is not theoretical. The repo I'm working in has 27 command files in .claude/commands/ and 15 sub-agents defined in .claude/agents/. They started as one or two and grew because each one paid for itself the second time I'd have typed the same paragraph.

Sub-agents are the heavier tool. A changelog agent, a test-runner agent, a retro agent that reads past sessions. Reach for them when a task is big enough to deserve its own context window. Most projects don't need them on day one. Most projects do eventually want at least one.

If you do all seven, your sessions stop starting from zero. But you won't always have time for all seven, so here's the honest ranking.

Number three, the CLAUDE.md, is the one that matters most by a wide margin. The repo (Step 1) protects you when Claude is wrong. The CLAUDE.md keeps Claude from being wrong in the first place, every session, automatically. Skip MCP servers and slash commands on a small project and you'll barely notice. Skip the CLAUDE.md and you'll feel it on the very next prompt, because you'll be explaining your stack again.

So if you take one thing from this: open a file called CLAUDE.md, write your stack and three hard rules, and save it before you write a single prompt. The other six can wait until the project earns them.