The Claude Code Engineering Tips guide rendered as a dark, terminal-styled site

I just shipped a guide: 14 habits for using Claude Code well without wasting tokens. Every tip cites Anthropic’s own docs, something Boris Cherny said publicly, or a field heuristic I can point to. It lives on GitHub and renders as a terminal-styled site, so you can read it like a page or point Claude straight at the repo and let it pull what it needs.

The HTML is for humans, the Markdown is for Claude. Read the site if you want the nice version, or feed Claude the repo Markdown, including llms.txt, and ask it to pull the parts relevant to your session.

The 14 habits

All fourteen, each as the thing to actually do. The deeper why, sources, and full command details stay on the site so this stays readable.

1. Write the spec first, with verification built in. Before any non-trivial work, have Claude write a spec, then iterate on it yourself until it’s clear before you approve. Build verification into it so Claude checks its own work instead of leaving you as the only feedback loop. Read every line, because one line in a spec easily becomes a thousand lines of code.

2. Send long, complete prompts. Front-load everything in one go: goal, constraints, examples, definition of done. A thorough prompt that feels slow to write beats five “actually, also…” follow-ups that each reload the context. Reference files with @path instead of pasting them.

3. One coherent workstream per conversation. New task, new thread. Don’t debug auth, write docs, then scan logs in the same conversation, /clear between unrelated tasks so you stop paying to re-read the noise on every turn.

4. Use /clear, /compact, and handoffs for different jobs. /compact when the same task runs long, /clear on a topic switch, a written handoff doc for any pause over an hour. Keep a status line up so context and cache health stay visible, and when Claude warns about uncached tokens, do what it says.

5. Babysit implementations. When Claude fully implements something, watch it. Hit esc the second the approach looks off, then fix the prompt or spec. Only reach for /goal or /loop when you’re genuinely willing to spend the tokens they burn.

6. /rewind instead of correcting. When Claude goes the wrong way, /rewind (or double-tap esc) back to the last good point instead of typing “actually, do X.” A typed correction leaves both the wrong path and the fix sitting in context for the rest of the session.

7. Opus xhigh is the team lead, not the team. Run Opus xhigh in your main coding session and delegate the grunt work, file reads, log scrapes, doc lookups, to Sonnet or Haiku subagents. It’s the same move as managing engineers, own the judgment, hand off the execution. For directive work like reading email or summarizing a doc, skip Opus entirely.

8. Compress tool output on heavy sessions. When a session is full of kubectl, aws, Databricks queries, or noisy test logs, don’t dump raw output into context. Filter at the CLI, ask for --json, or route the noisy work to a subagent so only the summary lands in your window.

9. Prefer CLIs over MCPs, and set up the toolbox first. Claude Code lives in the shell, so when a CLI and an MCP do the same job, pick the CLI, ideally an agent-aware one. Pre-install and authenticate your tools (gh, aws, kubectl, your log CLI) before the session, your verification depends on them.

10. Be deliberate about which MCP servers load. Only enable the servers you need for the work in front of you, every one adds discovery cost at session start. Audit now and then, and turn off anything you haven’t touched in weeks.

11. Install the official LSP plugins. Add Anthropic’s LSP plugins for the languages you actually code in. They give Claude go-to-definition and real diagnostics instead of grep, which collapses a search-and-read loop into a single lookup.

12. Start hard tasks in a fresh window. Don’t kick off something demanding at the tail of a long conversation. Quality drops as context fills, so open a clean window with a focused brief for the hard stuff.

13. Treat the harness as a system. Your AGENTS.md, hooks, skills, plugins, and LSPs decide performance more than the model does, they’re how you onboard Claude into your work. Review that surface every 3 to 6 months, and when Claude writes throwaway code to finish a task, ask it to turn that into a reusable, agent-aware tool so the lesson sticks.

14. Let Claude write the commit after you verify the diff. Once the work is verified and you’ve reviewed the diff, let Claude write the commit. It still has the spec, the failed attempts, and the why, all the reasoning a later hand-typed “fix bug” would lose.

Read the living version

This post is the snapshot. The why behind each habit, the citations, and the exact commands all live on the site, and it’ll keep growing as I learn more. The way I actually use it is to point Claude at the repo:

“Use gh cli to inspect JuanjoFuchs/claude-code-tips. Read the tips relevant to what we’re doing right now, then propose how to integrate them into this workflow.”

The full guide is at juanjofuchs.github.io/claude-code-tips, and that’s the copy I keep current.