|
| 1 | +# Workflows |
| 2 | + |
| 3 | +Workflows automate multi-step Spec-Driven Development processes — chaining commands, prompts, shell steps, and human checkpoints into repeatable sequences. They support conditional logic, loops, fan-out/fan-in, and can be paused and resumed from the exact point of interruption. |
| 4 | + |
| 5 | +## Run a Workflow |
| 6 | + |
| 7 | +```bash |
| 8 | +specify workflow run <source> |
| 9 | +``` |
| 10 | + |
| 11 | +| Option | Description | |
| 12 | +| ------------------- | -------------------------------------------------------- | |
| 13 | +| `-i` / `--input` | Pass input values as `key=value` (repeatable) | |
| 14 | + |
| 15 | +Runs a workflow from a catalog ID, URL, or local file path. Inputs declared by the workflow can be provided via `--input` or will be prompted interactively. |
| 16 | + |
| 17 | +Example: |
| 18 | + |
| 19 | +```bash |
| 20 | +specify workflow run speckit -i spec="Build a kanban board with drag-and-drop task management" -i scope=full |
| 21 | +``` |
| 22 | + |
| 23 | +> **Note:** All workflow commands require a project already initialized with `specify init`. |
| 24 | +
|
| 25 | +## Resume a Workflow |
| 26 | + |
| 27 | +```bash |
| 28 | +specify workflow resume <run_id> |
| 29 | +``` |
| 30 | + |
| 31 | +Resumes a paused or failed workflow run from the exact step where it stopped. Useful after responding to a gate step or fixing an issue that caused a failure. |
| 32 | + |
| 33 | +## Workflow Status |
| 34 | + |
| 35 | +```bash |
| 36 | +specify workflow status [<run_id>] |
| 37 | +``` |
| 38 | + |
| 39 | +Shows the status of a specific run, or lists all runs if no ID is given. Run states: `created`, `running`, `completed`, `paused`, `failed`, `aborted`. |
| 40 | + |
| 41 | +## List Installed Workflows |
| 42 | + |
| 43 | +```bash |
| 44 | +specify workflow list |
| 45 | +``` |
| 46 | + |
| 47 | +Lists workflows installed in the current project. |
| 48 | + |
| 49 | +## Install a Workflow |
| 50 | + |
| 51 | +```bash |
| 52 | +specify workflow add <source> |
| 53 | +``` |
| 54 | + |
| 55 | +Installs a workflow from the catalog, a URL (HTTPS required), or a local file path. |
| 56 | + |
| 57 | +## Remove a Workflow |
| 58 | + |
| 59 | +```bash |
| 60 | +specify workflow remove <workflow_id> |
| 61 | +``` |
| 62 | + |
| 63 | +Removes an installed workflow from the project. |
| 64 | + |
| 65 | +## Search Available Workflows |
| 66 | + |
| 67 | +```bash |
| 68 | +specify workflow search [query] |
| 69 | +``` |
| 70 | + |
| 71 | +| Option | Description | |
| 72 | +| ------- | --------------- | |
| 73 | +| `--tag` | Filter by tag | |
| 74 | + |
| 75 | +Searches all active catalogs for workflows matching the query. |
| 76 | + |
| 77 | +## Workflow Info |
| 78 | + |
| 79 | +```bash |
| 80 | +specify workflow info <workflow_id> |
| 81 | +``` |
| 82 | + |
| 83 | +Shows detailed information about a workflow, including its steps, inputs, and requirements. |
| 84 | + |
| 85 | +## Catalog Management |
| 86 | + |
| 87 | +Workflow catalogs control where `search` and `add` look for workflows. Catalogs are checked in priority order. |
| 88 | + |
| 89 | +### List Catalogs |
| 90 | + |
| 91 | +```bash |
| 92 | +specify workflow catalog list |
| 93 | +``` |
| 94 | + |
| 95 | +Shows all active catalog sources. |
| 96 | + |
| 97 | +### Add a Catalog |
| 98 | + |
| 99 | +```bash |
| 100 | +specify workflow catalog add <url> |
| 101 | +``` |
| 102 | + |
| 103 | +| Option | Description | |
| 104 | +| --------------- | -------------------------------- | |
| 105 | +| `--name <name>` | Optional name for the catalog | |
| 106 | + |
| 107 | +Adds a custom catalog URL to the project's `.specify/workflow-catalogs.yml`. |
| 108 | + |
| 109 | +### Remove a Catalog |
| 110 | + |
| 111 | +```bash |
| 112 | +specify workflow catalog remove <index> |
| 113 | +``` |
| 114 | + |
| 115 | +Removes a catalog by its index in the catalog list. |
| 116 | + |
| 117 | +### Catalog Resolution Order |
| 118 | + |
| 119 | +Catalogs are resolved in this order (first match wins): |
| 120 | + |
| 121 | +1. **Environment variable** — `SPECKIT_WORKFLOW_CATALOG_URL` overrides all catalogs |
| 122 | +2. **Project config** — `.specify/workflow-catalogs.yml` |
| 123 | +3. **User config** — `~/.specify/workflow-catalogs.yml` |
| 124 | +4. **Built-in defaults** — official catalog + community catalog |
| 125 | + |
| 126 | +## Workflow Definition |
| 127 | + |
| 128 | +Workflows are defined in YAML files. Here is the built-in **Full SDD Cycle** workflow that ships with Spec Kit: |
| 129 | + |
| 130 | +```yaml |
| 131 | +schema_version: "1.0" |
| 132 | +workflow: |
| 133 | + id: "speckit" |
| 134 | + name: "Full SDD Cycle" |
| 135 | + version: "1.0.0" |
| 136 | + author: "GitHub" |
| 137 | + description: "Runs specify → plan → tasks → implement with review gates" |
| 138 | + |
| 139 | +requires: |
| 140 | + speckit_version: ">=0.7.2" |
| 141 | + integrations: |
| 142 | + any: ["copilot", "claude", "gemini"] |
| 143 | + |
| 144 | +inputs: |
| 145 | + spec: |
| 146 | + type: string |
| 147 | + required: true |
| 148 | + prompt: "Describe what you want to build" |
| 149 | + integration: |
| 150 | + type: string |
| 151 | + default: "copilot" |
| 152 | + prompt: "Integration to use (e.g. claude, copilot, gemini)" |
| 153 | + scope: |
| 154 | + type: string |
| 155 | + default: "full" |
| 156 | + enum: ["full", "backend-only", "frontend-only"] |
| 157 | + |
| 158 | +steps: |
| 159 | + - id: specify |
| 160 | + command: speckit.specify |
| 161 | + integration: "{{ inputs.integration }}" |
| 162 | + input: |
| 163 | + args: "{{ inputs.spec }}" |
| 164 | + |
| 165 | + - id: review-spec |
| 166 | + type: gate |
| 167 | + message: "Review the generated spec before planning." |
| 168 | + options: [approve, reject] |
| 169 | + on_reject: abort |
| 170 | + |
| 171 | + - id: plan |
| 172 | + command: speckit.plan |
| 173 | + integration: "{{ inputs.integration }}" |
| 174 | + input: |
| 175 | + args: "{{ inputs.spec }}" |
| 176 | + |
| 177 | + - id: review-plan |
| 178 | + type: gate |
| 179 | + message: "Review the plan before generating tasks." |
| 180 | + options: [approve, reject] |
| 181 | + on_reject: abort |
| 182 | + |
| 183 | + - id: tasks |
| 184 | + command: speckit.tasks |
| 185 | + integration: "{{ inputs.integration }}" |
| 186 | + input: |
| 187 | + args: "{{ inputs.spec }}" |
| 188 | + |
| 189 | + - id: implement |
| 190 | + command: speckit.implement |
| 191 | + integration: "{{ inputs.integration }}" |
| 192 | + input: |
| 193 | + args: "{{ inputs.spec }}" |
| 194 | +``` |
| 195 | +
|
| 196 | +This produces the following execution flow: |
| 197 | +
|
| 198 | +```mermaid |
| 199 | +flowchart TB |
| 200 | + A["specify<br/>(command)"] --> B{"review-spec<br/>(gate)"} |
| 201 | + B -- approve --> C["plan<br/>(command)"] |
| 202 | + B -- reject --> X1["⏹ Abort"] |
| 203 | + C --> D{"review-plan<br/>(gate)"} |
| 204 | + D -- approve --> E["tasks<br/>(command)"] |
| 205 | + D -- reject --> X2["⏹ Abort"] |
| 206 | + E --> F["implement<br/>(command)"] |
| 207 | + |
| 208 | + style A fill:#49a,color:#fff |
| 209 | + style B fill:#a94,color:#fff |
| 210 | + style C fill:#49a,color:#fff |
| 211 | + style D fill:#a94,color:#fff |
| 212 | + style E fill:#49a,color:#fff |
| 213 | + style F fill:#49a,color:#fff |
| 214 | + style X1 fill:#999,color:#fff |
| 215 | + style X2 fill:#999,color:#fff |
| 216 | +``` |
| 217 | + |
| 218 | +Run it with: |
| 219 | + |
| 220 | +```bash |
| 221 | +specify workflow run speckit -i spec="Build a kanban board with drag-and-drop task management" |
| 222 | +``` |
| 223 | + |
| 224 | +## Step Types |
| 225 | + |
| 226 | +| Type | Purpose | |
| 227 | +| ------------ | ------------------------------------------------ | |
| 228 | +| `command` | Invoke a Spec Kit command (e.g., `speckit.plan`) | |
| 229 | +| `prompt` | Send an arbitrary prompt to the AI coding agent | |
| 230 | +| `shell` | Execute a shell command and capture output | |
| 231 | +| `gate` | Pause for human approval before continuing | |
| 232 | +| `if` | Conditional branching (then/else) | |
| 233 | +| `switch` | Multi-branch dispatch on an expression | |
| 234 | +| `while` | Loop while a condition is true | |
| 235 | +| `do-while` | Execute at least once, then loop on condition | |
| 236 | +| `fan-out` | Dispatch a step for each item in a list | |
| 237 | +| `fan-in` | Aggregate results from a fan-out step | |
| 238 | + |
| 239 | +## Expressions |
| 240 | + |
| 241 | +Steps can reference inputs and previous step outputs using `{{ expression }}` syntax: |
| 242 | + |
| 243 | +| Namespace | Description | |
| 244 | +| ------------------------------ | ------------------------------------ | |
| 245 | +| `inputs.spec` | Workflow input values | |
| 246 | +| `steps.specify.output.file` | Output from a previous step | |
| 247 | +| `item` | Current item in a fan-out iteration | |
| 248 | + |
| 249 | +Available filters: `default`, `join`, `contains`, `map`. |
| 250 | + |
| 251 | +Example: |
| 252 | + |
| 253 | +```yaml |
| 254 | +condition: "{{ steps.test.output.exit_code == 0 }}" |
| 255 | +args: "{{ inputs.spec }}" |
| 256 | +message: "{{ status | default('pending') }}" |
| 257 | +``` |
| 258 | +
|
| 259 | +## Input Types |
| 260 | +
|
| 261 | +| Type | Coercion | |
| 262 | +| --------- | ------------------------------------------------- | |
| 263 | +| `string` | Pass-through | |
| 264 | +| `number` | `"42"` → `42`, `"3.14"` → `3.14` | |
| 265 | +| `boolean` | `"true"` / `"1"` / `"yes"` → `True` | |
| 266 | + |
| 267 | +## State and Resume |
| 268 | + |
| 269 | +Each workflow run persists its state at `.specify/workflows/runs/<run_id>/`: |
| 270 | + |
| 271 | +- `state.json` — current run state and step progress |
| 272 | +- `inputs.json` — resolved input values |
| 273 | +- `log.jsonl` — step-by-step execution log |
| 274 | + |
| 275 | +This enables `specify workflow resume` to continue from the exact step where a run was paused (e.g., at a gate) or failed. |
| 276 | + |
| 277 | +## FAQ |
| 278 | + |
| 279 | +### What happens when a workflow hits a gate step? |
| 280 | + |
| 281 | +The workflow pauses and waits for human input. Run `specify workflow resume <run_id>` after reviewing to continue. |
| 282 | + |
| 283 | +### Can I run the same workflow multiple times? |
| 284 | + |
| 285 | +Yes. Each run gets a unique ID and its own state directory. Use `specify workflow status` to see all runs. |
| 286 | + |
| 287 | +### Who maintains workflows? |
| 288 | + |
| 289 | +Most workflows are independently created and maintained by their respective authors. The Spec Kit maintainers do not review, audit, endorse, or support workflow code. Review a workflow's source before installing and use at your own discretion. |
0 commit comments