The Claude Code commands and prompts that don't show up in the first week.
Session control
Undo the conversation and the files
/rewind
Most people know they can interrupt Claude. Fewer know they can un-happen the last twenty minutes. /rewind restores a checkpoint — the transcript and the file edits together — so a session that drifted into the wrong design goes back to the moment before it drifted.
The alternative is arguing with an agent whose context is now full of the bad approach, which almost never works. Rewind, rewrite the prompt with what you just learned, and run it again.
See what is actually eating the window
/context
When Claude starts forgetting decisions from earlier, the instinct is to blame the model. Usually the real answer is that a 4000-line log dump, three MCP servers and a giant CLAUDE.md are sitting in the window.
/context prints the breakdown by category. Once you can see it, the fix is obvious: drop the MCP server you are not using this session, trim the memory file, stop pasting whole files when a path would do.
Steer the compaction instead of accepting it
/compact keep the schema decisions and the auth constraints, drop the test output
Auto-compaction summarizes whatever it thinks matters. Given an argument, it summarizes what you think matters.
Run it deliberately before a long implementation phase, naming the decisions that must survive. It is the difference between coming out of a compaction with your architecture intact and coming out of it having to re-explain why you rejected Redis.
Turn the reasoning dial up
ultrathink about the race condition in the worker pool
Extended thinking is not a constant — you can ask for more of it. The word ultrathink in a prompt buys a deeper reasoning pass for the hard part of a task, and /effort xhigh or /effort max raises it for the whole session.
Use it where thinking actually pays: concurrency bugs, data model design, "why does this only fail in CI". Leave it low for boilerplate, where the extra tokens buy nothing.
Ask a side question without interrupting
/btw what does the retry logic in that file actually do?
Claude is mid-way through a refactor and you want to understand something it just touched. Typing a normal message derails the task; waiting means you forget the question.
/btw is single-turn, makes no tool calls, and has the full conversation in context. You get the answer, and the work in progress stays on track.
Review and quality
Append a quality pass to any change
hey claude make this code change then run /simplify
/simplify runs parallel agents over the code you just changed, looking for duplication, dead abstractions, inefficiency, and rules in CLAUDE.md that the diff quietly ignored.
Appending it to the original prompt matters more than running it later: the review happens while the reasoning behind the change is still in context, and the cleanup lands in the same diff instead of becoming a follow-up you never open.
Make it defend the change before you ship
Grill me on these changes and don't make a PR until I pass your test.
Inverting the review — Claude quizzes you instead of you quizzing Claude — surfaces the parts of a generated diff you were about to approve without understanding. If you cannot answer why a line is there, that is the line to look at.
A shorter variant for behaviour rather than comprehension: Prove to me this works. Ask it to diff actual behaviour between main and your branch, not to assert that the tests pass.
Ask for the second draft
Knowing everything you know now, scrap this and implement the elegant solution.
The first implementation is a discovery pass. It is where the real constraints, the awkward edge case and the missing requirement surface — which means it is written by a version of Claude that did not yet know any of them.
Throwing it away and asking for a clean implementation, now that the problem is fully understood, costs one prompt and routinely produces something half the size.
Memory that compounds
Turn every correction into a permanent rule
Update your CLAUDE.md so you don't make that mistake again.
The highest-leverage habit in vibe coding: never fix the same thing twice. Every time you correct Claude, end the message with this line. It is good at writing rules for itself, and it writes them in the form it will actually follow.
Keep CLAUDE.md at the repo root and check it into git, so the whole team's corrections accumulate in one place. Six weeks of this and the file is doing more work than any prompt you write.
Write the reason into the rule, not just the rule
Never use ellipses — this response is read aloud by a text-to-speech
engine that cannot pronounce them.
A bare NEVER use ellipses is a rule that covers exactly the case it names. The same rule with its motivation attached generalizes: Claude now also avoids em-dash pauses, ASCII art and anything else the TTS engine would mangle, without being told.
The same applies to your coding rules. Always use the repository layer is weaker than Always use the repository layer — direct ORM calls in views bypass our tenant filter and leak data across accounts. Explain why, and you get judgement instead of literal compliance.
Prompting
Ask for above-and-beyond explicitly
Create an analytics dashboard. Include as many relevant features and
interactions as possible. Go beyond the basics to create a fully-featured
implementation.
Create an analytics dashboard gets you a conservative, minimum-viable answer, because a short prompt reads as a small request. Claude does not assume you want the ambitious version unless you say so.
Treat it as a brilliant new hire who has no idea what your team considers "done". The golden rule from the docs: show your prompt to a colleague with no context — if they would be confused, so is the model.
Cap the over-engineering
Avoid over-engineering. Only make changes that are directly requested or
clearly necessary. Keep solutions simple and focused:
- Scope: Don't add features, refactor code, or make "improvements" beyond
what was asked. A bug fix doesn't need surrounding code cleaned up.
- Documentation: Don't add docstrings, comments, or type annotations to code
you didn't change.
- Defensive coding: Don't add error handling, fallbacks, or validation for
scenarios that can't happen. Only validate at system boundaries.
- Abstractions: Don't create helpers for one-time operations. Don't design
for hypothetical future requirements.
The most common complaint about generated code is not that it is wrong — it is that a three-line fix arrived as a new module, a config flag and a factory. Left unconstrained, models add flexibility nobody asked for.
Keep this block in CLAUDE.md rather than retyping it. It is the single biggest reduction in diff size you can make.
Ban hard-coding to the tests
Please write a high-quality, general-purpose solution. Implement a solution
that works correctly for all valid inputs, not just the test cases. Do not
hard-code values or create solutions that only work for specific test inputs.
Tests are there to verify correctness, not to define the solution. If the
task is infeasible or any of the tests are incorrect, tell me rather than
working around them.
Give an agent a red test suite and a strong instruction to make it green, and special-casing the test inputs is a legitimate-looking path to that goal. You end up with code that passes CI and fails on the first real request.
The last sentence is the important one. Explicit permission to say "this test is wrong" is what turns a workaround into a conversation.
Ground every answer in code it actually opened
<investigate_before_answering>
Never speculate about code you have not opened. If the user references a
specific file, you MUST read the file before answering. Investigate and read
the relevant files BEFORE answering questions about the codebase. Never make
claims about code before investigating.
</investigate_before_answering>
The dangerous failure mode is not a wrong answer, it is a confident and plausible one about a function that does something else entirely. Explicitly requiring a read before a claim converts speculation into a tool call.
Note the XML tags. Wrapping a standing instruction in a named block makes it unambiguously an instruction rather than part of the surrounding prose — and it survives compaction more reliably than a sentence buried in a paragraph.
Beyond the chat
Use Claude as a unix tool
git diff --staged | claude -p "write a conventional commit message" --bare
claude -p is headless: it reads stdin, writes stdout, exits. That makes it pipeable into git hooks, CI steps, xargs, or any script where you want a language model as one stage of a pipeline rather than a conversation.
--bare skips the usual discovery of CLAUDE.md files, settings and MCP servers, which is roughly 10x faster to start — exactly what you want for a one-shot call that needs none of it. Add --output-format=stream-json --verbose when a script needs to parse the result.