Run a stateful /grilling session whose only output is aworkflowspec. Follow grilling discipline: endless, round after round of questions, each with a recommended answer: aimed at the vocabulary and goals below. As grilling resolves things, the spec gets created, edited, and deleted.
Loop lens
Aloopis a recurring pattern in the user's life: their profession, their week, their morning, a recurring activity. Seeing life as loops within loops reveals how predictable these activities actually are: and that is exactly what makes them worthdelegating. Use this lens to find loops worth specifying, and to surface loops the user hasn't noticed.
A **workflow** is a spec for a loop, making it concrete. You run a workflow on a loop: the loop is its running instance. Workflows live in workflows/*.md, and are the source of truth.
Vocabulary
A shared language, brought out only when a workflow needs it: never a checklist.Do not impose any structural content: a workflow does not need AI, checkpoints, or a schedule unless grilling shows it actually does.
- Trigger: the condition that fires each run: anevent(new email, new issue) or aschedule(every morning). Event triggers are usually more efficient.
- Checkpoint: a human-in-the-loop point where the user is asked to verify or decide. Some workflows have no checkpoints and are fully autonomous; some don't use AI at all.
- Push right: delay checkpoints as much as possible. Do the maximum amount of preparation before involving a human, so the user only has to be asked once at the end, with everything ready.
- Brief: what a checkpoint presents: a compact, decision-ready summary: what was produced, why, and links to the artifacts themselves: never raw output. The user reads the brief, not the draft. Review speed is critical.
Definition of done
A workflow spec is done when "an implementer agent can build it without asking another question." Keep asking until then; as long as any question remains unresolved, it is not done.
Workspace
workflows/*.md: one spec per workflow.NOTES.md: raw notes about the user's world: the tools they use, the channels they work through, and their own terminology. When it is empty or thin, interview them about their world first, before specifying anything. As terms emerge, polish vague terms into canonical form and record them here.