Should SDD include a discovery and validation loop?

[pandeyshivendra]

I tried SDD yesterday and found the workflow a bit linear:

spec → plan → tasks → code

In practice, some assumptions in the spec can only be validated by inspecting the existing system and challenging the design against how it actually behaves.

I wonder if the workflow could be more iterative:

discover → spec → challenge → plan → implement → verify → update spec ↻

Or perhaps the workflow should vary depending on the type of system being built.

Curious if others have had a similar experience or if there’s already a recommended approach for this.

[mnriem]

Great observation — and the good news is SDD is meant to be exactly this composable. The linear spec → plan → tasks → implement is the core cycle, and the discovery/challenge/verify loops you're describing are provided as extensions and presets layered on top, rather than baked into the core:

• discover (inspect the existing system first) → brownfield extensions like brownkit do evidence-driven capability discovery for existing codebases.

• challenge (stress-test assumptions before planning) → the bundled assess extension (intake → research → define → shape → decide).

• verify / update spec ↻ → /speckit.analyze flags spec-drift between artifacts, and there's in-progress work on /speckit.revise ([Feature]: /speckit.revise - update the current spec without rewriting artifacts #4156) for updating a spec without rewriting everything.

• "vary by system type" → that's what presets (compose different command-template flavors) and bundles (package a tailored pipeline) are for.

So you'd build your discover → spec → challenge → … → verify ↻ flow by composing those pieces for your project type. If you try it and hit a gap none of them cover, that's worth a feature-assess issue. Thanks for the thoughtful write-up.

[soul-sol]

The loop shape looks right. The step I'd put pressure on is verify, because it's the
one that silently degrades into "the agent said it worked".

Two things that decided whether verify meant anything for me:

1. The spec line has to be able to come out false. "Handles errors gracefully"
   cannot fail; nothing in it is checkable. "On a 5xx from X, the request is retried at
   most twice and the final status is written to Y" can. If a spec line has no check, the
   verify step has nothing to run and quietly becomes a summary of the diff.

2. Verification needs both cases. A verify step only ever exercised on the passing
   path is indistinguishable from one that returns a constant. Two defects I shipped
   yesterday were both in checking code whose suites were fully green: a grep -q under
   pipefail that reported a real match as absent once input passed the pipe buffer, and
   a counter using grep -c where a genuine zero and a broken connection produced the
   same recorded 0. Neither would have survived a required failing case.

For the challenge step specifically, the version that worked for me is adversarial
rather than confirmatory: assume the spec is wrong about the existing system, and
produce the observation that would show it. Asked confirmatorily, the model reliably
finds that the design is fine.

Prompts written that way, MIT: https://github.com/soul-sol/ai-code-review-prompts

[mnriem]

Thanks for sharing these. Since you've got the prompts already (and MIT-licensed), would you consider packaging them as a community preset? Prompts that shape how the challenge/verify phases behave are exactly what command-template presets are for — it'd land in the community catalog as your own maintained, attributed contribution, more discoverable and reusable than a discussion comment. The publishing guide walks through the [Preset] submission flow.