Appendix A. How the Book Relates to Spec Kit and Kiro

This book uses an author's dialect of SDD for Qwen Code:

mission.md
tech-stack.md
roadmap.md
requirements.md
plan.md
validation.md

This is not the only possible format. Spec Kit and Kiro solve a similar problem, but name artifacts differently and divide stages in another way.

Main Difference

In the book, validation.md is extracted into a separate file. This is done intentionally: the agent and the human need an explicit set of facts that decides whether a branch can be merged.

In other systems, this idea may be distributed across tasks, checklists, plan analysis, or acceptance criteria.

Mapping Table

How to Transfer the Process

If a team uses Spec Kit, you don't have to impose the file names from this book on them. Transfer the meaning:

• the project constitution must be explicit;
• ambiguities must be clarified before planning;
• the plan must separate architectural decisions from the task list;
• verification facts must be visible before implementation;
• implementation must be compared against artifacts, not chat memory.

If a team uses Kiro, transfer three layers:

• steering files for permanent rules;
• specs for specific features;
• tasks and tests as a verifiable path to implementation.

Why the Book Has Its Own Format

The book's format is intentionally simpler than industrial command suites.

Reasons:

• files are easy to read without a special CLI utility;
• Qwen Code can work with them directly;
• validation.md makes verification a separate thinking stage;
• the structure fits a small project and transfer to another agent;
• the reader sees the process, not just a command like /speckit.implement.

There is a drawback too: in a large team, you will need to add conventions about merge requests, roadmap owners, specification reviews, and task templates. These topics are covered in part 16.

How to Choose a Format

Use the book's format if:

• you are learning SDD;
• the project is small;
• the team wants to see all decisions in ordinary Markdown files;
• you need a process without dependency on a specific platform.

Use Spec Kit if:

• the team wants ready-made commands and templates;
• a separate step for clarifying ambiguities is needed;
• extensions, presets, and repeatable workflows are important;
• there are multiple projects and a unified standard is required.

Use Kiro if:

• the team already works in Kiro;
• built-in specs, steering files, and agent hooks are needed;
• tight integration with the IDE process is important.

The format should not become a religion. The main thing is that intent, plan, verification, and decisions live in reviewable artifacts.