What is the difference between sdd-init and sdd-test-cases?

sdd-init creates the high-level specification and TDD starting point, while sdd-test-cases is responsible for the exhaustive enumeration of edge cases and boundary conditions.

What is sdd-init used for?

It is used to create a draft specification document (Spec) for a specific feature slice, acting as a formal contract before starting the implementation or testing phases.

Where are the spec files stored?

By default, spec files are created in the docs/specs/ directory using the format YYYYMMDD-{name}.md.

What happens if a requirement is too ambiguous?

The skill will identify the ambiguity as a 'Blocker' or 'Open Question' in the spec, alerting the user that these must be resolved before proceeding to TDD.

Does this skill generate implementation code?

No, sdd-init is strictly for documentation and requirement definition. It explicitly avoids implementation and test code to focus on architectural clarity.

SDD Spec Initializer

Name: SDD Spec Initializer
Author: See2et

bySee2et

•

Developer Tools

Drafts standardized specification documents to establish a clear development contract before starting TDD.

About

SDD Spec Initializer (sdd-init) streamlines the transition from planning to implementation by automatically generating structured specification drafts based on agreed-upon feature slices. It transforms high-level goals into a documented contract that includes scope, functional requirements, and directory impact, ensuring developers have the clarity needed to begin Test-Driven Development. By focusing on documenting the 'what' rather than the 'how', it prevents implementation sprawl and ensures that critical blockers and open questions are addressed before a single line of code is written.

Key Features

Outlines expected directory structure changes without requiring full file system context.
Defines minimal TDD scenarios (one happy path, one failure case) to jumpstart the Red phase.
Generates standardized specification Markdown files using a timestamped naming convention.
1 GitHub stars
Documents functional and non-functional requirements with unique IDs for traceability.
Identifies blockers and open questions to prevent development on ambiguous requirements.

Use Cases

Documenting the scope and constraints of a specific code slice before writing unit tests.
Starting a new feature implementation following a Spec-Driven Development (SDD) workflow.
Standardizing technical documentation across a team to ensure consistent requirement clarity.

About

Key Features

Outlines expected directory structure changes without requiring full file system context.
Defines minimal TDD scenarios (one happy path, one failure case) to jumpstart the Red phase.
Generates standardized specification Markdown files using a timestamped naming convention.
1 GitHub stars
Documents functional and non-functional requirements with unique IDs for traceability.
Identifies blockers and open questions to prevent development on ambiguous requirements.

Use Cases

Documenting the scope and constraints of a specific code slice before writing unit tests.
Starting a new feature implementation following a Spec-Driven Development (SDD) workflow.
Standardizing technical documentation across a team to ensure consistent requirement clarity.