sdd-spec

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

Updated Apr 10, 2026
One-click install
npx skills add https://github.com/Balthael/ciberbal-ai --skill sdd-spec-balthael
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sdd-spec
Source: https://github.com/Balthael/ciberbal-ai/tree/main/internal/assets/skills/sdd-spec
Command: npx skills add https://github.com/Balthael/ciberbal-ai --skill sdd-spec-balthael

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, or removed in a spec-driven development workflow. ## Core Features & Use Cases - Delta Spec Authoring: Writes ADDED, MODIFIED, and REMOVED requirement sections that cleanly merge into existing domain specs at archive time. - RFC 2119 + Gherkin Formatting: Enforces MUST/SHALL/SHOULD/MAY requirement language and Given/When/Then scenarios so every requirement is testable. - Multi-Mode Persistence: Supports engram, openspec, hybrid, and none artifact store modes, reading proposals and persisting specs accordingly. - Use Case: After an orchestrator produces a proposal for a new authentication capability, this Skill reads the proposal's Capabilities section, reads the existing auth spec, and writes a delta spec with full MODIFIED requirement blocks and edge-case scenarios. ## Quick Start Ask the orchestrator to launch the spec-writing phase for a named change so it reads the proposal and produces delta specs 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, or REMOVED 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.

Why do partial MODIFIED requirement blocks lose scenarios at archive time?

The archive step replaces the requirement in the main spec with the MODIFIED block exactly as written. If the block only contains the changed scenario, all uncopied scenarios are permanently dropped from the main spec.

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

Write a full spec when the proposal lists a domain under New Capabilities with no existing spec file. Full specs include a Purpose section and a Requirements section rather than ADDED/MODIFIED/REMOVED deltas.

What artifact store modes does the spec-writing phase 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 any project files.