Skip to content

6.5 Your First True Automation

Everything so far required you to restate the work. The next rung is a human-triggered routine: repeatable steps reduced to one invocation, with judgment and external actions still gated. Scheduled or event-triggered execution comes later and requires additional controls.

What you will learn

  • Apply the automation filter: what's worth automating and what isn't.
  • Build a one-invocation workflow: a repeatable job as a runnable routine.
  • Understand the automation ladder you'll climb through the rest of the course.

Builder principle

Automate the decided, not the deciding. Routines run on rails; judgment stays yours.

The filter: is it worth automating?

The famous trap: spending five hours automating a five-minute task. The filter:

  1. Frequency — weekly or more? Candidate. Monthly? Maybe. Rarely? Just do it.
  2. Sameness — are the steps the same every time? The decided part automates; the judgment part doesn't. Most tasks split: automate the assembly, keep the approval.
  3. Cost of error — if it runs slightly wrong once, is that annoying or catastrophic? Start your automation career firmly in "annoying."

Your Lesson 1.1 time-eater list — the one you've been carrying since Chapter 1 — was made for this moment. Run all three questions against it now.

The one-word workflow

The simplest semi-automation is a routine captured as a custom command (6.1), so a multi-step draft workflow becomes one invocation. Illustrative example — Monday content preparation:

Data gate — complete before connecting real content

Apply the writing data gate: classify and authorize each source, confirm provider and organizational handling, minimize what the routine can read, and substitute synthetic files when any answer is unclear. Repeat the check whenever the routine gains a new input.

.claude/commands/monday.md:

Monday content prep routine:

1. Read docs/content-calendar.md — what's scheduled this week.
2. Read the newest file in published/ — for continuity and to avoid repeats.
3. Draft this week's piece into drafts/ per docs/style.md.
4. Draft 3 social posts pointing at it, per the social section of style.md.
5. Update docs/content-calendar.md: mark this week in-progress.
6. Report: what you made, what needs my judgment, what looked off.

Monday morning: cd content && claude → /monday → coffee → return to a stack of drafts and a report. The deciding — which drafts ship, what changes — stayed yours. The ninety minutes of assembly didn't.

Notice the anatomy, because it's the template for every routine you'll ever write:

  • Steps that read before they write (the loop, always the loop)
  • Files as the interface — calendar in, drafts out, log updated
  • Judgment explicitly excluded — "needs my judgment" is an output, not a failure
  • A report at the end — automations that don't report drift silently

The automation ladder

This course climbs it rung by rung from here:

Rung 1 — ONE-WORD ROUTINES        ← you are here (custom commands)
Rung 2 — SKILLS                    ← Ch. 7: routines with structure, files,
                                      and know-how packaged for reuse
Rung 3 — TOOL-CONNECTED            ← Ch. 8: routines that touch real systems
                                      (calendar, email, DBs) via MCP
Rung 4 — SELF-CHECKING             ← Ch. 9: hooks verify every run
                                      automatically
Rung 5 — SCHEDULED / TRIGGERED     ← Ch. 11: runs on a timer or event,
                                      reports back; you review outcomes

Two things to notice about the ladder. Every rung keeps the report — autonomy grows, accountability doesn't shrink. And every rung keeps the judgment split — even rung-5 automations queue decisions for humans; they just batch them efficiently.

Rung 1 is enough to test value without granting external access. Run a routine on comparable inputs for two weeks; record preparation, review, correction, and maintenance time as well as execution time. Report the observed result for your sample instead of projecting a universal weekly saving.

You can see where this goes: routines are the unit that later gets scheduled (cron + claude -p headless mode exists, and Chapter 11 touches it), triggered (CI events), and composed (Skills invoking Skills). The discipline that matters now is designing routines with clean file interfaces and explicit judgment boundaries — automations with fuzzy inputs or embedded judgment are the ones that rot into "that script nobody trusts."

Try it now

Build your first routine this week — the full arc:

  1. Filter your time-eater list; pick the winner (weekly + same-steps + low-stakes).
  2. Do it manually one more time — but narrate every step into a file as you go. That file is your routine's first draft. (This is how pros extract processes: do it once with the recorder on.)
  3. Turn the narration into a .claude/commands/ routine with the four-part anatomy.
  4. Run it for real. Compare against your manual run. Fix the gaps.
  5. Journal the honest math: minutes saved per run × runs per year. That number is why Chapter 7 exists.

Check your understanding

  • Recite the three-question filter. Which question does the five-hours-for-five-minutes trap fail?
  • What are the four anatomical parts of a well-built routine?
  • What two properties persist up every rung of the ladder?
  • "Automate the decided, not the deciding" — apply it: which half of your chosen task was which?