[Feature]: Add example “hands-off” Spec Kit orchestration workflow for autonomous spec creation

[cerebral-valley]

Problem Statement

Summary

I'd like to contribute a repo-hosted example of a "hands-off" Spec Kit orchestration agent/workflow for autonomous spec creation first, with safe gates before issue creation or implementation.

The goal is not to change Spec Kit’s core philosophy, but to provide a practical example/pattern for users who want a more automated multi-step flow built on top of the existing Spec Kit stages.

Problem

Today, Spec Kit provides strong individual stages like:

• specify
• clarify
• plan
• checklist
• tasks
• analyze
• implement

But users who want a more autonomous "orchestrated" experience still have to decide:

• how to sequence these stages safely
• when to stop vs continue
• when to ask the user for a decision
• when issue creation should happen
• when implementation should not happen automatically

There are also workflow-oriented discussions in the repo around more structured orchestration and around treating clarify/checklist/analyze as more explicit parts of a standard flow.

Proposed Solution

Proposal

I'd like to contribute a repository example for a Spec Kit autonomous orchestrator that:

• starts from the user request
• runs specify
• runs clarify
• runs plan
• runs checklist
• runs tasks
• runs analyze
• stops by default after artifact generation
• only creates issues if explicitly requested
• only implements if explicitly requested

Design goals

• artifact-first, not auto-implementation-first
• safe defaults
• explicit stop conditions
• explicit loop-back behavior when artifacts become stale
• suitable for users who want a higher-assurance, more automated workflow

Scope

What I am proposing to contribute is one of the following, depending on maintainer preference:

1. Documentation example
   • a documented example of a hands-off orchestrator/workflow
2. Example workflow/agent file
   • contributed as an example/pattern in the repo
3. Reference workflow contribution
   • if maintainers think this belongs as a first-class workflow example

Constraints for the initial proposal

For the first version, I want to keep it intentionally conservative:

• use only README.md and DESIGN.md as in-repo guidance sources
• add a visible warning about those constraints
• no automatic issue creation unless explicitly requested
• no automatic implementation unless explicitly requested

Non-goals

This is not intended to:

• force a new default behavior for Spec Kit
• replace the existing stage-by-stage workflow
• introduce hidden autonomous implementation
• assume all users want bypassed approvals

Why I think this fits the repo

Spec Kit already has workflow support and an explicit multi-stage SDD model, and there are existing issues around higher-level orchestration and making clarification/analysis/checklist part of a more standard flow. This proposal is meant to build on that direction as an example users can adopt or adapt.

Questions for maintainers

1. Would you prefer this as:

   • docs only,
   • an example workflow/agent file,
   • or a more official workflow contribution?

2. Is there an existing preferred location for contributed orchestration examples?

3. If this seems in-scope, I’m happy to open a PR with the proposed example and docs.

Alternatives Considered

No response

Component

Agent integrations (command files, workflows)

AI Agent (if applicable)

All agents

Use Cases

Specific use cases

• Teams that want autonomous spec creation without autonomous coding
  A user can describe a feature once, and the orchestrator reliably runs specify -> clarify -> plan -> checklist -> tasks -> analyze, then stops with ready-to-review artifacts instead of immediately implementing code.

• Repos that want a consistent artifact-first workflow for every feature request
  Instead of each contributor manually deciding which Spec Kit stages to run and in what order, the orchestrator provides a repeatable default flow with explicit gates and stop conditions.

• Product or engineering leads preparing implementation-ready work for others
  A lead can use the orchestrator to turn a rough feature idea into a clarified spec, technical plan, and task breakdown that another engineer or agent can implement later.

• Users who want safer automation with explicit escalation points
  The orchestrator can resolve straightforward ambiguity from repo guidance, but pauses when a real product decision is required, reducing the risk of silently making the wrong choice.

• Issue-driven teams that want task generation before execution
  A user can request tracking-only output so the orchestrator produces tasks and optionally converts them into issues, without implementing the feature.

• Contributors who want a reference example for advanced Spec Kit orchestration
  The repository can provide a concrete example of how to combine existing stages like clarify, checklist, and analyze into a higher-assurance workflow.

Acceptance Criteria

Acceptance Criteria

• A repo-contributed example workflow or agent is available that orchestrates these stages in order:

  1. speckit.specify
  2. speckit.clarify
  3. speckit.plan
  4. speckit.checklist
  5. speckit.tasks
  6. speckit.analyze

• The example has safe default behavior:

  • stops after artifact generation unless the user explicitly requests issue creation or implementation
  • does not create issues unless explicitly requested
  • does not implement unless explicitly requested

• The example defines clear loop-back behavior:

  • reruns earlier stages when clarify, checklist, or analyze reveal stale, incomplete, or inconsistent artifacts

• The example defines clear escalation behavior:

  • asks the user when a true product decision is required instead of guessing

• The example is documented clearly enough that a user can understand:

  • when to use it
  • what it automates
  • what it intentionally does not automate

• The workflow or example is reviewed and accepted by maintainers as aligned with Spec Kit’s intended stage ordering and suitable as a repository example, documentation example, or reference workflow.

Additional Context

Additional context

I am proposing this as an example contribution, not as a mandatory change to Spec Kit’s default behavior.

The main idea is to provide a repo-hosted pattern for users who want a more autonomous but still safe orchestration layer on top of existing Spec Kit stages.

Proposed behavior at a glance

Default flow:

1. speckit.specify
2. speckit.clarify
3. speckit.plan
4. speckit.checklist
5. speckit.tasks
6. speckit.analyze
7. stop and report readiness

Optional follow-up stages:

• speckit.taskstoissues only if the user explicitly requests issue creation
• speckit.implement only if the user explicitly requests implementation

Why this seems useful

Spec Kit already provides the building blocks for a strong staged workflow, but users still have to decide how to safely compose them. A contributed example could help demonstrate:

• an artifact-first workflow
• explicit stop conditions
• explicit loop-back behavior
• safer defaults around issue creation and implementation

Constraints I would keep in the first version

• use only README.md and DESIGN.md as in-repo guidance sources
• add a visible warning about those constraints
• avoid relying on other repo documents unless explicitly provided by the user
• keep issue creation and implementation opt-in

Example user scenarios

• “Take this rough feature request and produce a reviewed-ready spec, plan, tasks, and analysis, but do not implement anything.”
• “Generate the full set of artifacts, then convert tasks into issues for tracking.”
• “Run the artifact flow first, and only implement if I explicitly confirm.”

What I am asking maintainers

I mainly want guidance on whether this is best contributed as:

• a docs example
• an example workflow/agent file
• or a more official reference workflow

If this is considered in-scope, I’d be happy to open a PR with the proposed example and documentation.

[mnriem]

Lets start with a docs example for our website? Please review the existing ones in the docs directory for that

[meow2149]

Hi, I'd like to work on this as a docs example for the website, following the existing examples in the docs directory as suggested. I'll keep the first pass focused on documenting a safe artifact-first orchestration pattern and open a draft PR shortly for feedback.