Workflows

This page documents the deterministic orchestration layer of the
Claude Code setup: the workflow scripts that run the
subagents as fixed, reproducible pipelines. For the
lighter, single-context slash commands (including /maintenance), see
Commands.

Workflows

The files in .claude/workflows/ are deterministic orchestration scripts. Each
runs as a fixed pipeline of subagents with structured output, in the background, and
is invoked by its file name as a slash command. Run /workflows at any time to watch
live progress, pause, or stop a run.

Command	Type	What it does
/fleet	read-only	Runs all ten dimensions in parallel, then adversarially verifies every finding against the source before reporting it. The high-confidence, low-false-positive audit.
/review	read-only	Reviews the current git diff across every dimension with the same adversarial verification. A pre-commit gate.
/feature	build	Adds a feature across the full fan-out: understand the area, plan the layers, implement, audit completeness and security, fix gaps, and write tests.
/endpoint	build	Scaffolds one new route across every touchpoint (form model, output schema, guarded handler, mount, template, Devii action, API docs, SEO) and writes its test.
/devii-tool	build	Adds a Devii capability with auth flags matched to the route guard, dispatcher wiring, docs, and a test, then verifies role gating and confirmation.
/job-service	build	Scaffolds an async job service in the zip and fork pattern: the service class, enqueue, status, and download routes, the output schema, Devii tools, the frontend poller, and docs.

Read-only versus build workflows

The two read-only workflows (/fleet, /review) fan subagents out freely, since
nothing is written. The build workflows (/feature, /endpoint, /devii-tool,
/job-service) implement coherently in a single pass so that interdependent files
stay in agreement, then fan out again for a parallel audit, then fix gaps. They edit
files directly in the working tree, run the project validator and an import check
when done, and never run the test suite or commit.

Adversarial verification

The read-only workflows do something the simple /maintenance command does not:
each candidate finding is handed to a second, independent subagent instance whose
only task is to refute it against the source. A finding is reported only if it
survives that refutation. This directly enforces the project rule that a wrong
finding is worse than a missed one.

Passing input

Build workflows take a plain description as their argument:

/feature add a bookmark button to gists, owner-scoped, with a profile tab
/endpoint POST /gists/{slug}/star to star a gist
/devii-tool a tool to list the current user's bookmarks
/job-service render a project to a PDF and offer it as a download

The read-only workflows take no required input; /review accepts an optional base
git ref to diff against.

Where to start

For a routine change, run /review before committing. For a new capability, run the
matching build workflow and review its output. For a periodic deep audit, run
/fleet. All of them reuse the same ten subagents, so the quality bar is identical
no matter which entry point you choose.