Tasks are session-scoped and expire after 3 days, so a forgotten loop won't run forever. Use /loop for monitoring deploys, watching CI pipelines, or polling an external service while you focus on something else. 23. Use voice dictation for richer prompts Run /voice to enable push-to-talk, then hold Space to dictate. Your speech transcribes live into the prompt, and you can mix voice and typing in the same message. Spoken prompts naturally include more context than typed ones because you explain the background, mention constraints, and describe what you want without cutting corners to save keystrokes. Requires a Claude.ai account (not API key). You can rebind the push-to-talk key to a modifier combo like meta+k in ~/.claude/keybindings.json to skip the hold-detection warmup. 24. After 2 corrections on the same thing, start fresh When you and Claude are going down a rabbit hole of corrections and the issue still isn't fixed, the context is now full of failed approaches that are actively hurting the next attempt. /clear and write a better starting prompt that incorporates what you learned. A clean session with a sharper prompt almost always outperforms a long session weighed down by accumulated dead ends. 25. Tell Claude exactly which files to look at Use @ to reference files directly: @src/auth/middleware.ts has the session handling. The @ prefix resolves to the file path automatically, so Claude knows exactly where to look. Claude can grep and search your codebase on its own, but it still has to narrow down candidates and identify the right file. Every search step costs tokens and context. Pointing Claude at the right files from the start skips that entire process. 26. Explore unfamiliar code with vague prompts "What would you improve in this file?" is a great exploration prompt. Not every prompt needs to be specific. When you want fresh eyes on existing code, a vague question gives Claude room to surface things you wouldn't have thought to ask about. I use this when onboarding onto an unfamiliar repo. Claude points out patterns, inconsistencies, and improvement opportunities that I'd miss on a first read. 27. Edit plans with Ctrl+G When Claude presents a plan, Ctrl+G opens it in your text editor for direct editing. Add constraints, remove steps, redirect the approach before Claude writes a single line of code. Useful when the plan is mostly right but you want to tweak a few steps without re-explaining the whole thing. 28. Run /init, then cut the result in half CLAUDE.md is a markdown file at the root of your project that gives Claude persistent instructions: build commands, coding standards, architectural decisions, repo conventions. Claude reads it at the start of every session. /init generates a starter version based on your project structure. It picks up build commands, test scripts, and directory layout. The output tends to be bloated. If you can't explain why a line is there, delete it. Trim the noise and add what's missing. For more on structuring these files, see how to write a great CLAUDE.md file. 29. The litmus test for every CLAUDE.md line For every line in your CLAUDE.md, ask: would Claude make a mistake without this? If Claude already does something correctly on its own, the instruction is noise. Every unnecessary line dilutes the ones that matter. There's roughly a 150-200 instruction budget before compliance drops off, and the system prompt already uses about 50 of those. 30. After Claude makes a mistake, say "Update your CLAUDE.md so this doesn't happen again" When Claude makes a mistake, say "update the CLAUDE.md file so this doesn't happen again." Claude writes its own rule. Next session, it follows it automatically. Over time your CLAUDE.md becomes a living document shaped by real mistakes. To keep it from growing indefinitely, use @imports (tip #32) to reference a separate file like @docs/solutions.md for patterns and fixes. Your CLAUDE.md stays lean, and Claude reads the