arizuko › concepts › workflows

workflows

A workflow is a convention, not a feature. A ## Session opening section in the CLAUDE.md of a group and one plan file, ~/plans/<topic>.md, let an agent finish a job with many steps. The platform runs nothing for it.

One plan file records the job

Without a file, the plan exists only in the chat history, and the agent rebuilds it every turn. A job with many steps gets one ~/plans/<topic>.md, written first and edited in place. The work updates it. “Done” means that the plan file is updated, not that a chat message says so. The file is markdown that the agent owns, with no schema and no database row, and you can diff it like every other file in the agent folder.

The opening goes in CLAUDE.md

Each group has a CLAUDE.md, its operating manual. You write a ## Session opening section in it. The self skill of the agent, ant/skills/self/SKILL.md, tells the agent to run that section before the first reply of every new session. Keep the section short and concrete:

## Session opening

Before replying to anything multi-step:
1. Load context — read MEMORY.md, the relevant facts/, and the diary.
2. Open the plan — read ~/plans/<topic>.md, or create it if missing.
3. Scan skills/ for one that fits the job, and apply its rules.
4. Confirm the goal and name the deliverable, then act.

"Done" means the plan file is updated — not a message that says done.

A workflow adds no seventh primitive

A workflow is Turn and State and the session lifecycle, used with a convention. The session boundary already starts each run fresh. The convention makes the agent load a fixed context there and keep a plan file.

Existing parts give what an engine would give