Is your team using Spec Kit, but you hate having to remember the sequence /speckit-specify => /speckit-plan => /speckit-tasks => /speckit-implement ? you know it’s going to get it right, and let’s be honest, you’re not going to review all of that intermediate output anyway (you should, though).

Well, you should check out Spec Kit workflows. I don’t see much discussion of this feature in the Spec Kit community. I stumbled across it while going through a new project the other day, and it took me a while to figure out how to even invoke it (which is a little embarrassing). But once you find it, it’s a pretty straightforward command you run from the terminal, and it starts up Claude itself and drives the whole thing.

I ran the workflow that ships with the standard Spec Kit install, and it had the same basic gates as running the commands by hand. On one hand, that’s nice — you don’t have to remember the sequence anymore. On the other hand, sometimes I just want it to go all the way to the end. This is why we have source control. This is why we have branches. If it goes sideways, I throw away the branch and try again.

YOLO mode

So I wrote my own version of the shipped workflow, called YOLO. It removes the gates and runs through to completion. Invoking it is as simple as:

specify workflow run yolo -i spec="make the app do the thing"

Here’s the workflow definition (.specify/workflows/yolo/workflow.yml):

schema_version: "1.0"
workflow:
  id: "yolo"
  name: "Full SDD Cycle - no gates"
  version: "0.0.1"
  author: "clintcparker"
  description: "Runs specify → plan → tasks → implement without review gates"

requires:
  # 0.8.5 is the first release with engine-side resolution of the
  # ``integration: "auto"`` default. Older versions would treat "auto"
  # as a literal integration key and fail at dispatch.
  speckit_version: ">=0.8.5"
  integrations:
    # The four commands below (specify, plan, tasks, implement) are core
    # spec-kit commands provided by every integration. The list here is an
    # advisory, non-exhaustive compatibility hint following the documented
    # ``any: [...]`` schema -- it is NOT a closed set. The workflow runs
    # against any integration the project was initialized with, including
    # ones not listed below, as long as that integration provides the four
    # core commands referenced in ``steps``.
    any:
      - "claude"

inputs:
  spec:
    type: string
    required: true
    prompt: "Describe what you want to build"
  integration:
    type: string
    default: "auto"
    prompt: "Integration to use (e.g. claude, copilot, gemini; 'auto' uses the project's initialized integration)"
  scope:
    type: string
    default: "full"
    enum: ["full", "backend-only", "frontend-only"]

steps:
  - id: specify
    command: speckit.specify
    integration: "{{ inputs.integration }}"
    input:
      args: "{{ inputs.spec }}"

  - id: plan
    command: speckit.plan
    integration: "{{ inputs.integration }}"
    input:
      args: "{{ inputs.spec }}"

  - id: tasks
    command: speckit.tasks
    integration: "{{ inputs.integration }}"
    input:
      args: "{{ inputs.spec }}"

  - id: implement
    command: speckit.implement
    integration: "{{ inputs.integration }}"
    input:
      args: "{{ inputs.spec }}"

Just drop this file into the workflows directory inside your .specify directory. Then make sure you register it in the Spec Kit workflow registry (.specify/workflows/workflow-registry.json):

    "yolo": {
      "name": "Full SDD Cycle - no gates",
      "version": "0.0.1",
      "description": "Runs specify \u2192 plan \u2192 tasks \u2192 implement without review gates",
      "source": "local",
      "installed_at": "2026-07-28T21:16:32.525333+00:00",
      "updated_at": "2026-07-28T21:16:32.525333+00:00"
    }

That’s it. No gates, no babysitting 😊 kick it off and come back to a finished branch.

It’s better than I expected

Here’s the part that made me stop what I was doing. I kicked off a run on a project that has pretty rigid behavioral tests and behavioral testing guidelines set up, and this particular change touched a UI component. During the implementation phase, during the “implement” phase, Claude spawned Playwright on its own. I was doing other stuff on the machine, and I saw the browser come up and start clicking through the app, doing exactly the kind of manual validation I would have wanted to see anyway.

I’m running this with Claude Opus 5, and I’m extremely impressed. It comes back to the same thing it always comes back to: having a better idea of what you want to build at the end of the day. But this one knocked it out of the park. It was exactly like telling a competent engineer on my team, “hey, make this change” … and they did everything right. They followed every step, they documented it, they tested it.

Anyway, happy coding.

Update (2026-07-29): you don’t have to copy-paste this anymore

I’ve published YOLO as a proper Spec Kit add-on: clintcparker/speckit-addons. Skip the “drop this file in .specify/workflows/ and hand-edit the registry JSON” dance above — Spec Kit has a catalog mechanism, and now there’s a catalog to point it at.

Register the catalog once, then install:

specify workflow catalog add https://raw.githubusercontent.com/clintcparker/speckit-addons/main/workflows/catalog.json
specify workflow add yolo

Or grab just this one workflow without registering anything:

specify workflow add yolo --from https://raw.githubusercontent.com/clintcparker/speckit-addons/yolo-v0.1.0/workflows/yolo/workflow.yml

Either way, specify workflow run yolo -i spec="make the app do the thing" still works exactly the same.