sdd-spec

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

Updated Jun 5, 2026
One-click install
npx skills add https://github.com/zMynxx/bifrost-with-opencode --skill sdd-spec-zmynxx
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sdd-spec
Source: https://github.com/zMynxx/bifrost-with-opencode/tree/main/.opencode/skills/sdd-spec
Command: npx skills add https://github.com/zMynxx/bifrost-with-opencode --skill sdd-spec-zmynxx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It removes ambiguity from spec-driven development by turning a change proposal into structured delta specifications that precisely describe what behavior is added, modified, removed, or renamed. ## Core Features & Use Cases - Delta Spec Generation: Produces ADDED, MODIFIED, REMOVED, and RENAMED requirement sections based on the proposal's Capabilities mapping. - Testable Scenarios: Every requirement includes Given/When/Then scenarios covering happy paths and edge cases, ready for automated test derivation. - Multi-Mode Persistence: Supports engram, openspec, hybrid, and none artifact store modes for flexible spec storage. - 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 to generate the delta specifications.

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 in an SDD workflow?▼

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

What is the difference between ADDED and MODIFIED requirements in delta specs?▼

Use ADDED when introducing new behavior without changing existing requirements. Use MODIFIED when altering an existing requirement, and always copy the full original requirement block with all scenarios before editing to avoid losing content at archive time.

When should I write a full spec instead of a delta spec?▼

Write a full spec when the proposal lists a capability under New Capabilities with no existing spec for that domain. Full specs include a Purpose section and a Requirements section rather than delta headers.

Does this skill support different spec storage backends?▼

Yes, it supports four artifact store modes: engram (single concatenated artifact), openspec (filesystem convention), hybrid (both), and none (return only, no file writes). The orchestrator passes the mode when launching the sub-agent.

Why must MODIFIED requirements copy the entire original block?▼

The archive step replaces the requirement in main specs with the MODIFIED block. A partial block would permanently lose scenarios that were not copied, so the full requirement plus all scenarios must be pasted and then edited.