aihero.dev had a post about tracer bullets — the idea from Pragmatic Programmer where you build a thin vertical slice end-to-end before filling anything in. I started applying it explicitly with Claude Code, using this as a standing instruction:

## Tracer Bullets

When building features, build a tiny, end-to-end slice of the feature first,
seek feedback, then expand out from there.

Before this, I’d give Claude a task and it would try to build the whole thing at once. On anything with multiple layers — a new API route wired up to a UI component with state management — I’d get a large diff I couldn’t reason about. Something would be wrong and I’d have to hunt for it.

Now Claude breaks it down explicitly. First the endpoint and one hardcoded UI call. Make it run. Then expand. Errors surface before they compound, and if the first slice goes sideways, the cost is small.

The original post frames this as “keeping AI slop under control.” That’s about right.

Claude Code just made 1M context the default. No extra charge compared to before — that’s a nice change.

But MRCR hasn’t changed. At 1M tokens, Opus 4.6 sits at 78% retrieval accuracy, which means 1 in 4 multi-needle retrievals still fails. There are already GitHub issues about it — model loses track of earlier decisions, starts going in circles, forgets things from earlier in the session. Anthropic calls it “context rot.”

My own workflow doesn’t really need 1M. I run around 20k, clear often, and split bigger tasks into subagents or subplans. At that scale retrieval is basically perfect and the context stays clean.

Having 1M available without paying extra is handy when you actually need it. But defaulting to it just because it’s there — I’m not sold on that.

One side note: the opusplan mode I use doesn’t default to 1M context. So even within Claude Code, it’s not universal.

Claude Code has a tool called AskUserQuestion. Most people don’t know it exists. It’s basically the difference between Claude guessing what you want and Claude asking what you want.

When Claude isn’t sure — which approach to take, which file to modify, what your naming convention is — it can pause and give you multiple-choice options. Not a vague “what do you think?” but concrete choices it figured out from reading your codebase.

The best way to trigger it: plan mode. Hit shift+tab, give a one-sentence description of what you want, and Claude will interview you. Each question comes with options it inferred from your code. You answer, it refines, and you end up with a solid spec before a single line of code gets written.

Thariq from Anthropic put it well: start with a minimal spec, let Claude interview you via AskUserQuestion, then execute the spec in a new session.

You can also teach Claude when to ask by putting instructions in your CLAUDE.md:

When modifying shared components, always ask which consumers should be updated.

Three things worth knowing:

• Users can always pick “Other” for free-text input — you’re never locked into the options
• multiSelect: true lets Claude show checkboxes instead of radio buttons
• There’s a 60-second timeout — if you step away, just pick the recommended option and adjust later

Think of it as Claude saying “I have options, but you know your project better.” That one pause can save you from undoing three wrong assumptions.

You kick off a long Claude Code task, lock your screen, come back, and the session is dead. macOS put the display to sleep, the system followed, and Claude got cut off mid-work.

caffeinate -d keeps the display from sleeping. Run it alongside Claude Code and your session stays alive while you’re away.

caffeinate -d claude

Or if Claude Code is already running, just run caffeinate separately:

caffeinate -d &

If you close the lid (clamshell mode on AC power), add -s to prevent system sleep too:

caffeinate -ds claude

-d keeps the display awake. -s keeps the system awake while plugged in. For the typical “I locked my screen and walked away” case, -d alone is enough.

Kill it when you’re done: Ctrl+C if it’s in the foreground, or killall caffeinate if it’s backgrounded.

Small thing, but once you start running multi-hour Claude Code sessions it’s good to have in muscle memory.

OpenClaw went viral in January because it nailed one idea: you shouldn’t have to be at your terminal to talk to your AI agent. Message it from Telegram or Discord, let it work, get the answer back in the same chat. Clean.

Anthropic just built that into Claude Code.

Claude Code Channels ships as a research preview in v2.1.80. It’s plugin-based — install the Telegram or Discord plugin, start Claude with --channels, pair your account, and your local session is now reachable from your phone. Messages you send from the chat app arrive inside the running session. Claude does the work against your actual files, git history, and any MCP tools you have set up, then replies back through the same channel.

claude --channels plugin:telegram@claude-plugins-official

The key architectural choice: outbound polling only. Claude’s machine initiates the connection to Telegram or Discord — no inbound ports, no ngrok, no Cloudflare Tunnel. OpenClaw often needed that kind of tunnel setup. Channels sidesteps it.

One honest limitation: this only works while the session is open. Close the terminal, let the machine sleep, and messages from your phone are silently dropped. OpenClaw runs as an always-on daemon and handles that gracefully. Channels requires you to keep a background terminal alive or run Claude on a server.

So where does that leave OpenClaw? Still useful. It supports 50+ platforms (Slack in particular — not in Channels yet), works with non-Claude models, and doesn’t need a live session to stay online. But for my workflow — Claude Code running on a persistent machine anyway — Channels is the simpler path. One less tool to maintain, native integration, no extra auth layer.

The pattern OpenClaw pioneered is now a first-class Claude Code feature.

Claude Code has a permission system: allow, ask, and deny. Rules live in settings.json, evaluated in order — deny wins first, then ask, then allow. Pattern matching supports wildcards like Bash(npm run *) or Read(/home/*).

A lot of people avoid --dangerously-skip-permissions because the name sounds scary. So instead they add Bash(*) to their allow list to skip the prompts. That’s the same thing. The flag just makes the risk visible; Bash(*) hides it in a config file.

The better move: figure out what you actually need. Add Bash(git *), Bash(npm run *), the specific commands your workflow uses. Put anything destructive in deny. Takes twenty minutes once, saves constant friction without opening everything up.

Claude Code v2.1.69 added voice dictation. /voice to toggle, hold Space to talk, release to transcribe. That’s it.

It’s input only — Claude still responds in text. Think of it as replacing your keyboard for the prompt, not turning Claude into Siri.

What’s nice: it actually knows coding words. Regex, OAuth, camelCase, async/await all come out right. It also picks up project names and git branch names from context. You can mix voice and typing freely — dictate a rough thought, then clean it up with the keyboard.

20 languages supported, Korean included. Space is rebindable if it conflicts with something (meta+k works).

The catch: you need claude.ai auth and a local mic. Doesn’t work over SSH or on remote servers.

Honestly though — open offices make this awkward. Talking to your terminal while people are around isn’t great. Best for home offices or solo setups.

Claude in Chrome is a Chrome extension that lets Claude Code control the browser you already have open.

The big difference from Playwright is that Playwright launches its own Chromium instance. That means if your app needs authentication, you have to deal with it — saving session cookies, writing an auth script, whatever. Claude in Chrome doesn’t bother with any of that. You’re already logged in, so Claude just… uses that.

Say you want to test a checkout flow on your staging environment that’s behind SSO. With Playwright you’d spend 20 minutes setting up session state. With Claude in Chrome, you just ask and it does it.

The one downside worth mentioning: it’s noticeably slower than playwright-cli. For quick, repeatable automation you’d still reach for Playwright. But for anything that needs real auth or a fast manual-style walkthrough, Claude in Chrome is just easier.

Before Docker Sandbox, you had two choices with Claude Code: approve every bash command manually, or run --dangerously-skip-permissions and hope nothing goes wrong. The first kills productivity. The second is exactly what it sounds like — dangerous.

Docker Sandbox sits in between. It uses OS-level primitives (Seatbelt on macOS, bubblewrap on Linux) to enforce filesystem and network isolation. Claude can read and write inside the working directory, access only approved network domains, and nothing else. No permission prompts for safe operations, no unrestricted access either. Run /sandbox and it’s on.

The real difference from --dangerously-skip-permissions: sandbox boundaries survive prompt injection. Even if a malicious dependency tricks Claude into running something nasty, it can’t touch ~/.bashrc, can’t exfiltrate your SSH keys, can’t call home to an attacker’s server. With skip-permissions, all of that is wide open.

That said, the rough edges are real. Docker itself is incompatible with the sandbox — you need excludedCommands to run it outside. Adding an env var means restarting the sandbox and losing your conversation context. Some dev dependencies don’t match the sandbox OS architecture. watchman doesn’t work, so Jest needs --no-watchman. And the escape hatch (dangerouslyDisableSandbox parameter) exists for when commands fail inside the sandbox — which happens more than you’d like.

It’s the right direction. Just not frictionless yet.

agent-browser shipped a skill called dogfood. It navigates a web app like a real user, finds bugs and UX issues, and returns a structured report — screenshots, repro videos, and step-by-step reproduction steps.

Before this, running exploratory QA with an AI agent meant cobbling together browser automation yourself. This wraps that whole workflow into a single skill you can call from Claude Code.

I’m curious whether this makes QA genuinely delegatable. Not automated testing in the traditional sense — no test files, no assertions — just someone walking through the app the way a human tester would. The structured output is the part that seems actually useful; it’s something you could hand off.

Still need to test how fast it runs and how many tokens it burns. That’ll determine whether it’s practical day-to-day.

Haiku 3 left a bad impression on a lot of people. Me included. It was just kind of… not usable for most things, and that reputation never really went away.

But Haiku 4.5 is worth a second look — specifically for literal instruction following. Opus reasons well, that’s the whole point. But that same reasoning thing means it sometimes just substitutes its own judgment for what you actually wrote in the prompt. There’s a GitHub issue where Opus 4.6 was asked to re-read a reference document four or five times and kept ignoring specific instructions anyway. A benchmark on slide text generation found Haiku outperforming premium models on instruction compliance — 65% vs 44%.

So when you need a model to do exactly what the prompt says — not interpret it, not “improve” it, just follow it — Haiku tends to be the more reliable one. Most people reach for it because it’s fast and cheap. The faithful execution thing is just quietly there and doesn’t get talked about enough.

Claude Code’s auto memory lets Claude save notes to itself between sessions — build preferences, debugging patterns, code style habits. It decides on its own what’s worth keeping.

My workflow adds a manual layer on top of that. When Claude writes code in a way I don’t want — wrong pattern, wrong style — I correct it. At that point, the remember skill fires and asks whether to save it to auto memory. If it’s something I want consistently applied going forward, I save it.

Over time, corrections accumulate. Claude gradually stops making the same mistakes because that context is already there at the start of each session.

The key bit: the remember skill doesn’t trigger automatically at the right moment on its own. As I covered in a previous post, you need an auto-trigger rule in CLAUDE.md. Without that, the skill just won’t fire when you make a correction.

Boris Cherny, who built Claude Code, keeps his CLAUDE.md at around 2.5k tokens — roughly 100 lines. One developer’s was 8x that length and was getting noticeably worse results.

Here’s why it matters. CLAUDE.md loads into context at the start of every session. System prompts, tool definitions, and MCP schemas already eat 30,000–40,000 tokens before you type anything. The longer your CLAUDE.md, the less actual working context you have compared to someone keeping it lean.

Boris’s rule: add a line when Claude does something wrong, not upfront. The file grows based on real mistakes, not hypothetical ones.

Most things people put in CLAUDE.md don’t need to live there permanently. Workflows, multi-step processes, style guides — those can be skills that only load when you invoke them. CLAUDE.md should hold what needs to be true on every single request. Everything else is just overhead.

Claude Code v2.1.72 added /loop — run a prompt on a repeating schedule without leaving your session.

/loop 5m check if the deployment finished and tell me what happened

Every 5 minutes, Claude wakes up, runs the prompt, and goes back to waiting. Leave out the interval and it defaults to 10 minutes. Works with any prompt, including other commands:

/loop 20m /review-pr 1234

For one-shot reminders, you don’t even need /loop — just describe it:

remind me at 3pm to push the release branch
in 45 minutes, check whether the integration tests passed

To see what’s running or cancel something: what scheduled tasks do I have? / cancel the deploy check job. Natural language works fine.

---

A few things worth knowing before you rely on this.

Tasks are session-scoped — close the terminal and they’re gone. Recurring tasks also auto-expire after 3 days, so a forgotten loop doesn’t run forever. That’s intentional, but it means /loop isn’t a replacement for a real cron job or GitHub Actions workflow.

If Claude is mid-response when a task comes due, it waits. It fires once when Claude goes idle — no catch-up for missed intervals. So if you’re deep in a conversation and a /loop 5m task was supposed to fire three times, it fires once when you stop.

Max 50 scheduled tasks per session.

For anything that needs to survive restarts or run without a terminal open, use GitHub Actions or Desktop scheduled tasks instead.

Claude Code now has three ways to work away from your terminal. They’re easy to mix up. Here’s how they actually differ.

Web (Dispatch) is the simplest one: Claude runs in the cloud, not on your machine. claude --remote "fix the auth bug" clones your GitHub repo into an Anthropic sandbox and works independently. Close your laptop, come back later, create a PR. You can run ten in parallel.

Remote Control and Channels are both local — your machine does the work. That’s where they diverge.

---

Remote Control is for when you want to keep steering a session from a different device. You started something at your desk, moved to the couch, and want to keep the conversation going from your phone. Open claude.ai/code or the Claude app, find your session, and pick up where you left off. You see Claude’s responses, you send the next message, you approve tool calls. It’s just a window into your running session — same conversation, different screen.

claude --remote-control "Refactor auth module"
# → session appears in claude.ai/code and the Claude mobile app

Channels is for when you want something else to trigger Claude, not you. You’re not steering a session — you’re setting up a listener. A message comes in on Telegram, Claude processes it and replies back. A CI webhook fires at 3am, Claude reads the failure and starts debugging. You don’t have to be watching.

claude --channels plugin:telegram@claude-plugins-official
# → Claude now reacts to messages sent to your Telegram bot

The difference is clearest with examples:

You’re on the couch and want to ask “what’s left in this PR?” and read Claude’s answer in a chat thread — Channels. You’re on the couch and want to watch Claude work through a refactor step by step, sending follow-up messages as you read its output — Remote Control.

You want CI failures to automatically wake Claude up and post a diagnosis — Channels. You want to interrupt a running Claude session from your phone to say “actually, skip that file” — Remote Control.

Channels is reactive. Remote Control is interactive.

---

	Runs on	Good for
Remote Control	your machine	steering a session from another device
Channels	your machine	reacting to external events (Telegram, webhooks)
Web	cloud	async tasks that don’t need local files

Claude Code v2.1.80 added effort frontmatter support for skills. You can now bake the reasoning depth right into a skill, so the user doesn’t have to think about it.

---
name: remember
description: Save a preference to memory
effort: low
---

Three levels: low, medium, high. Before this, effort was a session-wide setting — you’d /effort high before a heavy task and forget to reset it. Now the skill just carries that intention itself.

The split makes sense once you think about it. A remember skill is writing one line to a file — low effort is plenty. A research or plan-deep skill is doing multi-file analysis and architectural reasoning — you want high. Medium is the Opus 4.6 default and works fine for most things.

The nice part: skill authors can now encode their token budget assumptions into the skill itself. If you’re sharing a skill meant to be fast and lightweight, you can make sure it stays that way.

Claude reads each SKILL.md description and tries to match it against your message. In theory, the right skill loads when the context fits. In practice, it misses.

The description field is soft matching — Claude treats it as a hint, not a rule. If you want a skill to fire at a specific moment, you have two options that actually work.

Option 1: slash command directly. Type /skill-name and it runs.

Option 2: CLAUDE.md trigger rule. Add an explicit line like:

When the user says "commit", invoke the smart-commit skill.
When implementation is complete, invoke the code-review skill.

This is how skills with side effects — deploys, commits, messages — should be controlled anyway. The disable-model-invocation: true flag is there for the same reason: to stop unintended auto-firing.

If your skill isn’t triggering when you expect it to, the description isn’t the problem. The trigger setup is.

Oh My Claude Code was my first Claude Code setup. Statusline, Ralph loop, 30+ agents, orchestration out of the box. Genuinely useful when I was getting started.

Then I actually started learning how Claude Code works — how context works, what agents cost, how to keep things lean. And OMC started feeling heavy. Too many agents I hadn’t picked myself. Orchestration logic in my CLAUDE.md that I didn’t fully understand.

So I uninstalled it. Wrote my own statusline config, a simple loop script, a CLAUDE.md I could actually read.

OMC is a solid starting point. But once you know what you’re doing, you might want to own what’s running.

New command: /btw.

You can ask Claude a quick question while it’s mid-task — mid-generation, whenever. The answer pops up in an overlay and disappears when you dismiss it.

The key part: it doesn’t go into conversation history. No context bloat, no derailing the main task. It sees the full conversation but uses no tools, so it’s extremely lightweight — basically zero extra tokens.

One response only. No follow-ups. If you need a back-and-forth, use a normal prompt.

/btw what was the name of that config file again?
/btw explain the logic you're writing right now

I ask a lot of mid-task questions, so this fits my workflow really well. Before /btw, every small question added to the context and cost tokens on every future message. Now it’s just a quick peek and done.

It’s kind of the inverse of a subagent: /btw sees everything but can’t act. A subagent can act but starts with nothing.

LLMs have a training cutoff. Ask Claude about a library that shipped a major version recently and it’ll confidently give you outdated API calls. Context7 fixes this — it’s an open-source tool by Upstash that fetches live, official docs and injects them into your prompt at the moment you ask. No stale knowledge, no hallucinated method signatures.

Until now, Context7 only ran as an MCP server. You’d add it to your MCP config, it’d sit in the background ready to pull docs whenever your agent asked. Works well — but MCP has a cost: the server’s tool definitions live in your context window the whole session, and fetched docs get dumped in whether you need all of it or not.

Now there’s a CLI. npx ctx7 setup — that’s it. No MCP config needed.

The practical difference: with MCP, docs are always-on overhead. With CLI + a skill, docs load only when a library question actually comes up. Same up-to-date information, but the context hit is scoped to when it’s actually needed.

I care a lot about keeping context tight (running at ~20k tokens), so this is a welcome change. Pull the specific docs, use them, move on.

npx ctx7 setup. Worth trying.

Do you know about opusplan in Claude Code?

If you type /model, it won’t show up. You have to type /model opusplan directly. It’s a hidden option — Opus for plan mode, Sonnet for everything else.

The idea is simple: planning needs the smarter model, execution doesn’t. When you enter plan mode (Shift+Tab), Opus does the thinking. Once the plan is set and you start implementing, it switches to Sonnet automatically.

This makes a lot of sense to me. A good plan is 80% of the work. If Opus nails the architecture and breaks things down correctly, Sonnet can follow through just fine. You don’t need the most expensive model to write boilerplate or apply a well-defined diff.

/model opusplan. Try it.

Claude Code recently switched its default effort from high to medium, and added the “ultrathink” keyword to bump it back up per-turn.

The old default — high effort on every single turn — was just wasteful. Renaming a variable? High effort. Fixing a typo? High effort. Burning tokens on thinking that didn’t need thinking.

Now medium handles the routine stuff fast, and when I actually need deep reasoning — architecture decisions, tricky bugs, multi-file refactors — I just add “ultrathink” to that prompt. One turn of high effort, then back to medium.

Honestly, this is how it should’ve been from the start. Most interactions don’t need the model to think hard. The few that do, you know when you’re asking them.

medium + ultrathink when needed. That’s it.

1M context sounds great. Just throw everything in and let the model sort it out, right?

Not really. MRCR — a benchmark that tests whether models can actually find specific info in long context — tells a different story. At 1M tokens, the previous generation scored around 17%. Even today’s best barely hits 76%. The model loses track of things way more than you’d expect.

It’s kind of like searching for one email in an inbox with a million messages.

I keep my context around 20k. At that size, retrieval is nearly perfect and responses stay sharp. Bigger isn’t better here — tighter is.

If you’re writing Claude Code skills by hand, try Anthropic’s skill-creator instead.

It’s a plugin with four modes: Create, Eval, Improve, and Benchmark. You don’t just write a skill — you test it with evals, A/B compare versions, and optimize the description so Claude triggers it at the right time.

The part I find most useful: the eval system. You define test prompts, describe what good output looks like, and skill-creator tells you if the skill actually works. No more guessing whether it’ll behave right.

There’s also a benchmark mode that tracks pass rate, time, and token usage across runs — handy for checking whether a skill still holds up after a model update.

Install the skill-creator plugin and run /skill-creator. Worth it.