The Spec Kit Workflow

What Spec Kit is

GitHub Spec Kit is an open-source toolkit for Spec-Driven Development. Its specify CLI scaffolds a repository with templates, and a set of slash commands walk an AI coding agent through the method: establish a constitution, specify a feature, clarify it, plan it, break it into tasks, implement. Its strengths are a clear feature scope and a constitution that is versioned like code. What it does not do is interview you - the CLI provides templates; the thinking is yours.

MySpec's Spec Kit workflow keeps the templates and the layout and adds the interviewing, the specialist generators, and the independent reviewer on every file. The comparison of the two approaches is on Spec-Kit vs MySpec.

Interview → constitution → specify → plan → tasks

SpecKit generate-greenfield · speckit-greenfield-v1

1. Interview - one feature, not a roadmap. The Greenfield Product Interviewer focuses on a single feature: problem, user-facing surface, personas, the one to three key journeys (they become the P1/P2/P3 user stories), and the smallest valuable slice. If the project already has a constitution, the interviewer reads it first and never asks a question it already answers. It ends by deriving a short kebab-case name; the workflow prefixes the next free three-digit number to form <FEAT_DIR>.
2. Constitution → specs/memory/constitution.md. On the first feature: collect → generate → review. On later features the constitution already exists, so the stage skips collect and only edits it when an amendment is needed - bumping the SemVer footer and the Sync Impact Report.
3. Specify → spec.md: prioritised user stories with independent tests and Given / When / Then scenarios, edge cases, technology-neutral FR-###, key entities, measurable SC-###, assumptions.
4. Plan → plan.md: technical context, the Constitution Check (Simplicity, Anti-Abstraction, Integration-First gates), architecture and data-model diagrams, modules, a testing strategy mapped to the user stories, key decisions, and complexity tracking for any gate the design breaks.
5. Tasks → tasks.md: Setup → Foundational → one phase per user story → Polish, with T001 numbering, [P] parallel markers, [US1] story tags, and a file path on every task.

Folder layout and CLI compatibility

specs/
├── memory/
│   └── constitution.md          # one per project; later features read and only amend it
├── 001-photo-albums/            # <FEAT_DIR>: 3-digit prefix + kebab-case short name
│   ├── spec.md
│   ├── plan.md
│   └── tasks.md
└── 002-share-links/
    ├── spec.md
    ├── plan.md
    └── tasks.md

Spec Kit command      MySpec stage         File written
/speckit.constitution constitution         specs/memory/constitution.md
/speckit.specify      specify              specs/<FEAT_DIR>/spec.md
/speckit.clarify      (collect substages)  - folded into every stage's questions
/speckit.plan         plan                 specs/<FEAT_DIR>/plan.md  (research, data-model, contracts folded in)
/speckit.tasks        tasks                specs/<FEAT_DIR>/tasks.md
/speckit.implement    your coding agent    reads the bundle via MCP or .specs/

Where Spec Kit's /speckit.plan can spread planning across plan.md, research.md, data-model.md, and contracts/, MySpec writes one comprehensive plan.md - research becomes the Key Decisions table, the data model an erDiagram section, contracts the API / Protocol Design section - so the reviewer can check the plan as a whole.

Spec Kit workflow vs the MySpec bundle

Implementing the feature

Point your coding agent at the feature directory: through the MySpec MCP server it can read_spec_file the plan and tasks directly, or download them into .specs/001-photo-albums/. Spec Kit's /speckit.implement then works on the same files it always has. Later features start a new session in the same project; the interviewer picks up the existing constitution automatically.