Add pipeline workflow to community catalog

[domattioli]

What

Registers the Guided SDD Pipeline workflow in workflows/catalog.community.json.

The workflow itself is now hosted externally, per maintainer guidance (comment):

• Repository: https://github.com/domattioli/spec-kit-workflow-pipeline
• Release: v1.1.0
• Raw URL: https://raw.githubusercontent.com/domattioli/spec-kit-workflow-pipeline/v1.1.0/workflow.yml

What the workflow does

Chains specify → clarify (single interactive gate) → plan → tasks → analyze → implement → converge into one guided run. Optional constitution and checklist phases. Post-implement convergence loop replaces the earlier analyze/implement fix-loop, per review discussion.

Changes in this PR

• Removed the in-tree workflows/pipeline/ files (moved to the external repo above)
• Added the pipeline entry to workflows/catalog.community.json

Testing

• workflow.yml validates via specify workflow info
• Raw URL at the v1.1.0 tag verified fetchable (HTTP 200)
• Catalog JSON validates

[mnriem]

Thanks for this — the analyze/fix retry loop and the single-clarify-gate UX are genuinely nice, and the code is clean and well-tested.

Before going further, I'd like to steer this toward our workflows system, because that's precisely the mechanism Spec Kit ships for chaining /speckit.* phases into one guided, resumable invocation. The pipeline's charter — "collapse the manual command sequence into one command with a human checkpoint, orchestrating the stock commands rather than reimplementing them" — is verbatim what specify workflow run already does. The built-in speckit workflow (workflows/speckit/workflow.yml) already chains specify → plan → tasks → implement with review gates, and the engine natively provides everything the extension hand-rolls:

• Clarify gate → type: gate
• Analyze/fix loop (≤3 cycles) → type: while with max_iterations
• --skip / --add phases → boolean inputs guarding type: if steps
• Deterministic phase ordering + validation → the declarative steps: list (validated up front by specify workflow run)
• preview dry-run → specify workflow info ./workflow.yml
• Resume / state persistence / catalog distribution → for free

Concretely, here's your pipeline expressed as a single workflow.yml — no Python resolver, wrappers, or test suite needed, since the engine owns ordering and validation:

# workflow.yml
schema_version: "1.0"
workflow:
  id: "pipeline"
  name: "Guided SDD Pipeline"
  version: "1.0.0"
  author: "domattioli"
  description: >
    Chains specify → clarify → plan → tasks → analyze → implement into one
    guided run with a single clarify gate and an analyze/fix loop.

requires:
  speckit_version: ">=0.8.5"
  integrations:
    any: ["claude", "copilot", "gemini", "opencode"]

inputs:
  spec:
    type: string
    required: true
    prompt: "Describe what you want to build"
  integration:
    type: string
    default: "auto"
  with_constitution:   # replaces --add constitution
    type: boolean
    default: false
  with_checklist:      # replaces --add checklist
    type: boolean
    default: false
  skip_clarify:        # replaces --skip clarify
    type: boolean
    default: false
  max_fix_cycles:
    type: number
    default: 3

steps:
  - id: constitution
    type: if
    condition: "{{ inputs.with_constitution }}"
    then:
      - id: constitution-run
        command: speckit.constitution
        integration: "{{ inputs.integration }}"
        input: { args: "{{ inputs.spec }}" }

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

  - id: clarify
    type: if
    condition: "{{ inputs.skip_clarify == false }}"
    then:
      - id: clarify-run
        command: speckit.clarify
        integration: "{{ inputs.integration }}"
        input: { args: "{{ inputs.spec }}" }
      - id: clarify-gate
        type: gate
        message: "Review clarifications before planning."
        options: [approve, reject]
        on_reject: abort

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

  - id: checklist
    type: if
    condition: "{{ inputs.with_checklist }}"
    then:
      - id: checklist-run
        command: speckit.checklist
        integration: "{{ inputs.integration }}"
        input: { args: "{{ inputs.spec }}" }

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

  - id: analyze-first
    command: speckit.analyze
    integration: "{{ inputs.integration }}"
    continue_on_error: true
    input: { args: "{{ inputs.spec }}" }

  - id: fix-loop
    type: while
    condition: "{{ steps.analyze-first.output.exit_code != 0 }}"
    max_iterations: 3   # see note below on templating this
    steps:
      - id: apply-fixes
        command: speckit.implement
        integration: "{{ inputs.integration }}"
        input: { args: "Resolve the analyze findings for {{ inputs.spec }}" }
      - id: analyze-again
        command: speckit.analyze
        integration: "{{ inputs.integration }}"
        continue_on_error: true
        input: { args: "{{ inputs.spec }}" }

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

Two things to verify if you go this route:

1. max_iterations from an input — I hardcoded 3 above because I'm not certain the engine coerces a templated {{ inputs.max_fix_cycles }} at that field. If it accepts an expression, wire the input back in; if not, hardcoding is fine.
2. Analyze signaling — the loop assumes speckit.analyze returns non-zero when findings remain. If it always exits 0, branch on parsed output instead (an if/gate on steps.analyze-first.output).

If you'd like to publish this, the path is the community workflow catalog — see workflows/PUBLISHING.md. That gets it discoverable via specify workflow search/add while keeping it maintained in your own repo.

[domattioli]

Thanks for the feedback, mnriem. We've implemented the workflow approach you suggested instead of the extension.

Summary of changes

Created workflows/pipeline/workflow.yml that expresses the full pipeline using Spec Kit's workflows engine:

• Chains specify → clarify → plan → tasks → analyze → implement
• Optional phases: constitution, checklist
• Analyze/fix loop with configurable max cycles (default 3)
• Clarify gate (can be skipped)
• Full documentation in README.md and CHANGELOG.md

Advantages

• Uses engine-native if/while/gate constructs (no Python resolver needed)
• Declarative YAML configuration
• Built-in resume and state persistence via the engine
• Discoverable via specify workflow search
• Simpler to maintain

Validation

We validated the workflows/pipeline/workflow.yml locally against specify workflow run. It correctly handles the clarify gate (pausing for approval), phase sequencing, and resumability via specify workflow resume.

One fix along the way: max_iterations in the while step needs a literal integer — it doesn't accept a templated {{ inputs.max_fix_cycles }} expression, so we hardcoded it to 3 for now (matching your original suggestion).

Example invocation:

specify workflow run workflows/pipeline/workflow.yml --input 'spec=add user authentication with JWT tokens'

This runs the full pipeline and pauses at the clarify gate for approval before continuing to plan/tasks/analyze/implement.

[mnriem]

You are aware we have a converge command now too? Should that one be in play?

[domattioli]

You're right: converge fits better than my original pairing. Two changes:

1. Dropped the analyze/implement fix-loop. analyze checks artifact consistency, not code, so "fix via implement" was a verbiage bug that the orchestrator bot and I didn't catch.
2. Added a post-implement convergence loop per converge's own contract ("must run after implement"): implement → converge → (tasks appended?) → implement → converge…, capped at 3 cycles. A converged run leaves tasks.md untouched, so the loop stays safe even when the engine can't branch on converge's outcome. If steps.X.output can carry the converged/tasks_appended signal, I'll wire the condition to it.

Also removed the old extensions/pipeline/ tree (Python resolver + wrappers + tests) since the workflow supersedes it — the PR is now purely the workflows/pipeline/workflow.yml approach. Updated the workflow, README, and CHANGELOG.

[Copilot]

Pull request overview

This PR introduces a new “pipeline” workflow under workflows/ that aims to run the full Spec-Driven Development command sequence (with optional phases) as a single guided workflow, and adds accompanying documentation/changelog for publishing and use.

Changes:

• Added a new pipeline workflow YAML that chains Spec Kit phases and attempts a post-implement convergence loop.
• Added workflow documentation (README.md) and a workflow-local changelog (CHANGELOG.md).

Show a summary per file

File	Description
workflows/pipeline/workflow.yml	Defines the new pipeline workflow steps, inputs, requirements, and convergence loop logic.
workflows/pipeline/README.md	Documents workflow purpose, inputs, and usage examples.
workflows/pipeline/CHANGELOG.md	Tracks workflow version history and initial feature set.

Review details

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 3/3 changed files
• Comments generated: 9
• Review effort level: Low

[mnriem]

Similarly to our extension and presets we can host this in our community catalog. Please create it in your own GitHub repository so we can do so. See https://github.com/github/spec-kit/blob/main/workflows/PUBLISHING.md

[domattioli]

Done — the workflow now lives in its own repository:

• Repo: https://github.com/domattioli/spec-kit-workflow-pipeline (workflow.yml, README, CHANGELOG, MIT license)
• Release: v1.0.0, raw URL verified fetchable at the tag

This PR is reworked to only add the pipeline entry to workflows/catalog.community.json, per PUBLISHING.md. Let me know if you'd like any changes to the catalog entry.

[Copilot]

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 3
• Review effort level: Medium

[mnriem]

Please address Copilot feedback

[domattioli]

Addressed the Copilot feedback. The three active comments are all on the catalog entry, and each traced back to the external workflow, so I published a corrected release (v1.1.0) and repointed the catalog at it.

Convergence loop never ran. The while condition was steps.converge-first.output.exit_code != 0, which is false on any normal (exit 0) run, so the loop body never executed. There is also no outcome signal available to fix it "properly": command steps dispatch with stream=True, so stdout is returned empty, and speckit.converge exits 0 for both converged and tasks_appended. So neither exit_code nor stdout can distinguish the outcomes. I took the unconditional-bounded-loop route you offered: a do-while (condition: "true", max_iterations: 3) running converge → implement each cycle. A converged pass leaves tasks.md unchanged, so trailing cycles are safe no-ops. Verified against the engine with a stubbed dispatch: the loop runs 3 cycles now (converge x3, implement x4), versus 0 loop iterations before.

Minimum version. Raised requires.speckit_version to >=0.11.2 (the release that introduced speckit.converge) in both workflow.yml and the catalog entry; >=0.8.5 advertised a range that could not reach the convergence step.

README usage. All examples now pass inputs via --input key=value, matching specify workflow run <source> -i key=value. Also corrected the SDD expansion to "Spec-Driven Development" and removed the CHANGELOG trailing-whitespace hard break.

Catalog entry now points at .../v1.1.0/workflow.yml (verified fetchable, HTTP 200) with speckit_version >=0.11.2. specify workflow info validates clean.

[Copilot]

Review details

Comments suppressed due to low confidence (1)

workflows/catalog.community.json:24

• This entry now describes the v1.1.0 release published on 2026-07-22, so its updated_at should reflect that release/catalog update rather than 2026-07-21. The repository's catalog-update convention updates entry timestamps when versioned metadata changes (for example, .github/workflows/add-community-extension.md:191 and .github/workflows/add-community-preset.md:243).

      "updated_at": "2026-07-21T00:00:00Z"

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

workflows/catalog.community.json:24

• The entry now points to v1.1.0, which was published on 2026-07-22, but its updated_at still reports the previous day and disagrees with the catalog-level update date. Update this timestamp so consumers receive accurate catalog metadata for the release change.

      "updated_at": "2026-07-21T00:00:00Z"

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Medium

[mnriem]

Thank you!