An SDD workflow is a stage machine that turns an idea (or a change to an existing codebase) into a set of spec files, one stage per file, each gated by review. MySpec runs three methodologies - MySpec, Spec Kit, and OpenSpec - as four selectable generate workflows plus two Edit workflows (greenfield and brownfield), so a team keeps its folder conventions and CLI while the interviewing and drafting are automated.
Every good firm follows the same discipline - understand the client, fix the rules, specify, design, schedule - but each has its own document set and its own way of numbering drawings. MySpec's own firm produces the four-file bundle. The Spec Kit firm numbers every feature 001-, 002- and keeps one constitution in a shared binder. The OpenSpec firm never re-draws the building: it files change orders that redline the capability drawings already on record. Hire the firm whose filing system your building department (your repo and CLI) already accepts.
Side by side
| MySpec greenfield | MySpec brownfield | Spec Kit | OpenSpec | |
|---|---|---|---|---|
| Scope | New product / project | Change to an existing codebase | One new feature in a project | Change to an existing codebase |
| Entry stage | Interview (product only, no tech) | Interview that reads your code | Interview (single feature) | Explore (reads your code) |
| Stages | constitution → requirements → solution → tasks | proposal → requirements delta → tasks (optional) | constitution → specify → plan → tasks | proposal → specs → design → tasks |
| Files | constitution.md, requirements.md, solution.md, tasks.md | proposal.md, requirements.md (AR/BR/CR), tasks.md | memory/constitution.md, spec.md, plan.md, tasks.md | proposal.md, specs/<cap>/spec.md, design.md, tasks.md |
| Root | specs/<bundle>/ | specs/<change>/ | specs/memory/ + specs/NNN-feature/ | openspec/changes/<id>/ |
| Requirement style | FR-/NFR- + EARS+ | AR-/BR-/CR- + EARS+ | User stories P1–P3, FR-/SC- | ADDED / MODIFIED / REMOVED / RENAMED + WHEN/THEN |
| Extra artefacts | C4 diagrams, requirement diagrams, delivery plan, QA milestone | Requirement diagram, QA tasks | Constitution Check gates, Sync Impact Report | Capability contract |
| Compatible CLI | MySpec MCP server | MySpec MCP server | GitHub Spec Kit (specify) | OpenSpec CLI (openspec, /opsx) |
The four stage machines
MySpec generate-workflow (greenfield)
greenfield · myspec-greenfield-v1
- 1 Interviewno file yet
- 2 Constitutionwrites constitution.md
- 3 Requirementswrites requirements.md
- 4 Solutionwrites solution.md
- 5 Taskswrites tasks.md
- Completehand off via MCP or ZIP
Every file-writing stage runs three substages - collect (clarifying questions) → generate (draft the file) → review (an independent reviewer checks it against the template and your answers). You approve, edit, or send it back before the next stage starts.
MySpec generate-brownfield
brownfield · myspec-brownfield-v1
- 1 Interview (explores your code)no file yet
- 2 Proposalwrites proposal.md
- 3 Requirements deltawrites requirements.md
- 4 Taskswrites tasks.md optional
- Completehand off via MCP or ZIP
Every file-writing stage runs three substages - collect (clarifying questions) → generate (draft the file) → review (an independent reviewer checks it against the template and your answers). You approve, edit, or send it back before the next stage starts.
SpecKit generate-greenfield
greenfield · speckit-greenfield-v1
- 1 Interviewno file yet
- 2 Constitutionwrites specs/memory/constitution.md
- 3 Specifywrites spec.md
- 4 Planwrites plan.md
- 5 Taskswrites tasks.md
- Completehand off via MCP or ZIP
Every file-writing stage runs three substages - collect (clarifying questions) → generate (draft the file) → review (an independent reviewer checks it against the template and your answers). You approve, edit, or send it back before the next stage starts.
OpenSpec generate-brownfield
brownfield · openspec-brownfield-v1
- 1 Explore (reads your code)no file yet
- 2 Proposalwrites proposal.md
- 3 Delta specswrites specs/<capability>/spec.md
- 4 Solutionwrites design.md
- 5 Taskswrites tasks.md
- Completehand off via MCP or ZIP
Every file-writing stage runs three substages - collect (clarifying questions) → generate (draft the file) → review (an independent reviewer checks it against the template and your answers). You approve, edit, or send it back before the next stage starts.
Every file-writing stage is gated: collect asks the clarifying questions that file needs, generate drafts it against a strict template, and review hands it to an independent reviewer agent that checks structure, traceability to your answers, and consistency with the earlier files. OpenSpec skips collect on its spec stages but keeps generate and review. You approve, edit in the WYSIWYG editor, or type /goback to return to any earlier stage.
Which one to pick
- Default: MySpec brownfield - the leaner flow: a code-reading interview, a technical proposal, and an AR/BR/CR requirements delta; tasks only if you want them.
- Already on OpenSpec: OpenSpec - per-capability deltas that
openspec archivemerges into your baselines.
A project is created as greenfield or brownfield, and the workflow picker only offers matching methodologies (MySpec first). Both brownfield workflows refuse to write a proposal until they have read real files - via a mounted folder in Chrome or the MCP server's reverse mode.
What every workflow gives you
- Multiple-choice interviews with option cards enriched from a catalogue of ~1,000 technologies, and a curated skill recommendation (framework or domain guidance the generator then follows) once the entry stage ends.
- Independent review on every generated file, plus a Business-Analyst, Project-Manager, and QA-Engineer pass where the file shape allows it.
- Your model, your language - Gemini, Claude, or GPT families per session (Auto by default); specs written in English, Japanese, Vietnamese, or Chinese.
- Edit workflow - reference files → describe changes → review each change as a diff before it is applied; manual WYSIWYG edits are summarised back into the AI's context.
- Versioned revisions, diffs, and a Trash Bin for every file; attachments (PDF, DOCX, XLSX, text) as interview context.
- Hand-off through the MCP server (stdio or hosted HTTP), a ZIP of the whole project, or a read-only public share link.
specs/<bundle>/ MySpec greenfield
specs/<change>/ MySpec brownfield
specs/memory/constitution.md Spec Kit (shared)
specs/<NNN-feature>/ Spec Kit feature
openspec/changes/<change-id>/ OpenSpec change
openspec/specs/<capability>/spec.md OpenSpec baselines (after apply)The three SDD workflows
The default four-file bundle: interview → constitution → requirements → solution → tasks.
GitHub Spec Kit's feature-scoped flow: interview → constitution → specify → plan → tasks.
OpenSpec's change-proposal flow: explore → proposal → delta specs → design → tasks.
All spec file types
Project vision, core principles, and the MUST / MUST NOT constraints every later file has to obey.
User roles, FR-/NFR- requirements with EARS+ acceptance criteria; a coded AR-/BR-/CR- delta for brownfield changes.
Architecture, modules, data model, and API design with Mermaid flowchart, ER and sequence diagrams - plus C4 diagrams when your organisation enables them.
Ordered, sized implementation tasks grouped into milestones, traced back to requirement IDs.
Why a brownfield change is needed, what changes, the technical solution, and its impact on existing code.
Spec Kit's prioritised user stories and success criteria, or OpenSpec's ADDED / MODIFIED / REMOVED / RENAMED requirement deltas.
Spec Kit's technical plan: technical context, constitution gates, architecture, data model, and key decisions.
OpenSpec's optional context, goals / non-goals, decisions, and risks for a change.
Let the AI Architect write it for you
MySpec interviews you, then drafts every spec file with collect → generate → review gates. Free during Open Beta.