Lesson 005Field guide · AI Workflows & Systems
Documenting AI Processes
Write down what works so it's repeatable — by you or your team.
You'll learn
- Why a written process outlives a remembered one
- The six-line process-doc format: purpose, trigger, steps, prompt, review, owner
- When documentation earns its cost — and when it doesn't
- The handoff test: the real quality bar for any process doc
- How to keep docs true instead of letting them rot
01Section
Written beats remembered
Your system so far lives in two places: your prompt library and your habits. That works — until you're away for two weeks, or a teammate needs to cover for you, or future-you opens the library and can't remember why step two comes before step three.
A process doc fixes that. It's the workflow written down completely enough that someone who isn't you — including you, three months from now — can run it cold.
A useful analogy
A process doc is the note taped inside the equipment cabinet: how to run the thing, written by the last person who figured it out. Nobody reads it for fun. Everybody is glad it's there.
Checkpoint
02Section
The six-line format
You don't need a wiki or a template gallery. Six fields cover it:
Purpose
Why this process exists — one line
Trigger
What starts a run: a day, an event, a threshold
Steps
Numbered, starting with gathering the input
Prompt
The exact stored prompt, pasted in full
Review
What to check before the output counts
Owner
Who keeps this doc true when things change
Process doc template — copy and fill in
PROCESS: (name that says the job) Purpose: (why this exists, one line) Trigger: (what starts a run) Steps: 1. (gather the input — from where, in what shape) 2. (run the prompt below) 3. (review, then deliver the output — to where) Prompt: (paste the full prompt here — complete, not a reference) Review: (what to check before using the output) Owner: (who keeps this doc up to date) Last updated: (date)
Checkpoint
03Section
When documentation earns its cost
Not every workflow deserves a doc. Documentation costs time to write and — the part people forget — time to keep true. A process earns a doc when it hits most of these:
- You've run it three or more times and expect to keep running it
- Someone else might need to run it — coverage, delegation, a growing team
- A bad output has real cost: it goes to customers, clients, or your boss
- You keep re-answering the same "how does that work again?" — from others or from yourself
Documenting everything is how documentation dies. A stale doc is worse than none — it teaches the old way with full confidence.
Checkpoint
04Section
The handoff test
Here's the quality bar, and it's binary: could you hand this doc to someone else and have them run the process without asking you anything? Every question they'd need to ask is a missing line.
Write for that reader even if you work alone — because you-in-three-months is that reader. They have your job and none of your current context.
Key takeaway
A process doc is done when it survives a handoff. Every question the reader still has to ask is a missing line.
Privacy note: Process docs get shared and copied. Keep real customer data, credentials, and personal details out of the prompt and the examples — describe the shape of the input, never actual private content.
Pause and think: Who would you hand your first process doc to? Picture their first three questions — those are the lines to write most carefully.
Checkpoint
05Section
Keep it true
The owner field is a promise: when the prompt gets a v2 in your library, the doc gets the same v2 — they must never disagree. And when a process dies, its doc gets archived, not left around to mislead the next reader.
That's the whole maintenance burden: update on change, archive on death. If a doc's last-updated date is older than your memory of running the process, that's the doc to check first.
Checkpoint
Prompt exercise
Run the handoff test
Copy this prompt into ChatGPT, Claude, Gemini, Copilot, or whichever AI tool you have access to — the website doesn't run AI itself. The AI plays the teammate taking over one of your workflows; your job is to survive its questions.
Act as a new teammate who has to take over one of my processes tomorrow, with zero context. First, ask me to briefly describe a task I do with an AI tool. Then try to run the process in your head, and ask me one question at a time about everything you'd actually need: where the input comes from, the exact prompt, what to check in the output, where the result goes, what done looks like. Keep asking until you could genuinely run it without me. Then list every question you had to ask — that list is the outline of the process doc I need to write.
Reflection: Every question the AI asked is a line your doc needs. Keep the list — the final lesson in this path turns it into a complete, saved process doc.
Quick check
3 quick questions — no pressure
There's no pass or fail here. Answer them all, and we'll show you the answers either way.