Claude Code

Claude Code is Anthropic’s agentic coding tool: it reads a repository, runs commands, edits files and checks its own work, in the terminal, IDE, desktop, web or CI. From v2.1.280 (the latest channel) it defaults to Claude Opus 5.5 on paid plans and the Anthropic API (per-provider defaults). The repository’s configuration and gates, not the model, make its output trustworthy.

This hub is for developers adopting Claude Code and tech leads standardising it. Typically the agent writes working code on day one, but each session rediscovers the build commands and you still read every diff.

What this Claude Code guide gives you

A first change from worktree to read-only plan to green gates, a permission mode per session type, and a verification stack so you check evidence rather than lines.

How do you ship a first verified change with Claude Code?

You need a Git repository with a clean working tree and a short spec committed at docs/specs/login-rate-limit.md; claude -w branches from the remote default branch, so push it too unless step 3 sets baseRef.

Install Claude Code and start it in the repository root (terminal):
Terminal window
```
curl -fsSL https://claude.ai/install.sh | bash
claude
```
Run /init to generate CLAUDE.md, then edit it until it names the exact typecheck, lint and test commands.
Commit the edited CLAUDE.md, then either push it to the default branch or set "worktree": { "baseRef": "head" } in .claude/settings.json so the new worktree starts from your current HEAD (version control).
Start a session in a new Git worktree, already in plan mode, which proposes but never edits: claude -w login-rate-limit --permission-mode plan. Paste the planning prompt. When the plan approval prompt appears, decline it, because approving lets Claude start implementing at once. Once the plan is right, press Shift+Tab to leave plan mode, ask Claude to write the plan to docs/plans/login-rate-limit.md and commit it on the worktree branch, then paste the build prompt.
Check the command list and exit statuses the build prompt reported, then run /code-review --fix for a second pass on the diff. Commit, push and open a PR; required checks and a reviewer gate the merge.

Read CLAUDE.md and docs/specs/login-rate-limit.md, then inspect the code that handles POST /api/login.
Propose an implementation plan: the files you will change, the tests you will write first,
the commands that prove the change (typecheck, lint, unit, integration), the risks, and how to roll back.
Do not edit any file. Stop and wait for my approval.

Implement milestone 1 of docs/plans/login-rate-limit.md and nothing else.
Write the failing tests first, then the code. Run every typecheck, lint and test command CLAUDE.md lists.
If a check fails, fix the implementation; never delete, skip or loosen a test.
Finish with: files changed, each command you ran with its exit status, and the risks you did not cover.

Which permission mode should a Claude Code session use?

Cycle with Shift+Tab or pass --permission-mode (choices in 2.1.283: acceptEdits, auto, bypassPermissions, manual, dontAsk, plan).

Mode	Use it for	Watch out for
`plan`	Discovery and planning	Switch modes to implement
Manual (`default`)	Unfamiliar repositories, work near secrets	Prompt fatigue: approving without reading
`acceptEdits`	Implementation inside a worktree with tests	File edits no longer ask first; commit often
`auto`	Starting mode for interactive terminal and VS Code sessions from v2.1.283 (`latest`); a classifier reviews each action	`claude -p`, the Agent SDK and unsupported models (Haiku, for one) start in Manual; project settings cannot enable it
`dontAsk`	Scripted runs where every tool is pre-allowed	Anything not in `permissions.allow` or `--allowedTools` is denied rather than prompted
`bypassPermissions`	A disposable, network-restricted sandbox only	Never on your main checkout or with production credentials

How do you know Claude Code’s output is right without reading every line?

Stack the checks so each layer enforces what the one above only asks for:

CLAUDE.md names the gates. It explains but does not enforce (memory and CLAUDE.md).
Hooks enforce. A hook can block a tool call or run the formatter after every edit, whatever the prompt says.
/code-review re-reads the diff (--fix or --comment).

CI re-runs the gates. Required checks repeat the gates; a read-only print-mode review adds a second opinion:

claude -p --permission-mode plan --output-format json \
  "Review the diff between origin/main and HEAD against docs/specs/login-rate-limit.md. Report only blocking findings, each with file, line, and the behaviour that fails."

A human signs off on evidence. The reviewer reads the evidence bundle, not every line (why evidence beats diffs).

What breaks first when you adopt Claude Code?

Every session relearns the repository. Cut CLAUDE.md to commands and rules; move long procedures into skills.
Claude edits before the plan is agreed. Plan in plan mode inside the worktree and commit the agreed plan before the build prompt.
Tests go green because they were weakened. Review the test diff first and add the checks in catching test weakening.
Parallel sessions collide. One worktree per task (claude -w) isolates files, not ports, databases or cloud resources.
Usage runs out mid-week. Check /usage and lower effort with /effort before switching model (cost control).

Where each part of the Claude Code guide lives

Section	Go there when you need to
Quick Start	Install, configure, set up MCP
Plan	Analyse a codebase, plan a feature
Build	Run the daily loop, manage memory
Test & Debug	Drive red-green loops, debug
Review & Ship	Automate review, wire CI/CD, deploy
Operate	Troubleshoot, control cost
Automate	Write hooks, subagents and skills
Team & Enterprise	Share configuration, run proxies and LLM gateways
Reference	Check the changelog and upgrade steps

Where to go next with Claude Code

Developers: installation, then features you haven’t tried.
Tech leads: team collaboration and the tech lead track.
Mixing tools: Cursor vs Claude Code and the tool map.