Clear the conversation with /clear

You’re an hour into Monday’s rate-limiter work when Slack lights up: the submit button on the contact form is overlapping the footer on mobile, and someone wants it fixed before a demo at noon. It’s unrelated to the payments refactor in every way — different files, different part of the stack, different headspace.

Here’s the trap. Your session is right there, warm and full of context, so you just start typing the bug into it. But that session is saturated with the refactor: middleware code, the in-memory-LRU decision, the rate-limiting test output. All of it is still in the window, and all of it now works against you. You’re paying tokens to carry it on every turn, and — worse — it’s quietly steering the agent, which now reasons about a CSS bug through the lens of payments middleware. Ask it to fix the button and don’t be surprised when it wonders aloud whether the change affects the limiter.

You learned last lesson not to resume unrelated work. This is the same principle one step further in: don’t even keep unrelated work in the current window. You want a clean slate — without quitting and losing your place in the terminal.

Wiping the slate

/clear

That empties the conversation and starts fresh in the same working directory, same running process. The window drops back to just the system prompt, your rules, and the tool definitions — none of the refactor chatter. Then you describe the actual problem into a context that has room for it and no opinions about payments:

> /clear

  ⎿ Conversation cleared. Starting fresh.

> the submit button on the contact form overlaps the footer on mobile —
  find it and fix it

  [reads src/styles/contact.css, src/components/ContactForm.tsx ...]

The agent goes straight to the stylesheet. It doesn’t reach for a migration file, doesn’t ask whether the button change needs a schema update, doesn’t burn three thousand tokens re-reading database context it will never need. The button gets fixed, you make the demo, and when you --continue back into the refactor afterward it’s untouched — /clear reset what the agent knew, not what it had done.

The line between clear and rewind

/clear is a hard reset of the conversation, and there’s no undo for it. That makes it worth one moment of care: anything in the thread you’ll want later — a decision, a useful finding — needs to be on disk before you wipe, in a commit, a plan file, or CLAUDE.md. This is a real distinction from the /rewind you’ll meet shortly, which steps back through checkpoints and can be undone. Rewind is a time machine; clear is a clean desk. Reach for clear when you want the thread gone, not relocated.

Two smaller things, quickly. /clear never touches your files — every edit, staged or not, sits exactly where it was; it resets the agent’s memory, not the working tree. And don’t confuse it with Ctrl+L: that just scrolls the visible output off your screen while the entire conversation stays in context, costing exactly what it did before. If your goal is a cheaper, sharper agent and not merely a tidy terminal, /clear is the one that actually empties the window.

The decision you’re really making

Step back and the choice between /clear and the /compact you’ll meet at the end of this chapter is the same question asked from two sides: am I done with this line of work, or continuing it? Done and moving to something unrelated — like that button — and you clear, dropping the thread entirely. Still on the same task but running low on room, and you’ll compact, keeping the thread but condensing it. Pick the wrong one and you either throw away context you needed or keep paying for context you didn’t.

For now the button is fixed and the refactor is waiting. So you --continue back, hand the agent the next chunk of the feature, and let it run while you grab coffee — which is precisely when it misreads what you asked for.