Automation auditor

Decompose a workflow into steps, then propose automations in a fixed order of leverage.

Most automation advice starts with "make the slow step faster." That is the last move. A step that a machine can do at all should not have a human in it, and a step that waits three days for a human is a latency problem that no amount of optimization touches.

Rule zero: get a real trace, not a description

Never audit an abstraction. "My invoicing process" is not auditable; a numbered list of what actually happened the last three times is. If the user describes the workflow in the abstract, ask for one concrete run before analyzing anything.

For each step, you need:

Estimates are fine. The ratios matter more than precision. If the user does not know a number, guess out loud and mark it as a guess.

Where you can observe the workflow directly instead of asking (shell history, git log, a scripts directory, an inbox, cron/launchd entries, the Things database), do that first and bring a draft trace to the conversation. A trace you derived and they corrected beats a trace they had to write from memory.

For a dev workflow, the observable trace lives in: shell history (~/.zsh_history, ~/.bash_history: repeated multi-step sequences, retries after typos), git log across the repos under the code root (~/code/*: WIP commits, amend-and-force-push, revert patterns), dotfiles (aliases and functions that already exist or are dead), per-repo Makefile / justfile / package.json scripts / AGENTS.md, and what is already on PATH. State the sample (e.g. "last 30 days of history, last 50 commits"). History holds secrets: summarize patterns and redact any token or credential you see; recommend deleting that line from the history file and moving the value into a secret manager.

Rule one: classify what the human is actually doing

For every human step, decide which of these it is. This single distinction drives most of the findings:

• Transport: moving data between systems. Copy/paste, re-typing, downloading then uploading, reformatting, forwarding, "checking if X happened yet". The human is a network cable. Always automatable. Start here.
• Judgment: a decision that needs context the machine does not have. Usually reducible rather than directly automatable; see rule two.
• Ceremony: the step exists because it always has. Sign-offs, statuses and reports that no one reads, queries or opens. Delete, do not automate.

State the classification for each step explicitly. If you cannot tell whether something is judgment or transport, ask: "what would go wrong if this were done automatically?" A vague answer means transport. A specific failure means judgment.

Rule two: the ladder, in this order

Work down in order. Do not skip to the bottom.

1. Delete the step

Does it need to exist at all? Ceremony steps die here. So do steps that exist only to feed a later step you are about to automate away. Deleting a step beats automating it every time, and it is the only move with negative maintenance cost.

2. Remove the human from the step

Every transport step. This is where the bulk of real savings live and it is usually the least interesting work, which is why people skip it.

3. Collapse the wait

A step with 2 minutes of duration and 2 days of wait is a 2-day step. Waits come from batching, from approvals, from "I'll do it tonight", and from polling something that could push instead. Attack the wait before the duration. A 2-day wait cut to 2 hours dwarfs any speedup of the 2 minutes.

For judgment steps that cannot be automated, this is where they get reduced instead:

• Batch the decisions so the wait happens once, not per item.
• Narrow the decision: present three options instead of a blank page.
• Invert the default: act automatically, let the human veto. Only safe when the action is reversible; say so explicitly when you propose it.

4. Then optimize speed

Only now. Caching, parallelism, a faster tool, a better algorithm. If you find yourself here on step one of the analysis, go back to the top.

Rule three: weight by frequency, and say what you are not doing

Sort findings by duration × frequency saved, plus wait eliminated. A 5-minute monthly task is 1 hour a year and is almost never worth automating. Say so plainly rather than proposing something polite. Explicitly list the steps you looked at and chose to leave alone; a report that only contains proposals reads as if everything needs work.

Flag anything where automation adds risk the manual version did not have: irreversible actions, things touching money or credentials, anything where a silent failure looks like success. Those need a check, not just a script.

Output

## Trace
[numbered steps, one line each: what · actor · duration · wait · frequency · class]

Total: [X] min hands-on per [period], [Y] elapsed.

## Findings
### 1. [What to change]: [delete | de-human | collapse wait | speed up]
Step(s): [n]. Saves: [X min/period, or "Y days of wait"].
How: [one or two sentences, concrete enough to start]
Risk: [only if there is one]

## Left alone
- Step [n]: [one-line reason]

Order findings by leverage, not by step number.

When the fix is code (an alias, a zsh function, a just recipe), put it in the finding copy-pasteable and syntax-checked (zsh -n / bash -n). The smallest form wins: alias, then function, then script, then a target in the repo's existing Makefile / justfile, then a new tool.

Anti-patterns

• Proposing a tool before tracing the workflow. The tool is the last decision.
• Automating the interesting step. The interesting step is usually judgment. The boring one is usually transport, and transport is where the hours are.
• A pipeline that needs babysitting. An automation with a human watching it is a transport step wearing a costume.
• Ignoring the wait column because duration is easier to measure.
• Proposing an LLM for something a for loop does. If the step is deterministic, keep it deterministic: it is cheaper, faster, and it fails loudly instead of plausibly.
• Automating something the user does twice a year. Say no.

Notes for this setup

Built for macOS + zsh. Before proposing anything, check which of these already exist (command -v, launchctl list, the installed skills); a finding that wires them together beats one that needs a new repo:

• owa-piggy + owa-tools: 20 owa-* CLIs over Microsoft 365 (cal, mail, graph, drive, todo, planner, sites, teams, places, people, sched, ado, vids, ...). No app registration, JSON by default, so they pipe. See the cj-owa-tools skill.
• things (things3-cli): read/write Things 3, with a JSON mode. See cj-things.
• now: one read-only view of open work across .plans/, Things, ADO and ledger loops. See cj-now.
• todo: repo-scoped todos and plans. See cj-todo.
• yaams (raw recall over mail, chat, calendar) and ledger (the cognitive ledger: curated facts, decisions, open loops).
• teaminal: Teams in the terminal.
• launchd, not cron, for new schedules on macOS (owa-piggy already uses it).
• Skills for daily notes (cj-daily), capture (cj-notes), meetings (cj-meetings) and voice (cj-voice-dna).

Record a rejected proposal in the ledger (through cj-notes) when it is installed, and check there before pitching it again. Re-pitch only with new evidence.