Rules for AI-assisted delivery

From ticket to
verified release.

Give your coding agents a repeatable workflow.

Task readiness, coding, independent review, QA and release gates — defined in versioned rules you can inspect and adapt.

Start walkthrough Explore workflow Set up

Interactive example · no account or API key needed to explore

Example walkthroughWEB-123

One ticket, start to finish.

WFTasks prepares the context
Jev checks the ticket
WFCoder implements it
Jev picks the review
Review checks code and tests
QA tests the build
Jev decides to ship
WFRelease ships it

Human

WFTasks picks up the ticket and prepares the context: description, acceptance criteria, comments and history.
Jev checks the ticket against the rules. One criterion is unclear, so it asks a human instead of guessing.
The ticket owner clarifies it. Jev checks again: the ticket is ready.
WFCoder starts a coding agent in Superset. It implements the ticket until CI is green.
Jev decides how deep the review goes: a Codex review, an independent verification, or both.
An independent reviewer checks the code and whether the tests really prove it. It finds a gap.
The findings go back to WFCoder. It fixes the gap, and the review passes.
A QA engineer tests the reviewed build and passes it.
Jev checks it is safe to ship: QA passed, checks are green and nothing is blocking.
WFRelease ships it to staging, then to production after one more QA pass and Jev check. Done.

Simplified and illustrative, not a live run.

Step through it

01 / ORCHESTRATE

Grok Bot

Collects evidence, coordinates steps and handles results.

02 / EXECUTE

Superset

Runs coding agents in separate workspaces.

03 / DECIDE

Jev

Evaluates readiness and routing; the controller applies policy.

The interactive explorer

Follow the work. Inspect the rules.

Jev decides readiness. Workers implement. Independent reviewers challenge both the code and its tests.

100%

Click and drag to pan · Ctrl/⌘ + scroll to zoom · Double-click to focus · Click anything

Rules, evidence and decisions

Approved diagram verbatim from the approved SVG · Actual rule verbatim quote from a repository file · Documentation explanation UI summary · Illustrative example made-up web widget ticket

Make it your workflow

Scaffold it. Verify it. Let it run.

Install the full orchestration in Grok Bot, then verify each step or let the workflow run on its own when you are ready.

01 / INSTALL

Scaffold the fleet in Grok Bot

Bring an existing Grok Bot controller, Superset, a coding agent, tracker and GitHub access, and a TypeSafe API key.

Scaffold workflow, create required bots and assign roles.

Scaffold the bots. In the Grok Bot general chat, define github.com/BrRenat/workflow as the workflow source, then send the message above. Grok Bot creates WFTasks, WFJev, WFReview, WFCoder and WFRelease and assigns their roles. Only WFJev calls Jev.
Map your environment. Configure tracker states, repositories, model IDs, reviewers, QA and CI in local policy copies.
Prepare worker sessions. Install the coding and verification skills and the status hooks in each target project.
Run a shadow pilot. Inspect decisions for one task while every action stays disabled.

The controller runtime is external. This repository supplies skills, policies and helper scripts.

02 / RUN

Choose how it runs

Both modes start from a passing shadow pilot and change only your local policy copies.

Step by step

Enable one step at a time. Check each decision, action and result against its evidence before granting the next.

Full autonomy when ready

Grant every calibrated step. The workflow runs from intake to verified release; people act only where it names them:

Ticket owner, when acceptance criteria are unclear
QA on the reviewed and the staged build
Release owner, for reserved risks or named decisions
Named owners, for missing QA details or review decisions

Every gate still applies, and a score is never a permission. Example policies keep every action disabled.

From ticket toverified release.

Grok Bot ↗

Superset ↗

Jev ↗