sdd-spec

Write delta specifications with RFC 2119 keywords and Given/When/Then scenarios.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Delta specifications capture WHAT must change from an observable behavior perspective, enabling clear alignment between proposals and verification criteria while separating specification from implementation.

Core Features & Use Cases

  • Writes delta specifications that describe the required changes and the associated Given/When/Then scenarios.
  • Supports ADDED, MODIFIED, and REMOVED sections when a spec already exists, and can produce a delta from a base specification.
  • Reads prior artifacts (openspec/changes/<change-name>/proposal.md, openspec/specs/<domain>/spec.md, and ai-context/architecture.md) to inform the new spec with domain context.

Quick Start

Create a delta spec for your change by examining the current proposal and the domain spec, then emit the per-domain spec under openspec/changes.

Frequently Asked Questions about sdd-spec

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

FAQPage Schema
What is a delta specification and when do I need to write one?

A delta specification describes WHAT must change from an observable behavior perspective. You need delta specs when proposing changes to an existing system, ensuring alignment between proposals and verification criteria while separating specification from implementation.

How do I define acceptance criteria and BDD scenarios for edge cases and errors?

Define acceptance criteria by writing Given/When/Then scenarios covering happy paths, edge cases, errors, and security. Delta specs formalize these behavioral scenarios using RFC 2119 keywords to ensure precise requirement language.

How do I document ADDED, MODIFIED, and REMOVED sections for an existing spec?

Document changes by reading the current domain spec and prior proposal artifacts, then emit per-domain delta specs. The output includes ADDED, MODIFIED, and REMOVED sections when a base specification already exists, or a full spec if no artifacts are present.

Can I generate a delta spec from an existing base specification and proposal artifacts?

Yes, you can generate delta specs by reading prior artifacts like proposal.md, domain spec.md, and architecture.md. The process examines these inputs to inform the new spec with domain context and outputs the per-domain delta specification.

Does this approach to specification require RFC 2119 keyword usage?

Yes, delta specifications enforce RFC 2119 keyword usage to formalize requirement language. This ensures precise definition of scenarios for happy paths, edge cases, errors, and security within the observable behavior changes.

What's the best way to formalize requirements for proposed changes without detailing implementation?

The best way is writing delta specifications that capture WHAT must change from an observable behavior perspective. This separates specification from implementation, enabling clear alignment between proposals and verification criteria across domains.