5 Claude Code Workflows I Use Every Day (For the Boring 80%)

People keep asking me what my Claude Code "prompts" are.

I don't really have prompts. I have workflows. Small, boring, repeatable things that each save me 10-30 minutes, and at the end of a day add up to why I can keep shipping around a day job.

Here are five I use almost every session.

1. "Before you edit, grep."

When I hand Claude Code a task that touches something broader than a single file — a rename, a pattern change, a refactor — I start the session with one directive:

Before you edit anything, grep for all occurrences of X. Show me the list. I'll tell you which ones to change.

That single sentence has prevented more bad edits in my repos than any test suite. It forces the AI to enumerate the scope before it takes action, and it gives me a natural "stop, this is too big" moment.

The cost is 15 seconds. The upside is not finding out three hours later that it renamed something in a migration script.

2. "Write the test first. Fail it. Then fix it."

Not because I'm a TDD purist. I'm not. But AI is weirdly good at writing confident code that does the wrong thing, and tests are the cheapest way to catch that.

My actual phrasing:

Write a failing test for the bug I just described. Run it. Confirm it fails for the right reason. Then write the fix. Then re-run.

The "run it. Confirm it fails for the right reason" is the key. Tests that pass by accident are worse than no tests — they give false confidence. Forcing the AI to watch its own red-to-green transition catches the subtle "test was wrong, code is actually broken" cases.

3. "Explain, then diff."

When I'm learning something new — a library API, a framework pattern, a language feature — I don't let Claude just write it for me.

Before writing code, explain what you're going to do in plain English. What calls what. What the state machine looks like. Then write the diff.

Without this, I end up with working code I don't understand, and understanding-debt compounds until I get burned on the second or third iteration.

With it, I read three paragraphs and then review a diff. My comprehension stays current, and my edits are informed.

4. "Grep my notes first."

I keep a flat directory of .md files with notes from past sessions. Problems I solved, patterns I chose, decisions I'd regret if I forgot. Not a fancy system. Just markdown.

When I start a new session on a related topic:

Read ~/notes/ (look for filenames matching the topic). Summarize what I've already decided before suggesting anything new.

This catches the "we already tried that and rejected it" case before I waste an hour rebuilding the rejected path. It also forces me to keep writing those notes, because now they have a feedback loop.

5. "Pick one. Ask before the others."

When I give Claude a list of 4-5 things to do, it used to just plow through all of them. Sometimes halfway through it would change its mind about #1 based on what it learned in #3, and I'd end up with an inconsistent mess.

Now:

Do #1. Stop. Show me what you did. Wait for me to say continue.

Multi-step autonomy is great for well-scoped tasks. For fuzzy ones — anything exploratory, anything touching architectural decisions — forcing a checkpoint between steps keeps the work coherent.

Opus 4.7 is better at self-checkpointing, but I still add this explicitly when the stakes are non-trivial.

The meta-workflow

What these have in common:

• Cheap to run. None of them take more than 30 seconds of me typing or 60 seconds of Claude thinking.
• Fail loud. If they break, I know immediately, not three hours later.
• Compound. Each one is worth a few minutes. Stack five of them and the day opens up.
• Boring. None of them are clever. They're just discipline encoded in a sentence.

I used to write long system prompts. I don't bother anymore. Five short workflows, applied ruthlessly, outperform any clever preamble.

Three cups of tea, no coffee, still tired. Shipping anyway.