Getting started with Claude Code in a repository

The first 30 minutes with Claude Code in a new repo shape how it’s going to work for the rest of the project. It’s worth following this list in order, because some steps depend on earlier ones; others can be done in parallel. Each item links to the article that explains it in detail.

1. Run /init so Claude analyzes the repo and generates an initial CLAUDE.md (Memory and context). Don’t leave it as-is: it’s a starting point, not a finished product.
2. Prune that CLAUDE.md down to the essentials. Cut everything Claude would already know on its own and keep only the exact commands, your own conventions, and the project’s traps. Aim to stay under ~200 lines (Memory and context).
3. Separate the personal from the shared. Your own preferences (not the team’s) go in CLAUDE.local.md, and that file goes in .gitignore before the first commit.
4. Choose the starting permission mode. In a repo you don’t know yet, start in default (or plan if you’re going to do a big exploration before touching anything). Move up to acceptEdits only once you trust what it’s doing (Permissions in Claude Code).
5. Write the non-negotiable deny rules before writing a single line of code: at minimum, .env, credentials, and any sensitive infrastructure folder (Read(./.env), Edit(/src/db/migrations/**), etc.) (Permissions in Claude Code).
6. Decide your MCP policy. Which servers does this particular project need? Which go in --scope project so the whole team uses them, and which stay in --scope local because they’re experimental or yours? (MCP).
7. Add the minimum-hygiene hooks, if the project already has a linter/formatter: a PostToolUse that runs prettier/eslint --fix after every Edit/Write saves you from asking for it by hand in every prompt (Skills, subagents, and hooks).
8. Run /security-review once, even if the project already exists. It gives you an initial snapshot of which vulnerabilities were already there before Claude Code touched a single line — useful for not later attributing to it something that predated it (Security when working with Claude Code).
9. Set the project’s default model if your team has a preference (for example, Sonnet for everything except a security review subagent on Opus) (Essential commands and shortcuts).
10. Commit the shared configuration (CLAUDE.md, .mcp.json, .claude/settings.json, .claude/rules/) so the rest of the team starts with the same behavior — and so it’s in the history if something has to be reverted.

If the project is large enough that “what does done mean” isn’t obvious at a glance, this is also the moment to evaluate whether it’s worth adding Spec-Driven Development before the first big feature, rather than after the third.