sdd-spec

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

Updated Jul 10, 2026
One-click install
npx skills add https://github.com/AD-Paladins/beaconator-web --skill sdd-spec-ad-paladins
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sdd-spec
Source: https://github.com/AD-Paladins/beaconator-web/tree/main/.config/opencode/skills/sdd-spec
Command: npx skills add https://github.com/AD-Paladins/beaconator-web --skill sdd-spec-ad-paladins

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Translating a change proposal into precise, testable specifications is error-prone: requirements get lost, modified behavior is described partially, and scenarios lack a consistent format. This Skill produces structured delta specs (ADDED, MODIFIED, REMOVED, RENAMED requirements) that archive cleanly into a project's spec system. ## Core Features & Use Cases - Delta Spec Generation: Writes ADDED, MODIFIED, REMOVED, and RENAMED requirement sections based on the proposal's Capabilities mapping, with full-block MODIFIED requirements to prevent content loss at archive time. - Standardized Scenario Format: Enforces Given/When/Then scenarios and RFC 2119 keywords (MUST, SHALL, SHOULD, MAY) so every requirement is testable. - Multi-Mode Persistence: Supports engram, openspec, hybrid, and none artifact store modes, reading existing specs before writing deltas. - Use Case: After an orchestrator approves a change proposal for a new API rate-limiting capability, this Skill reads the proposal, checks existing specs, and produces a delta spec with requirements and edge-case scenarios ready for the design phase. ## Quick Start Ask the orchestrator to run the sdd-spec phase 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 for a change proposal?▼

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

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

Use ADDED when introducing new behavior without changing existing requirements. Use MODIFIED when altering an existing requirement, and copy the entire requirement block with all scenarios before editing, since the archive step replaces the original completely.

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

Write a full spec when the domain is completely new and no existing spec file exists for it. Full specs include a Purpose section and a Requirements section, while deltas only describe changes to existing behavior.

Why do MODIFIED requirements lose scenarios at archive time?▼

The archive step replaces the requirement in main specs with the MODIFIED block verbatim. If the block only contains the changed scenario, all uncopied scenarios are permanently lost, so always copy the full requirement first.

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 any project files.