A collection of 52 posts
When a check fails, do not ask Claude Code to “fix it.” Paste the exact failure, freeze the scope, request one hypothesis, and make the next patch prove that signal changed.
Read more
When you paste the same review or verification prompt for the third time, promote it into a project slash command with allowed tools, arguments, and a checklist tied to real evidence.
Read more
Before Claude Code edits a busy file, make it state the file contract: responsibilities, callers, invariants, side effects, and proof commands. Then review the patch against that contract.
Read more
Use /clear when a Claude Code session has accumulated wrong assumptions, failed fixes, and stale logs. Restart with a clean brief, not a clean memory.
Read more
Before asking Claude Code to fix a bug, capture the exact repro path, command output, expected behavior, and one failed attempt. A repro transcript turns a vague debugging session into a focused loop.
Read more
Make Claude Code keep a rollback note next to the git diff: what changed, how to undo it, what proof is missing, and when to revert instead of piling on fixes.
Read more
Before Claude Code makes another patch, define the signal that forces it to stop: a repeated failing test, an unexplained log line, a widened diff, or evidence that the first theory was wrong.
Read more
Use Claude Code permissions as a deliberate safety gate: approve boring inspection, pause before destructive commands, and turn risky operations into reviewed checkpoints.
Read more
Use /mcp as a Claude Code preflight: audit connected tools, name what the session can prove, and turn missing access into concrete verification checks.
Read more
Before you type claude, choose the repository that can prove the work: the code path, the focused tests, the logs, and the deploy command. The right cwd is a verification decision, not a convenience.
Read more