How to Use Claude Code: A Practical First Week

To use Claude Code, install it, open a terminal in your project, run claude, sign in, and describe what you want in plain English: Claude reads the files it needs, edits them and runs commands, asking first when your permission mode says so (quickstart). The rest of a first week is setup that makes it dependable: a CLAUDE.md, a deliberate permission mode, plan mode for big edits, subagents for parallel work and independent checks, memory for corrections, hooks for hard rules and a human approval on every push. Each piece was checked against the official docs on October 3, 2026, with how it works on this blog.

How do you install Claude Code and run a first session?

On macOS, Linux or WSL the recommended native installer is one command. Windows uses irm https://claude.ai/install.ps1 | iex in PowerShell, and Homebrew and WinGet packages exist too (install).

curl -fsSL https://claude.ai/install.sh | bash
claude --version
cd /path/to/your/project
claude

The first run opens a browser login. You need a Pro, Max, Team, Enterprise or Console account, or a cloud provider such as Amazon Bedrock; the free claude.ai plan does not include Claude Code (authenticate). Start with a question such as "what does this project do?", then a small change. Run /clear between unrelated tasks (manage context) and claude -c to continue the last conversation in that folder (commands).

How do you tell Claude what done looks like?

Give it a check it can run: a test, build, linter or screenshot that returns pass or fail, because "Claude stops when the work looks done" and without a check you become the verification loop (verify its work). Name the file, the scenario and what fixed looks like, as in "write a failing test that reproduces the issue, then fix it" (specific context). On this blog every draft gets two checks: a content linter and a render in a real browser at desktop and phone width.

What goes in CLAUDE.md?

The facts you would otherwise repeat (what to put in CLAUDE.md). Claude reads it at the start of every session: ~/.claude/CLAUDE.md for your own preferences across projects, ./CLAUDE.md for the project, shared through git (CLAUDE.md files). Run /init for a starter, then keep it under the 200 lines the docs suggest, with instructions concrete enough to verify, such as "Run npm test before committing" instead of "Test your changes". A multi-step procedure belongs in a skill instead, like the ones in skills I wrote from agent mistakes.

My personal file holds working rules: the language I talk in, never commit or push without my explicit approval, no AI attribution in commits. The project file holds this site's positioning and copy rules and imports AGENTS.md with an @AGENTS.md line, as the docs describe for files shared with other tools (share one file). Run /context to see what loaded.

Which permission mode should you start in?

Know which one you are in. With v2.1.283 or later, interactive terminal and VS Code sessions start in auto mode by default, where a separate classifier model reviews actions instead of you (which mode a session starts in). In Manual mode, config value default, Claude Code stops and asks before most actions that edit files, run shell commands or reach the network. The docs warn that auto mode "reduces permission prompts but does not guarantee safety" (auto mode). On an unfamiliar codebase I would start with claude --permission-mode default (common setups) and switch with Shift+Tab once the pattern is clear. /permissions lists every allow, ask and deny rule and the file it came from (manage permissions).

When should you use plan mode?

Before a change that touches several files or that you are unsure how to approach (plan mode, in detail). In plan mode Claude reads files, runs commands to explore and writes a plan, but does not edit your source until you approve it (plan mode). Enter it with Shift+Tab until the status bar shows ⏸ plan mode on, start with claude --permission-mode plan, or begin a single prompt with /plan. Ctrl+G opens the plan in your editor before you approve it. The docs' rule for skipping it: if you could describe the diff in one sentence, skip the plan (explore, plan, code).

What are subagents for?

Two jobs: work that would flood your conversation, and checks that should not come from the agent that did the work. A subagent runs in its own context window and returns a summary, so "Research the authentication, database, and API modules in parallel using separate subagents" keeps the main session clean (parallel research). For checks, the docs recommend a reviewer subagent that sees only the diff and your criteria, not the reasoning behind it; the bundled /code-review skill does this for bugs (adversarial review).

This blog runs on the second job: one writer agent per article, an independent fact-checker that re-reads the official docs and fixes or cuts claims, editor passes, and a render check. One run on October 2, 2026 used 32 agents to write 13 manuals, tighten 5 drafts and render-check 20 pages. A fact-checker caught an outreach finding, a site sending consent "denied" with no banner, that was true only because the check ran from Bulgaria; Wix sets denied only for EU visitors. More in subagents that verify work and a coordinator, workers and a verifier.

How do you make a correction stick?

Ask Claude to remember it (how memory works). Auto memory, on by default in local sessions, holds notes Claude writes from your corrections: a MEMORY.md index plus one file per memory in ~/.claude/projects/<project>/memory/, with the first 200 lines or 25KB of the index loaded every session (auto memory). "Remember that ..." saves to auto memory, "add this to CLAUDE.md" saves to the file you own, and /memory opens both. My saved rules include running the dev server on port 3100 and never 3000, requesting recrawls after every deploy, checking consent from a non-EU location, and writing manuals without filler. That last one came from early drafts I rejected as padded; the fix became a fixed manual format and a saved rule.

What about rules that must never be skipped?

Move them out of prose. The docs say Claude treats CLAUDE.md and auto memory "as context, not enforced configuration" (CLAUDE.md vs auto memory), while hooks are commands Claude Code runs at fixed points so the action always happens (hooks guide). Claude can write one, such as "Write a hook that runs eslint after every file edit", and /hooks shows what is configured (set up hooks). My rules live in scripts/content_lint.py, which fails the run on em dashes, links to removed or missing pages, over-long titles, repeated FAQ questions and banned phrasing. Claude Code hooks shows how I would wire it.

How do you keep a human approval on every push?

Make it a permission rule, not a sentence in a prompt. An ask rule prompts you even in a mode that would otherwise approve the call, such as acceptEdits or bypassPermissions (permissions.ask), and no mode auto-approves a tool an explicit ask rule matches (actions no mode auto-approves). Put this in .claude/settings.json or ~/.claude/settings.json:

{
  "permissions": {
    "ask": ["Bash(git push *)"]
  }
}

The rule matches commands that begin with git push; a push written another way, such as git -C . push, isn't matched (wildcard patterns). A "don't push" typed in chat does make auto mode block a push, but the docs say it can be lost when compaction removes that message (boundaries). On this blog I approve every commit and every push, and agents never push on their own.

Where to go from here

The pattern holds at any scale: instructions in CLAUDE.md, checks that a script or a second agent runs, and a person on the release. How those layers fit together is in the guardrails I put around agents that write for this site.