A daily English series sharing practical Claude Code tips, commands, and workflows.
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
Treat /apply as a review gate, not a keyboard shortcut: inspect pending changes, ask Claude what would prove them, apply only the coherent slice, then verify with tests and a diff.
Read more
Before Claude Code edits a dirty working tree, snapshot the starting diff, label what is already there, and make every later review separate your changes from the model’s patch.
Read more
Before Claude Code patches a bug, make it list competing hypotheses, evidence, checks, and the smallest next action. The table keeps debugging honest when the first theory sounds too convenient.
Read more
After Claude Code edits, make it trace every meaningful change back to the failing behavior, the file evidence, and the verification result before you accept the patch.
Read more
Before trusting a Claude Code plan or patch, ask it to name the files, runtime paths, logs, and assumptions it did not inspect. The unread list turns confidence into reviewable scope.
Read more
Use /ultraplan when the work is too large for a casual prompt: draft the plan separately, attack its assumptions, then bring back only a verified first slice.
Read more
After a feature works, run /simplify as a separate cleanup pass: preserve the proof, narrow the target, review the diff, and reject clever rewrites that change behavior.
Read more
Use Claude Code to decompose a vague GitHub issue into small, verifiable tasks before asking it to edit files.
Read more
When Claude Code deletes code, slow the session down: ask what each removal proves, which runtime path depended on it, and what verification would catch a bad cleanup.
Read more