sdd-spec

Generate ADDED, MODIFIED, and REMOVED requirement sections with Given/When/Then scenarios.

Updated Apr 14, 2026
One-click install
npx skills add https://github.com/dallay/opencode-docker --skill sdd-spec-dallay
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sdd-spec
Source: https://github.com/dallay/opencode-docker/tree/main/config/skills/sdd/sdd-spec
Command: npx skills add https://github.com/dallay/opencode-docker --skill sdd-spec-dallay

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill automates the creation of clear, testable delta specifications so teams can describe exactly what is being added, modified, or removed when a change is proposed, reducing ambiguity between proposal and implementation.

Core Features & Use Cases

  • Delta spec generation: Read existing domain specs and produce ADDED, MODIFIED, and REMOVED requirement sections.
  • Testable scenarios: Write Given/When/Then scenarios for every requirement and include both happy paths and edge cases.
  • Standards compliance: Enforce RFC 2119 keyword usage and follows openspec conventions for persistence and structure.

Quick Start

Generate delta specifications for the change named my-feature by reading existing openspec specs and writing the delta spec files into openspec/changes/my-feature/specs/.

Frequently Asked Questions about sdd-spec

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate delta specifications for proposed system changes?

To generate delta specifications, the Skill reads existing openspec domain specs, groups proposed changes by domain, and outputs ADDED, MODIFIED, and REMOVED requirement sections with Given/When/Then scenarios to the openspec directory.

How do I write BDD scenarios for system change requirements?

BDD scenarios for system changes are written using Given/When/Then syntax, ensuring at least one testable scenario exists per requirement while covering both happy paths and edge cases for comprehensive validation.

What are delta specifications and when do I need them for openspec repositories?

Delta specifications define exactly what is ADDED, MODIFIED, or REMOVED during a system change. They are needed for openspec repositories to reduce ambiguity between proposal and implementation by enforcing RFC 2119 keyword standards.

Does this approach enforce RFC 2119 keyword usage in requirement sections?

Yes, standards compliance enforces RFC 2119 keyword usage within the ADDED, MODIFIED, and REMOVED requirement sections, ensuring precise language for requirement levels across all generated openspec artifacts.

Can I use this to group system changes by domain automatically?

Yes, the Skill reads existing domain specs and automatically groups proposed system changes by affected domain, structuring the output into distinct requirement sections for each domain area.

What is the best way to structure openspec change artifacts?

The best way to structure openspec change artifacts is to persist them as structured envelopes within openspec/changes/{change-name}/specs, adhering strictly to openspec conventions for directory and file organization.