Stop Writing Prompts. Automate Claude Code With Triggers.

I stopped writing prompts about four months ago.

Not because prompting stopped working. Because I noticed what I was doing all day: opening a session, typing a careful request, waiting, reading the result, typing the next careful request. I had built an expensive way to do the work myself.

A prompt is a thing you type when you're already sitting there. That's the tell.

A prompt needs you present. A trigger doesn't.

Here's the whole difference, and it's not about how well you write.

A prompt starts when you start it. However good it is, the work happens because you showed up, opened the thing, and asked. Miss the morning and the work doesn't slip — it never begins.

A trigger is a condition you write once. When the condition is true, the work fires. Nobody types anything. Nobody remembers. The eight o'clock research run on my machine has never once been started by me, and it has never been skipped either.

Same model. Same instructions. Completely different relationship to your calendar.

A recurring job that needs someone awake to start it is not automated. It's a chore with a calendar invite.

I wrote that line in a piece about automations failing silently, and it took me embarrassingly long to apply it to my own agents.

Three conditions cover almost everything

You don't need a framework. You need to notice that a trigger is just an answer to "when."

A clock. The plainest one and the one most people skip. Every weekday at eight, run the research pass and hand me two things worth publishing. I don't decide to do research any more. It's already done when I sit down.

An event. Something in the system changed, so work starts. A build goes green, and that wakes the person who can merge it. A row's status flips, and the piece gets written and published. Nobody watched for either of those. The change itself was the instruction.

A shape in the data. A condition you can check cheaply and often. Spend crossed a line. A job hasn't reported in longer than it should have. Something is queued that shouldn't be. These are the ones that catch problems while they're still small, and they're the least written.

graph TD
  P[You open a session and type] --> W1[Work happens]
  W1 --> P2[You read it and type again]
  P2 -.- N[Miss the morning and nothing runs]

  C[A clock] --> T[Condition is true]
  E[An event: build green, status flips] --> T
  S[A shape in the data: spend, silence, a queue] --> T
  T --> W2[Work fires]
  W2 --> R[It reports back when it needs a person]

Everything I run sits in one of those three. There is no fourth kind.

Write the condition down before you write the instruction

This is the part that changes how you build.

When you sit down to automate something, the instinct is to start with what the agent should do. Start one step earlier. Write the sentence that says when, in plain words, and be specific enough that a person could check whether it was true.

"Every weekday at 8am." "When a pull request turns green." "When the month's spend passes the line." "When nothing has reported in for two hours."

If you can't write that sentence, you don't have a trigger — you have a thing you'll do manually and feel guilty about. And most of the time, writing the when down shows you the instruction was never the hard part.

The instruction is usually a paragraph you already know. The condition is the thing you never bothered to name.

What it looks like when this is running

My whole week hangs off conditions I wrote once.

Research runs on a clock. Work gets reviewed because a build turned green and something woke a boss to look at it. Pieces publish because a field changed, not because I remembered to publish. Something tells me when spend moves the wrong way, and stays quiet the rest of the time.

I still type. I approve, I redirect, I kill things I don't like. But I stopped being the thing that starts work, and that was the whole promotion.

The honest catch: a trigger that fires into a mess makes the mess faster. Get the work right by hand first, once. Then write the condition that starts it, and stop starting it.

Where prompting is still the right tool

I'd rather be straight about this than sell you a rule that breaks.

Prompting is right when the work is genuinely new — a thing you've done zero times and can't yet describe. That's a conversation, and it should be. You're figuring it out, not running it.

The mistake is staying there. Most people run the same conversation forty times and never notice it stopped being new around the fourth. The moment you can predict what you're going to type, you're not prompting any more. You're an expensive cron job with an opinion.

That's your signal. Predictable input means it's time to write the condition and stop starting the work by hand.

Start with the thing you do every morning

Pick the one job you begin the same way every day.

Write down when it should happen, in one sentence a person could check. Write down what should happen when that's true. Wire those two together, then go a full week without starting it yourself — and pay attention to whether you even notice.

That's the test. If a week goes by and the work still happened, you've moved something out of your head and into the system, permanently. Do it once and you'll want to do it for everything.

Stop asking better. Start writing conditions.