Block destructive commands with PreToolUse hooks Block rm -rf, drop table, and truncate patterns with a PreToolUse hook on Bash. Claude won't even try. The hook fires before Claude executes the tool, so destructive commands get caught before they cause damage. json { "hooks": { "PreToolUse": [ { "matcher": "Bash", "type": "command", "command": "if echo \\\\"$TOOL_INPUT\\\\" | grep -qE 'rm -rf|drop table|truncate'; then echo 'BLOCKED: destructive command' >&2; exit 2; fi" } ] } } Add this to .claude/settings.json in your project. You can set it up interactively with /hooks, or just tell Claude: "Add a PreToolUse hook that blocks rm -rf, drop table, and truncate commands." 41. Preserve important context across compaction with hooks When context compacts during long sessions, Claude can lose track of what you're working on. A Notification hook with a compact matcher automatically re-injects your key context every time compaction fires. Tell Claude: "Set up a Notification hook that after compaction reminds you of the current task, modified files, and any constraints." Claude will create the hook in your settings. Good candidates for re-injection: the current task description, the list of files you've modified, and any hard constraints ("don't modify migration files"). This is most valuable during multi-hour sessions where you're deep in a feature and can't afford Claude losing the thread. 42. Always manually review auth, payments, and data mutations Claude is good at code. These decisions need a human. Auth flows, payment logic, data mutations, destructive database operations. Review these regardless of how good the rest looks. A wrong auth scope, a misconfigured payment webhook, or a migration that drops a column silently can cost you users, money, or trust. No amount of automated testing catches every one of these. 43. Use /branch to try a different approach without losing your current one /branch (or /fork) creates a copy of your conversation at the current point. Try the risky refactor in the branch. If it works, keep it. If it doesn't, your original conversation is untouched. This is different from rewind (#3) because both paths stay alive. 44. Let Claude interview you when you can't fully spec a feature You know what you want to build, but you feel like you don't have all the details Claude needs to build it well. Let Claude ask the questions. markdown I want to build [brief description]. Interview me in detail using the AskUserQuestion tool. Ask about technical implementation, edge cases, concerns, and tradeoffs. Don't ask obvious questions. Keep interviewing until we've covered everything, then write a complete spec to SPEC.md. Once the spec is done, start a fresh session to execute with clean context and a complete spec. 45. Have one Claude write, another Claude review First Claude implements the feature, second Claude reviews from fresh context like a staff engineer. The reviewer has no knowledge of the implementation shortcuts and will challenge every one of them. Same idea works for TDD. Session A writes tests, Session B writes the code to pass them. 46. Review PRs conversationally Don't ask Claude for a one-shot PR review (although you can if you want). Open the PR in a session and have a conversation about it. "Walk me through the riskiest change in this PR." "What would break if this runs concurrently?" "Is the error handling consistent with the rest of the codebase?" Conversational reviews catch more issues because you can drill into the areas that matter. One-shot reviews tend to flag style nits and often miss the architectural problems. 47. Name and color-code your sessions /rename auth-refactor puts a label on the prompt bar so you know which session is which. /color red or /color blue sets the prompt bar color. Available colors: red, blue, green, yellow, pu