Workflows: your named ways of working

You have explained the same thing to agents more than once. Always branch before you change anything; never call it done until the tests pass; tell me once at the end rather than four times along the way. Written into a prompt, that guidance lasts one session. Written into a workflow, it reaches every machine: sessions launched after each Director's next poll see it in their briefing, and the ones that do that kind of work read it and follow it. A session started before the poll can still get the old catalog, and sessions already running keep the briefing they started with.

About fifteen minutes. You need a Gateway and the DevThrottle command line, which installs with the product.

1. See what your fleet already works by

   The catalog

   cc-devthrottle workflow list

   Three come built in - mission, standalone and standalone-with-review. The first is the Team way of working - an Architect, a Manager, and Workers - shipped in the catalog under the name mission. They are not examples; they are in force right now, and every one of your sessions starts with them in its briefing.

2. Read one properly

   What a session actually receives

   cc-devthrottle workflow instructions standalone

   Read the output before writing anything of your own. Notice how short it is, and that it is guidance rather than a script - a few hard rules, stated plainly. That is the shape you are aiming for. A workflow nobody can hold in their head is one sessions will follow unevenly.

3. Start from one that already works

   Do not start from an empty file. Pull an existing workflow into a directory and edit it:

   Pull it down

   cc-devthrottle workflow pull standalone --dir ./my-workflow

   You get the workflow's definition in workflow.json, its instructions in markdown, and any helper files. The markdown is the part that matters - it is the conduct a session following the workflow reads.

4. Write the rules, then give it an id of its own

   Edit the instructions. Write the handful of things you find yourself saying over and over, and say why for each - a session that understands the reason applies a rule sensibly in a case you did not foresee, and one that only has the rule will not.

   Then open workflow.json and change the id (and the name) - the pulled file still says standalone. This is not optional: built-in workflows are read-only, so a push aimed back at standalone is refused, and a push aimed at a new id is refused until the id inside workflow.json agrees with it. Pick the id you want to live with - my-branch-rules in the steps below.

5. Push it as a draft, then publish

   Draft first, then live

   cc-devthrottle workflow push my-branch-rules --dir ./my-workflow
   cc-devthrottle workflow publish my-branch-rules

   Pushing creates a draft and changes nothing about how your fleet behaves. Publishing is the moment it takes effect: the Gateway serves the new version at once, with nothing to deploy and no restart. Each Director picks it up on a poll about every minute, and from its next poll onwards the sessions it starts see the new catalog entry. Nothing is retroactive: a session already running keeps the briefing it started with, and one started in the first moments after you publish can still carry the old catalog.

6. Check it landed

   Open Workflows in the Cockpit. Yours is in the list, marked in force, with its version and the date it changed. Within about a minute, newly started sessions anywhere in your fleet see it in their briefing - sessions already running are not interrupted with it.

Next

For the full command surface - turning a workflow off without deleting it, cloning one in a single command, and reading past runs - see Workflows. If your workflow describes work split across several sessions, see Roles: who plans, who manages, who builds.