Expecto CentumEXPECTO CENTUM
Download
Download
Manuscripts · Workflows · Custom workflows

Custom workflows

Build your own workflow — a row of machines you lay out yourself, each one an AI agent running your prompt or a step you code — and pass it on to anyone else who runs Expecto Centum.

Published
✦ Before you begin

You'll need the Expecto Centum desktop app and a signed-in account. Installing and running custom workflows comes with every plan — Tenfold and up. Creating and editing them is a House Hundredfold feature, which the Hundredfold plan, the Openfold grant and the free trial all include. The built-in workflows work without an account.

A workflow is one folder. Its stages, their prompts and the artwork the dashboard draws for each machine all live inside it, so a workflow is easy to keep in a repository, back up, or hand to someone else. Custom workflows sit in the workflow picker alongside the built-ins and run the same way.

✦ The worked example: PR Pro

The examples on this page come from PR Pro, a custom workflow published on GitHub. It reviews the open pull requests in your repositories and posts what it finds as a comment on each one — six machines, from PR Scan to Publish, every one of them a file you can read. Clone it and keep the folder open beside this page; section V installs it.

✦

I Create a workflow

Open the workflow picker on the right side of the dashboard and choose Add New Workflow at the bottom of the list — or click Add workflow in Config → Workflow. On the Create tab, fill in:

  1. Name — lowercase letters, digits and hyphens. It becomes the workflow's folder name: PR Pro's is pr-pro.
  2. Label — what the workflow is called in the picker: PR Pro.
  3. Location — where the folder is made. It defaults to the app's own workflows folder; pick a repository of yours instead and the workflow lives there. The full path is shown under the field as you type.

The app creates the folder with an empty workflow and opens it in the editor.

II Build it in the editor

A workflow is a row of machines, each one a stage: an AI agent following a prompt you write, a step you write in code, or one of the built-in stages such as Ticket Scanner or Publish. PR Pro's row is six machines long. PR Scan finds the open pull requests in the repositories you pick and queues one review for each. Discussion reads the comments already on the pull request, so the review joins the conversation instead of restarting it. Correctness, Quality and Evidence are three AI agents, each with its own prompt and each reading the reports of the ones before it: the first runs the repository's own checks and hunts for bugs, the second looks for duplication and maintainability problems, the third verifies every finding against the code and drops what it can't show. Publish shows you the finished comment and posts it on your confirmation. Each machine is also a drawing of your own — PR Pro's move as their stages work. You build a row like this in the editor: placing the machines, setting each one up, drawing each one, and passing work from one to the next. The manuscript The workflow editor walks through each of those steps.

III Run it

Switch the editor off and the workflow runs like any other. How you start it depends on its first machine:

  • With a ticket stage first — Ticket Scanner, Specifications or Single Prompt, or a machine of your own that queues tickets, like PR Pro's PR Scan — it works like the built-ins: Scan or Create fills the queue, and Start runs every queued ticket through the machines that follow. In PR Pro, Scan queues one ticket per open pull request and Start reviews them one after another.
  • Without one — a single Start under the first machine runs the whole row once, left to right.

Before a run begins, Expecto Centum checks every connection and agent its stages will use. If a sign-in has expired or a stage has nothing set up to run it, the Connection not working dialog says which, and nothing starts. PR Pro, for instance, needs the GitHub, GitLab or Bitbucket account that reads the pull requests, and an agent chosen for each of its three review machines. A machine can also carry a Test version of itself — every one of PR Pro's does — and with the row switched to Test it runs on canned pull requests, with no AI calls and nothing posted, so you can watch a workflow work before it touches anything real.

IV Share it

Click Share Workflow in the editor's bottom-right corner. Its Show the workflow's folder link opens the folder in your file browser — sharing the workflow means sharing that folder. Pass it on either way:

  • As an attachment — compress the folder into a .zip so it travels by email or chat as one file. The other person unpacks it and imports the folder.
  • On GitHub — make the folder a git repository and push it. Others clone it and import the clone. Add the repository's address to the workflow's header and everyone running a copy can find newer versions there. PR Pro is shared this way: its folder is the repository at github.com/alfonsocejudo/pr-pro, its header carries that address, and a README in the folder tells the reader how to install and set it up.

Bump the workflow's version in the header whenever it changes in a way people should notice. The header also shows the account that created the workflow.

V Install someone else's

Download the workflow — clone its repository, or unpack its archive. For PR Pro, that's one command wherever you keep repositories:

git clone https://github.com/alfonsocejudo/pr-pro.git

Then open Add New Workflow (or Add workflow in Config → Workflow), switch to the Import tab, and choose the downloaded folder. Then pick how it's added:

  • Copy it in — takes a copy now. The folder you picked can move or be deleted afterwards. For a later version, download it and import again.
  • Link to it where it is — follows the folder where it sits. If it's a repository, pulling an update makes it live straight away, and edits you make in the editor are written back to that folder. This is the right choice for PR Pro, which is distributed as a repository: a git pull in the clone brings the next version.

The workflow appears in the picker under its own name — the one in its header, not the folder's, so PR Pro lands as PR Pro whether you cloned it or unpacked an archive called pr-pro-main. If the import is refused, the message says why — usually an archive that wrapped everything in an extra folder (pick the one inside it), or a workflow by that name that's already installed.

VI Approve before it runs

A custom workflow is code that runs on your computer: its stages can read your files, reach the network and use your saved sign-ins. Workflows you create are yours and run without asking. One you got from someone else asks first — the first time you Start, Scan or Create with it, a Run this workflow's code? prompt appears. You can also approve it ahead of time from the Not trusted chip in the dashboard header. PR Pro is exactly the case the prompt exists for: its machines read your repositories, fetch pull requests with your saved sign-in and post comments under your name. Read its stage files before you approve it — its own README tells you the same.

  • Approve a workflow only if you trust where it came from. Importing never approves anything for you.
  • Approval covers the workflow exactly as it was. If any of its files change — a new version, or an edit — you're asked again before the next run.
  • Once you've reviewed a workflow and consider it yours, tick This is my workflow — trust my future edits too and stop asking in the prompt.
✦