# Workflows This page documents the deterministic orchestration layer of the [Claude Code setup](/docs/claude.html): the workflow scripts that run the [subagents](/docs/claude-agents.html) as fixed, reproducible pipelines. For the lighter, single-context slash commands (including `/maintenance`), see [Commands](/docs/claude-commands.html). ## 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.