Claude Code workflows
A workflow lives in the repo, not in the chat.
The prompt starts the session, it does not run it. What the agent does next comes from the files it finds: rules it has to follow, a toolkit it can reach for, and a place to write down what it learned.
Free. Unsubscribe anytime.
01
Rules
CLAUDE.md
02
Toolkit
skills/ · commands/
03
Interface
mods/
04
Record
Journal/
The definition
A workflow is a loop, not a prompt.
A workflow is not the message you type. It is what happens once the agent has read the repo: the order it takes the work in, what it checks before it edits, and what it writes down before the session ends.
The order is the part people skip. With no defined entry point the agent starts wherever the last message left it, and re-derives the project on every run. That re-derivation is where most of the wasted tokens and most of the wrong edits come from.
Write the order into the setup and the session becomes repeatable: the same four steps whether the task is a one-line fix or a new subsystem.
The test: open a fresh session, say nothing about the project, and see whether the agent still knows where to begin.
In practice
One session, start to finish.
The prompt is a single line. Everything under it comes from the setup: which files get read first, where the plan gets written, and what the check has to pass before the session is allowed to end.
> fix the flaky test in ci.yml
- orientread CLAUDE.md and MEMORY.md
- planreproduce, patch the retry, run the suite
- buildedit .github/workflows/ci.yml
- checknpm test, 128 passed
- recordwrite Journal/2026-10-27.md
done in one session, nothing re-explained
Structure
Four steps, every task.
The steps are cheap individually. What costs real time is skipping one, then paying for it twice: once when the agent guesses, and again when the next session inherits the guess.
- 01
Orient
CLAUDE.md
Before anythingThe agent reads the rules and the memory index before it opens a file. Build commands, off-limits paths, conventions that are not up for debate. This is the cheapest step and the one that prevents the most damage.
- 02
Plan
task note
Before editsThe task gets written down and the files it touches get named. A plan held in the conversation disappears on a context reset. A plan on disk survives a crash, a restart and a new session.
- 03
Build
terminal
In the loopEdits and commands run in the same loop: change, run, read the output, change again. The terminal output is the review. A diff that was never executed is a proposal, not a result.
- 04
Record
Journal/
After the runWhat changed, what broke, what was decided. Written at the end so the next session starts from the result instead of from someone's memory of it.
Four steps is the whole workflow. Everything else in the setup exists to make one of them cheaper, and anything that does not make one of them cheaper is decoration.
Failure modes
Where a session goes wrong.
- 01
A prompt-only setup
A long instruction pasted at the start of a chat works once. It leaves nothing behind, so the second session spends its first minutes rebuilding the first.
- 02
Editing without running
An agent that changes files without executing anything is guessing. The check has to happen in the same session, or the next one inherits a broken assumption as fact.
- 03
Work that never gets written down
If a decision only exists in the scrollback, it exits with the tab. The journal entry is what makes the next run faster than this one.
See it running
The setup, built on camera.
The long-form walkthrough builds the vault and the workflow together. The shorts take one step at a time.
Get the next system.
One message when a new breakdown is published, with the files from it.