Call the Skill tool and specify grilling, run a stateful session whose only output is workflow specs. Use grilling discipline: keep asking, one question at a time, each question with a recommended answer. Interview around the vocabulary and goal below. As grilling resolves things, create, edit, and delete specs.
The loop lens
Loop is a repeating pattern in the user's life: career, week, morning, or a single recurring activity. Seeing life as loops within loops reveals how predictable the activity really is, and therefore which ones are worth delegating. Use this lens to find loops worth writing a spec for, and to surface loops the user has not noticed yet.
Workflow is the spec of a loop, and makes it executable. You run a workflow on a loop; the loop is its running instance. Workflows live in workflows/*.md and serve as the source of truth.
Vocabulary
Use shared language only when the workflow needs it; it is not a checklist.Do not force any structure: unless grilling shows it is needed, a workflow does not need AI, does not need a checkpoint, and does not need a schedule.
- Trigger - the trigger for each run: an event(new email, new issue) or a schedule(every morning). Event-triggering is usually more efficient.
- Checkpoint - the human-in-the-loop point, where the user verifies or decides. Some workflows have no checkpoint and can run autonomously; some do not use AI at all.
- Push right - delay the checkpoint as much as possible. Complete the maximum amount of work before involving a person, so the user is asked only once, later, and everything is ready.
- Brief - what the checkpoint shows: a compact, decision-ready summary of what was produced, why, and links to the underlying asset; 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 any questions. Keep grilling until then; as long as there are still questions, it is not done.
The workspace
workflows/*.md- one spec per workflow.NOTES.md- raw notes about the user's world: the tools they use, the channels they deal with, and their own terms for both. When it is empty or thin, interview the user's world first, then write any spec. As fuzzy terms emerge, polish them into canonical terms and record them here.