Docs/Tutorials/Workflows
Tutorials

Workflows: your named ways of working

8 min read

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, every agent on every machine reads it from then on.

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. They are not examples; they are in force right now, and your agents are already being briefed with them.

  2. Read one properly

    What an agent 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 agents 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 ./my-workflow

    You get the workflow's definition, its instructions in markdown, and any helper files. The markdown is the part that matters - it is what your agents read.

  4. Write the rules you keep repeating

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

    Give it a name of its own in the definition so it does not overwrite the built-in you started from.

  5. Push it as a draft, then publish

    Draft first, then live
    cc-devthrottle workflow push ./my-workflow
cc-devthrottle workflow publish <your-workflow-id>

    Pushing creates a draft and changes nothing about how your fleet behaves. Publishing is the moment it takes effect - and it takes effect everywhere at once, with nothing to deploy and no restart.

  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. Any session started from now on is briefed with it.

Note
Publishing will not disturb work already in progress. A run keeps the version it was pinned to when it started, so you can improve a workflow without rewriting the rules under a job that is halfway done.
Tip
The best first workflow is the shortest one. Take the single instruction you are most tired of repeating, write only that, and publish it. You can always add to it - and a workflow that is actually followed beats a thorough one that is skimmed.

Next

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