Stop retyping the same rules into every agent session

You have said it before. Branch before you change anything. Do not call it done until the tests pass. Tell me once at the end, not four times along the way. Typed into a prompt, that lasts one session. Tomorrow you type it again, from memory, slightly differently, and the agent behaves slightly differently in return.

Multiply that by six sessions on three machines and the expectations you hold in your head stop matching the ones your agents are working to. Nobody decided that. It drifted, one hurried prompt at a time.

What a workflow is

A workflow is a named way of working that your whole fleet shares. It is not a script and not automation - it is written guidance about how a kind of job should be run, stored on your Gateway rather than in any one repository or on any one machine.

Every session, on every machine, starts with the catalog in its briefing: each workflow's name and a one-line summary. That is all it carries until it needs more. A session that takes on matching work fetches the full guidance, and follows it as its conduct for that job:

cc-devthrottle workflow list
cc-devthrottle workflow instructions standalone-with-review

The split matters. Sessions do not pay to read guidance for jobs they are not doing, and the ones that are doing that job get the whole of it, word for word, every time.

Three you already have

• standalone - one agent picks up the work and finishes it. No manager, no reviewer.
• standalone-with-review - one agent does the work, and a second, separate agent reviews it before it is called done.
• mission - the team way of working, where the design is settled first, one seat drives the job to done, and others build. You are bothered once, at the report.

The built-ins are read-only. A push aimed at one is refused, so they never drift from what ships and they update with the Gateway itself. To make one your own, clone it - the copy is yours, editable, and live immediately.

Changing one is how an improvement sticks

This is the part that pays for itself. When a session does something you do not want repeated, the instinct is to tell that session. It will listen, and the next session will not have heard. Change the workflow instead.

• Publishing is immediate. You push a draft, publish it, and it is the live version on the Gateway at once. There is nothing to deploy and nothing to restart.
• The edge catches up in about a minute. Each Director re-reads the catalog on a poll, so a session started in the first moments after a publish can still be briefed with the old one. Sessions already running keep the briefing they started with. Nothing is retroactive.
• Work in flight is left alone. A run keeps the version it was pinned to when it started, so a change never rewrites the rules under a job that is halfway done.
• Off is not gone. disable takes a workflow out of every briefing and stops new runs without removing anything; enable puts it back.

A run leaves a record

Each execution of a workflow is a run, and a run can be read back: the version it was pinned to, where it got to, its acceptance criteria, who took part, and the proof it produced. That is the difference between "I asked for a review" and being able to see that one happened, and what it found.

Workflows and skills

They sit on the same shelf and answer different questions. A workflow says how a whole job is run and who staffs it. A skill is one capability an agent picks up in the middle of a job - see teach it once, not once per machine. Most teams want both, and most start with the workflow, because the thing they keep retyping is how the work should go rather than how one tool works.

Every command, the authoring loop and the rules for built-ins are on the workflows page. To write your first one end to end, follow Workflows: your named ways of working.