sdd-spec

Writes SDD delta specifications with RFC 2119 requirements and Given/When/Then scenarios.

Updated May 24, 2026
One-click install
npx skills add https://github.com/etrigan16/v0-cipher-ar --skill sdd-spec-etrigan16
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sdd-spec
Source: https://github.com/etrigan16/v0-cipher-ar/tree/main/.opencode/skills/sdd-spec
Command: npx skills add https://github.com/etrigan16/v0-cipher-ar --skill sdd-spec-etrigan16

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It turns a change proposal into structured, testable specifications, eliminating ambiguity about what behavior is being added, modified, removed, or renamed in a system. ## Core Features & Use Cases - Delta Spec Generation: Produces ADDED, MODIFIED, REMOVED, and RENAMED requirement sections based on the proposal's Capabilities mapping. - Standardized Format: Enforces RFC 2119 keywords (MUST, SHALL, SHOULD, MAY) and Given/When/Then scenarios so every requirement is testable. - Multi-Mode Persistence: Supports engram, openspec, hybrid, and none artifact store modes for reading and saving specs. - Use Case: After an orchestrator approves a change proposal, this sub-agent reads the proposal, inspects existing domain specs, and writes delta specs under openspec/changes/{change-name}/specs/ ready for the design phase. ## Quick Start Ask the orchestrator to launch the sdd-spec sub-agent for your approved change proposal so it writes the delta specifications for each affected domain.

Frequently Asked Questions about sdd-spec

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

FAQPage Schema
How do I write delta specs for a spec-driven development change?▼

Read the proposal's Capabilities section to identify affected domains, then write ADDED, MODIFIED, REMOVED, or RENAMED requirement sections per domain. Each requirement uses RFC 2119 keywords and at least one Given/When/Then scenario.

What is the difference between a delta spec and a full spec?▼

A delta spec describes changes (ADDED/MODIFIED/REMOVED/RENAMED) against an existing domain spec, while a full spec is written when no existing spec exists for a new capability. The proposal's Capabilities section determines which type to write.

Why must MODIFIED requirements copy the entire existing requirement block?▼

The archive step replaces the requirement in main specs with the MODIFIED block, so a partial block loses scenarios that were not copied. Copy the full requirement with all scenarios, edit it, and add a Previously note summarizing the change.

When should I use ADDED instead of MODIFIED in a delta spec?▼

Use ADDED when introducing new behavior that does not change any existing requirement. Use MODIFIED only when altering the text or scenarios of a requirement that already exists in the domain spec.

What artifact store modes does the spec workflow support?▼

Four modes are supported: engram persists a single concatenated artifact, openspec writes domain files to the filesystem, hybrid does both, and none returns the result without creating or modifying project files.