The Claude Code cheat sheet from our agency builds: setting it up inside your repos, a CLAUDE.md that holds each client’s code standards, the commands worth knowing in week one, and how to go from a client brief to a working prototype. This page is a two-minute summary; the pages after it go into detail and include files you can copy.
Sign in with a business seat for client code: Team Standard seats include Claude Code, and under commercial terms Anthropic doesn’t train on your code or prompts.
Shift+Tab cycles how much it does without asking:
/compact keep the API decisions.@briefs/spring.md.!npm test./review is now an alias./init in one client repo, then spend twenty minutes cutting and correcting what it wrote. That file does more for quality than any prompt.Team Standard seats include Claude Code; Premium seats carry about five times the usage, so give those to the one or two people who live in it. Under commercial terms Anthropic doesn’t train on code or prompts unless you opt in.
Terminal, the VS Code or JetBrains extension, or the desktop app for parallel sessions. They all read the same CLAUDE.md and settings, so the standards travel.
Standards, permissions, connectors and history never mix between clients. In a monorepo, give each client folder its own CLAUDE.md.
/init, then edit the resultIt writes what it can infer. Cut what’s obvious from the code, add what isn’t: the client, the quality bar, the never-touch list. Every line loads into every session, so keep it short.
.claude/settings.jsonAllow the boring commands, ask before a push or a new dependency, deny reads of secrets, and every developer inherits the rules. A Read deny doesn’t stop a cat in the shell; the hook in A2 does.
Put them in a committed .mcp.json with tokens read from environment variables, never pasted in. Write one line per server on what it can change: GitHub can open PRs and comment, your tracker can move tickets.
{ "mcpServers": { "github": { "type": "http", "url": "https://api.githubcopilot.com/mcp/",
"headers": { "Authorization": "Bearer ${GITHUB_PAT}" } } } }
/init, the settings file from A2 and GitHub over MCP. One afternoon.| Layer | Where it lives | Shared? | What goes in it |
|---|---|---|---|
| Agency-wide | ~/.claude/CLAUDE.md per person, or a managed policy file IT pushes to every machine | Managed: yes | The non-negotiables: no secrets, branch and PR rules, how you write commits. |
| Per client | ./CLAUDE.md at the repo root | Committed | The client’s standards. Template in A1. |
| Personal | CLAUDE.local.md | Gitignored | Your local URLs, sandbox accounts, how you like to work. |
| Path rules | .claude/rules/*.md with paths: | Committed | Rules that only load for part of the code, such as blocks or tests. |
---
paths:
- "src/blocks/**/*.{js,jsx,php}"
---
Every block has a block.json, an editor preview
and a save() that matches the front end exactly.
@docs/brand.md.A spring-campaign landing page, on a repo already set up as in 02 and 03. The prompts are the ones we use; swap in your paths. Most of the quality is decided in the first two steps.
Switch to plan mode (Shift+Tab or /plan) so nothing changes yet.
Correct it in plain words, then accept it to leave plan mode.
Small commits make /rewind and review easy.
A subagent reads the diff with fresh context and CLAUDE.md as the standard (sample in A3).
Your host builds the preview (Vercel, Netlify, WP Engine, Pantheon); Claude opens the PR.
A skill, so every handover reads the same (A3).
wp-env, with the theme and custom plugins in git. Push through staging; Claude never gets production credentials.--dry-run first.theme.json.block.json and an editor preview.## WordPress - Local only: `npx wp-env start`, site at http://localhost:8888. Never connect to production. - Theme: block theme in wp-content/themes/[client]. Styles go in theme.json first, CSS last. - Blocks: src/blocks/[name], built with @wordpress/scripts (`npm run build`). - Follow WordPress Coding Standards; run `composer run phpcs` before every commit. - Escape on output (esc_html, esc_attr, esc_url), sanitize on input, a nonce on every form. - WP-CLI: `--dry-run` first, on a local copy. - Never edit: WordPress core, third-party plugins, wp-config.php.
CLAUDE.md client standards (A1)
.mcp.json GitHub, tracker, Figma
.claude/
settings.json permissions + hooks (A2)
rules/ path-scoped rules
skills/
new-landing-page/SKILL.md
qa-pass/SKILL.md
client-handover/SKILL.md (A3)
agents/
reviewer.md (A3)
a11y-auditor.md
hooks/
protect-env.sh (A2)
block-push-main.sh (A2)
SKILL.md; anyone runs it as /qa-pass. Custom commands have been merged into skills, so start here..env edits, block pushes to main.claude -p runs one prompt with no chat; the GitHub Action (anthropics/claude-code-action@v1, set up with /install-github-app) reviews PRs when someone mentions @claude.{
"extraKnownMarketplaces": {
"agency": {
"source": { "source": "github",
"repo": "your-agency/claude-kit" }
}
},
"enabledPlugins": { "client-kit@agency": true }
}
claude -p "Run the qa-pass skill on main and write the findings to qa-report.md" \ --allowedTools "Read,Grep,Glob,Write,Bash(npm run *)" \ --output-format json | jq -r '.result'
“Claude treats CLAUDE.md files as context, not enforced configuration.”Claude Code docs, Memory
/usage weekly per person, so a runaway loop shows up before the invoice does./security-review before merging anything that touches auth, payments or personal data.Skills make a job repeatable when a person starts it. An agent holds the role: it watches for the trigger, does the job through your tools and comes back to a person where judgment counts. Client onboarding and the lead pipeline are where most agencies feel it first.
It’s ready when it runs every week, its inputs and outputs are clear, and a skill for it has run cleanly for a month.
# [Client] · [project] ## Client and project - [Client]: [what they do]. Contact: [name, role]. - Building: [what], live at [URL], staging at [URL]. - Account lead [name] · tech lead [name]. ## Stack - [Framework and version, e.g. Next.js 16 or a WordPress block theme] - Node [22], [pnpm]. Ask before adding a dependency. ## Commands - Install `[pnpm install]` · Dev `[pnpm dev]` · Build `[pnpm build]` - Lint `[pnpm lint]` · Types `[pnpm typecheck]` · Test `[pnpm test]` ## Conventions - [Components in src/components, one per file, named exports] - [Styles: design tokens only, no hard-coded colours or spacing] - Copy the pattern in the nearest similar file before inventing one. ## Brand - Tokens: @docs/brand-tokens.md (as text, not the PDF) - Placeholder copy in the client's voice, [three words]. Never lorem ipsum. ## Quality bar - Browsers: [last 2 versions of Chrome, Safari, Firefox, Edge; iOS 17+] - Accessibility: WCAG 2.1 AA. [Ontario client with 50+ staff: AODA applies.] - Performance: [LCP under 2.5s on mobile for key pages] ## Deploy - Branch, PR, preview, [named reviewer] approves, merge; [host] deploys main. - Never push to main. Never deploy from a laptop. ## Never touch - .env*, secrets/, [infra/], [legacy/ (the client's team owns it)] - [Generated files, vendor code, third-party plugins] - Production data or credentials, ever. ## Definition of done - Lint, types and tests pass; new logic has a test. - Checked at 375px and 1440px; meets the accessibility target. - PR says what changed, what's placeholder and how to check it. ## Handover notes - [What the client's team needs: CMS fields, editor guide, env var names] - Run /client-handover before any handover.
Deny rules stop Claude’s file tools; the hooks catch the same things in the shell and block them in every permission mode. Hooks need jq, and test them on a scratch repo before you rely on them.
{
"permissions": {
"allow": [
"Bash(npm run lint)", "Bash(npm run test *)", "Bash(npm run build)",
"Bash(git status)", "Bash(git diff *)", "Bash(git log *)",
"Bash(git switch -c *)", "Bash(git add *)", "Bash(git commit *)"
],
"ask": ["Bash(git push *)", "Bash(npm install *)", "Bash(composer require *)"],
"deny": [
"Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)",
"Edit(./.env)", "Edit(./.env.*)", "Edit(./secrets/**)",
"Bash(git push --force *)", "Bash(rm -rf *)"
]
},
"hooks": {
"PostToolUse": [
{ "matcher": "Edit|Write",
"hooks": [{ "type": "command",
"command": "jq -r '.tool_input.file_path' | xargs npx prettier --write --ignore-unknown" }] }
],
"PreToolUse": [
{ "matcher": "Edit|Write|Bash",
"hooks": [{ "type": "command",
"command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-env.sh" }] },
{ "matcher": "Bash",
"hooks": [{ "type": "command",
"command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-push-main.sh" }] }
]
}
}
#!/usr/bin/env bash # Exit 2 blocks the tool call; stderr goes back to Claude. INPUT=$(cat) TARGET=$(echo "$INPUT" | jq -r \ '.tool_input.file_path // .tool_input.command // empty') if echo "$TARGET" | grep -Eq '(^|[/[:space:]])\.env(\.|$|[[:space:]])|secrets/'; then echo "Blocked: .env and secrets/ are off limits." >&2 exit 2 fi exit 0
#!/usr/bin/env bash INPUT=$(cat) CMD=$(echo "$INPUT" | jq -r '.tool_input.command // empty') CWD=$(echo "$INPUT" | jq -r '.cwd') echo "$CMD" | grep -Eq 'git( -C [^ ]+)? push' || exit 0 BRANCH=$(git -C "$CWD" rev-parse --abbrev-ref HEAD 2>/dev/null) if [ "$BRANCH" = "main" ] || \ echo "$CMD" | grep -Eq '[[:space:]:](main|master)([[:space:]]|$)'; then echo "Blocked: open a PR instead of pushing to main." >&2 exit 2 fi exit 0
Make both scripts executable: chmod +x .claude/hooks/*.sh. The env hook also catches shell commands that mention .env, so expect it to stop a cat .env as well as an edit.
---
name: client-handover
description: Write HANDOVER.md for a client build.
Use when a prototype or project is ready to hand
to the client's team or another developer.
argument-hint: [audience, e.g. client dev team]
disable-model-invocation: true
---
Write HANDOVER.md at the repo root for $ARGUMENTS.
1. Read CLAUDE.md, the README, the open PR and
`git log --oneline main..HEAD`.
2. Run the build and the tests. If either fails,
stop and tell me. Never hand over a broken build.
3. Write these sections in plain English, and
invent nothing:
- What was built: pages, components and
integrations, with paths.
- How to run it: install, dev, build, deploy.
Env vars by name only, never values.
- Decisions and why: anything a new developer
would otherwise undo.
- What's placeholder: copy, images, data and
credentials still to swap.
- Known issues and open questions, with owners.
- Accessibility and browser checks done, and
what wasn't checked.
4. Check every item under "Handover notes" in
CLAUDE.md is covered.
5. Show me the draft. Don't commit until I approve.
--- name: qa-pass description: QA the current branch against this client's CLAUDE.md before it goes to review. --- Run the reviewer and a11y-auditor subagents on this branch in parallel, with CLAUDE.md as the standard. Then run lint, types and tests. Fix what's clearly wrong. List the rest as a checklist in the PR description.
--- name: new-landing-page description: Plan and build a landing page from a client brief. argument-hint: [path to the brief] disable-model-invocation: true --- 1. Read $ARGUMENTS and CLAUDE.md. Ask me up to 5 questions about gaps. Wait for answers. 2. Propose a page map and components, reusing src/components. Wait for my approval. 3. Branch proto/[slug]. Build one section at a time, committing each. 4. Run the qa-pass skill, then open a draft PR.
--- name: reviewer description: Reviews a branch against this client's CLAUDE.md. Use after a build, before a PR. tools: Read, Grep, Glob, Bash model: sonnet --- Read CLAUDE.md first; it is the standard. Review the diff against main for the never-touch list, conventions, brand tokens, the accessibility and browser targets, tests for new logic, and any leaked secret or env value. Report each finding as file:line, what's wrong, why it matters and a suggested fix. Don't edit files.
SourcesClaude Code docs: setup, commands, interactive mode, memory, permissions, permission modes, checkpointing, hooks, skills, subagents, plugins for teams, MCP, headless, GitHub Actions, data usage · Claude Help Center, What is the Team plan? · Commands as of Claude Code v2.1, October 2026.
Thirty minutes, free. Bring a client brief and we’ll map how it goes from brief to prototype in Claude Code, and what to set up first across your team. If it’s not a fit, you’ll still leave with the plan.