Expose built-in extension flows as specify workflow pipelines (extension-owned workflows)

[markuswondrak]

The specify workflow engine currently ships exactly one workflow: the full SDD cycle (workflows/speckit/workflow.yml — specify → plan → tasks → implement with review gates, resumable state). The two bundled pipeline extensions have multi-step flows of exactly that shape, but they can only be driven by invoking each command manually:

• bug extension: speckit.bug.assess → speckit.bug.fix → speckit.bug.test (per-bug reports under .specify/bugs/<slug>/)
• assess extension: speckit.assess.intake → research → define → shape → decide (per-idea artifacts under .specify/assessments/<slug>/)

This is not a feature-parity issue — the commands work fine on their own. It's a convenience gap: the one flow that is orchestratable (speckit) gets gates, persisted state, and workflow resume for free, while the extension pipelines don't, even though the engine supports everything they'd need.

Proposal

Let extensions declare workflows in extension.yml, so the workflow installs, updates, and uninstalls with the extension that owns it:

provides:
  commands: [...]
  workflows:
    - id: bugfix
      file: workflows/bugfix.yml

With that in place, two small built-in workflows would ship with the existing extensions:

• bugfix (ships with bug): assess → gate "review the assessment before any code change" → fix → test. The gate maps the extension's "no code change before a reviewed assessment" guardrail onto engine semantics; a reject aborts the run.
• assess (ships with assess): intake → research → define → shape → decide → gate to review the verdict in decision.md. Ends there — the handoff to /speckit.specify stays a deliberate, separate step, matching the extension's stated philosophy.

No change to the engine itself — installed workflows are already resolved through the registry. The only new machinery is the extension lifecycle wiring:

1. extension add copies the workflow YAML to .specify/workflows/<id>/workflow.yml and registers it (source: extension:<id>)
2. Existing workflow IDs are never clobbered — collision means skip with a warning
3. extension remove uninstalls the workflow only if unmodified; edited files are skipped with a warning
4. extension update reinstalls the workflow on version change
5. workflow remove/update on an extension-owned workflow points at the owning extension instead

Deliberate non-goals

• git extension — its commands already run automatically via lifecycle hooks; a workflow would duplicate that.
• agent-context extension — a single maintenance command driven by hooks, not a multi-step flow.

Since the workflow ships inside the extension, the prerequisite problem solves itself: a workflow can't be installed without the extension that provides the commands it calls. No requires.extensions schema key needed.

Happy to work out a full implementation plan if this sounds like something spec-kit should have.

[mnriem]

Thanks for the detailed write-up — but I don't think we want extensions to own workflows. Spec Kit's layers are deliberate: extensions provide commands + hooks, presets compose templates, workflows orchestrate, and bundles are the mechanism for grouping any of these together with coherent install/update/uninstall. So the orchestratable bugfix flow you're after is exactly a bundle — ship the bug extension together with a bugfix workflow as one bundle, and bundle install gives you both with the lifecycle coupling you described. Adding provides.workflows to extension.yml would duplicate the bundle layer inside the extension layer, which is the wrong place for it. For the two first-party pipeline extensions, the path is to package each as a bundle that includes its workflow. Let me know if there's something a bundle genuinely can't express here, otherwise I'd rather keep workflow ownership out of extensions.

[markuswondrak]

Fair enough — bundles make sense.

Quick sketch of what I have in mind: the actual gap is that the only out-of-the-box workflow is the SDD cycle (speckit). Nothing equivalent ships for bug or assess, so those flows stay manual invoke-per-command. What about shipping two small first-party bundles instead — bugfix (bug extension + a bundled bugfix workflow: assess → gate → fix → test) and assess (assess extension + workflow: intake → … → decide → gate, stop there)? One bundle add gives you the extension plus its orchestrated pipeline, and bundles already handle install/update/remove for the pair.

Any thoughts on whether that's worth doing, and roughly where the workflow YAML + bundle artifacts should live for first-party content?

[mnriem]

Yes, this is worth doing — and it's the right shape: two first-party bundles composing existing pieces, no new contribution type. It fills a real gap (only speckit ships an out-of-box workflow today; bug and assess are manual per-command).

On placement: workflows have their own layer, so these belong alongside the SDD one — workflows/bugfix/workflow.yml and workflows/assess/workflow.yml (parallel to workflows/speckit/workflow.yml), registered in workflows/catalog.json. The bundle (in bundles/catalog.json) is then just the thin composition that pairs each extension with its workflow, so bundle add installs the pair with coherent install/update/remove. That keeps each layer in its own home — the workflow in the workflow layer, the composition in the bundle layer — which is the same separation-of-layers reasoning as keeping workflows out of extension.yml.

Want to move this to a [Feature] issue for an acceptance-criteria pass? If you're up for implementing, I'd scope it as the two workflows + their bundles, reusing the bug/assess command surfaces unchanged — happy to have you take it.