sdd-spec

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

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

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, or full specs for new domains. - Standardized Requirement 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, reading existing specs before writing deltas. - Use Case: After an orchestrator approves a change proposal for a new team-archiving feature, this sub-agent reads the proposal, writes a delta spec with scenarios for the archive guard, and persists it for the design phase. ## Quick Start Delegate the approved change proposal to the sdd-spec sub-agent so it writes the delta specifications for the change.

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 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 original requirement block with all scenarios before editing, since the archive step replaces it wholesale.

When should a full spec be written 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 rather than delta headers.

Why do MODIFIED requirements lose scenarios at archive time?▼

The archive step replaces the requirement in the main spec with the MODIFIED block from the delta. If the block only contains the changed scenario, all uncopied scenarios are permanently lost, so the full requirement must be copied first.

Can this skill be invoked directly by the orchestrator?▼

No. The skill is marked delegate-only and user-invocable false; the orchestrator must delegate execution to the dedicated sdd-spec sub-agent rather than running the instructions inline.