sdd-spec

Generate delta or full domain specs from change proposals.

Updated Jun 22, 2024
One-click install
npx skills add https://github.com/KilloconQ/dotfiles --skill sdd-spec-killoconq
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sdd-spec
Source: https://github.com/KilloconQ/dotfiles/tree/main/opencode/.config/opencode/skills/sdd-spec
Command: npx skills add https://github.com/KilloconQ/dotfiles --skill sdd-spec-killoconq

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

You are a sub-agent responsible for writing SPECIFICATIONS. You take the proposal and produce delta specs — structured requirements and scenarios that describe what's being ADDED, MODIFIED, or REMOVED from the system's behavior.

Core Features & Use Cases

  • Identify Affected Domains from the proposal's "Affected Areas" and group changes by domain.
  • Read existing specs (if present) to understand current behavior.
  • Write delta specs (ADDED/MODIFIED/REMOVED) and place them under openspec/changes/{change-name}/specs/{domain}/spec.md, or create full domain specs if no prior specs exist.

Quick Start

Provide the change proposal and artifact mode to generate delta specs for all affected domains.

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 in software requirements?

A delta specification describes structured requirements and scenarios for what is being ADDED, MODIFIED, or REMOVED from existing system behavior, organized under openspec/changes/{change-name}/specs/{domain}/.

How do I generate delta specs from a change proposal?

To generate delta specs, provide the change proposal and artifact mode. The system identifies affected domains, reads existing specs, and outputs structured requirements with RFC 2119 terminology under the designated openspec directory structure.

When do I need to create a full domain spec instead of a delta spec?

You create a full domain spec instead of a delta spec when no prior specifications exist for that domain, establishing the complete baseline behavior rather than documenting incremental changes.

Does this specification process enforce standard requirements terminology?

Yes, the specification process enforces RFC 2119 terminology for all generated requirements and scenarios, ensuring standardized language for requirement levels across affected domains.

How are changes grouped when writing specifications for multiple affected areas?

Changes are grouped by domain, identified from the proposal's Affected Areas. The process reads existing specs to understand current behavior and writes domain-specific delta specs under openspec/changes/{change-name}/specs/{domain}/.

What is the best way to document system behavior changes across different domains?

The best way is applying the delta specification process across all affected domains, using ADDED, MODIFIED, and REMOVED classifications with RFC 2119 terminology, outputting under the openspec changes directory structure.