Everything below is Claude Code configuration, not a separate product. The whole setup is files in your repo and your home directory.
Claude Code setup
Out of the box Claude Code re-learns your project every session and writes code against APIs as they existed in training. Five pieces of configuration fix that permanently. Each one is a file, most are free, and the whole setup runs on a $20/mo plan.
Fixes the most common failure: writing code against an API as it existed in the training data. One MCP server, free, and it removes a whole class of confident wrong answers.
The agent reads your real schema instead of inferring it from your types. Migrations stop being a copy-paste round trip through a dashboard.
The agent that wrote the code is the wrong reviewer. This reads the pull request cold, on GitHub, with no memory of the reasoning that produced it.
- claude-code$20
- context7$0
- supabase-mcp$0
- coderabbit$0 OSS
- claude-code$20
- context7$0
- supabase-mcp$0
- coderabbit$30
- claude-code$300 Max ×3
- context7$0
- supabase-mcp$0
- coderabbit$90
- 1CLAUDE.md, the file that stops repeated correctionsClaude Code
Claude Code reads CLAUDE.md at the start of every session. Anything you find yourself saying twice belongs in it. Project file is ./CLAUDE.md, personal preferences that follow you across every repo go in ~/.claude/CLAUDE.md, and ./CLAUDE.local.md is for machine-specific notes you do not want committed. It supports @imports up to four levels deep, so a repo that already documents itself in AGENTS.md can point at it rather than duplicating.
Prompt · A CLAUDE.md worth having# {{project name}} @AGENTS.md ## Things that bite - The middleware file is proxy.ts, not middleware.ts. - Content lives under content/, not lib/. lib/*.ts are thin loaders. - Before writing code against any library, look up its current docs with Context7. This applies even to libraries you know well: the API may have changed since training. Do not skip it because the change looks like a one-liner. ## Commands - npm run build runs the content index and logo manifest first. - Never run the dev server in the background without checking the port. - 2MCP servers, so it stops guessingContext7
MCP servers give the agent access to things outside your codebase. Scope decides who gets them: --scope local is the default and applies only to you in this project, --scope user follows you into every project, and --scope project writes .mcp.json at the repo root so your team inherits it on clone. For stdio servers the -- separator is mandatory, otherwise the flags are read as arguments to the server.
Prompt · Add the three worth having# Live docs, everywhere you work claude mcp add --transport http --scope user context7 https://mcp.context7.com/mcp # Your database, shared with the team via .mcp.json claude mcp add --transport http --scope project supabase https://mcp.supabase.com/mcp?project_ref={{your_ref}} # A stdio server: note the -- before the command claude mcp add --transport stdio --scope user airtable -- npx -y airtable-mcp-server claude mcp list - 3Subagents, for work that would pollute the sessionClaude Code
A subagent runs in its own context and reports back a conclusion. That matters for anything that reads a lot and returns a little: a sweep across forty files ends with one answer in your session instead of forty files of transcript. Definitions live in .claude/agents/, name and description are required, and everything else is optional. The description is what decides when it gets picked automatically, so write it as a trigger rather than a title.
Prompt · .claude/agents/schema-check.md--- name: schema-check description: Use when a change touches database queries or types. Reads the live schema and reports mismatches. Does not edit files. tools: Read, Grep, Glob model: haiku --- Compare the query or type under discussion against the real database schema. Report only mismatches: a column that does not exist, a nullable column treated as non-null, a type that has drifted. If everything matches, say so in one line. Do not suggest refactors and do not edit files.
- 4Hooks, for the things you keep forgettingClaude Code
Hooks are shell commands the harness runs on events, configured under a hooks key in settings. They are the right tool for anything that must happen every time regardless of whether the agent remembered: formatting after an edit, a notification when a long run needs input. PostToolUse with a matcher on Write and Edit is the one most people want first.
Prompt · .claude/settings.json{ "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write" } ] } ] } } - 5Skills, for the prompts you keep retypingClaude Code
A skill is a markdown file whose body loads only when it is used, which is what makes it cheaper than putting the same instructions in CLAUDE.md. Project skills live in .claude/skills/<name>/SKILL.md and become /<name>. Custom commands in .claude/commands/ still work and produce the same slash command, but skills are the current shape: they support supporting files, path scoping, and being invoked automatically when the description matches.
Prompt · .claude/skills/ship/SKILL.md--- name: ship description: Run the pre-push checks this repo actually requires, in order, and report what failed. --- Run these in order and stop at the first failure: 1. npx tsc --noEmit 2. npm run lint 3. npm run build Report the failing output verbatim. Do not fix anything unless asked. If all three pass, say so and list what changed since the last commit.
aistack.sh is built with this setup. Its CLAUDE.md is one line that imports AGENTS.md, so the same file serves both. The Supabase and PostHog MCP servers are in the repo's .mcp.json at project scope, so they arrive on clone. A recent session used the analytics server to find five comparison pages ranking on page one with under 2% click-through, then rewrote their titles in the same sitting: the question and the fix in one place, which is the whole argument for wiring the servers up.
It is not a README. Nobody needs the project history or an architecture overview; the agent can read the code. What belongs there is the things it gets wrong: the file that is not where it looks, the command that needs a flag, the convention that contradicts the framework default. If a line has never prevented a mistake, delete it.
Every connected server spends context on tool definitions before you have typed anything. Three you reach for beat fifteen you installed from a list and forgot. Run claude mcp list monthly and remove what you have not used.
An agent will happily write code from memory with a live-docs server sitting right there. If you have not written the rule into CLAUDE.md, assume the server is not being consulted.
Start read-only. An agent that can run migrations unsupervised will eventually run one you did not want, and Postgres has no undo.
Asking the agent that wrote the code to review it produces agreeable answers. The reviewer has to be something that did not see the reasoning: a separate subagent at minimum, a separate product like CodeRabbit on the pull request ideally.
What changed in AI tools and the stacks that ship. One email a week.


