Claude Code cheatsheet

CLAUDE.md, /clear, plan mode, and the rest of the Claude Code habits the course uses, all on one page

This page summarises the small set of commands and habits to remember. We will add to it during the semester, so check back rather than reading it once. For installation and authentication, see onboarding.

Starting a session#

cd into the repo first, then run claude. The session’s context starts where you launch it, so launching from your home directory and then asking about a project somewhere else is the most common self-inflicted wound of week 1.

• Esc interrupts a response mid-flight — use it as soon as you see the agent heading somewhere you didn’t intend, rather than waiting politely for it to finish
• /help lists the built-in commands; /comp4020:help lists the course skills
• the comp4020: prefix is the plugin’s namespace, and dropping it can bite: /doctor is Claude Code’s own health check while /comp4020:doctor checks your course setup, so the unprefixed one may report all-clear while your key, org membership and crit group are still unset
• you rarely need memorised commands: describe the outcome you want and let the agent pick the mechanism

The working loop#

For anything larger than a one-line change, use the same loop:

1. explore — ask how the relevant part of the repository works and which files implement it
2. plan — settle the intended change, its boundaries and how it will be verified
3. implement — make one bounded change
4. verify — inspect the diff, run the checks and use the rendered artefact

Planning is overhead. Ask directly if you can describe the diff in one sentence and review it at a glance. Plan when the code is unfamiliar, the change crosses several files or you are unsure of the approach.

Ask for evidence at the end: the command and its output, the diff, and what the agent observed in the running artefact. “Done” is still a claim.

CLAUDE.md#

The standing rules the agent reads every turn. A project-level CLAUDE.md in the repo root contains the codebase’s commands, constraints and conventions. A global one at ~/.claude/CLAUDE.md contains your preferences across every project.

Everything in there consumes context on every turn. Include rules you need often, especially those you repeatedly type into the chat.

/clear#

The fresh start. /clear discards the conversation and begins a new one in the same directory, keeping your CLAUDE.md and losing everything else.

Reach for it when a session has gone weird — the agent is looping, defending an earlier mistake, or still working from something you corrected twenty turns ago. Failed attempts remain in a long session’s context and can affect later responses, so clearing and re-briefing usually works better than arguing. The reasoning underneath this, and what to do besides clearing, arrives in week 4.

Interrupt, rewind, or revert#

Use Esc as soon as the work heads in the wrong direction. The conversation is preserved, so explain the correction and continue.

Press Esc twice or run /rewind to return to an earlier Claude Code checkpoint. Checkpoints cover conversation state and edits made through Claude’s editing tools; they do not replace git. Use git when the repository history is the source of truth, especially after commands or other programs changed files.

Continue or resume#

Use claude --continue to reopen the most recent session and claude --resume to choose an earlier one. A resumed session should still be one coherent workstream. Clear the context or start a new session when the job changes.

Model and effort#

/model picks the model for the session and /effort picks its reasoning budget. Use the pickers rather than memorising a list that will change.

Both are cost levers, and your course credits are capped weekly. Keep the model’s default for ordinary work; lower it for short, scoped jobs where speed and cost matter more, and raise it deliberately for hard debugging. Running a heavy model at high effort on a one-line fix is how a week’s allowance can be consumed before the crit. /comp4020:balance reports your usage, and the LLM access page covers the allocation itself.

Plan mode#

Have the model plan before it builds. Plan mode restricts the agent to reading and proposing, making no edits until you accept the plan. You can therefore correct a misread task before it changes any files.

Use it when the code is unfamiliar, the change crosses several files or you are unsure of the approach. For a change you can describe and review at a glance, ask directly. This is the informal version of the practice covered in week 2, when you start interrogating the brief and spec before you build.

Permissions#

Permissions are part of the harness. Approve a capability because its scope is appropriate, not because the prompt has become annoying. Prefer narrowly allowing repeatable project commands such as the test or build script. The software and platforms page sets the course policy for broader modes.