mcpField
S
sdd-spec

sdd-spec

github.com/fearovex-labsDevelopment55 installs
Repository

About sdd-spec

sdd-spec is a specification-writing skill for defining observable requirements as delta specs. It supports orchestrators that manage software changes, distinguishing new specifications from additions, modifications, and removals to existing ones.

Key features

  1. 01Observable functional requirements
  2. 02Given/When/Then scenarios
  3. 03Delta specs for existing systems
  4. 04Disk-first spec persistence
  5. 05Project-local skill resolution

Use cases

  1. 01Writing a complete spec for a new change
  2. 02Recording added or modified requirements
  3. 03Preparing specifications for design and task planning

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/fearovex-labs/agent-config --skill sdd-spec

After installing, type/sdd-specin Claude Code to confirm it loaded.

Details

From the project README

sdd-spec

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

Triggers: /sdd-spec <change-name>, write specs, specifications, functional requirements, sdd spec

Purpose

Specs define WHAT the system must do from the perspective of observable behavior. They do not say how to implement it. They are the source of truth for verification.

Key concept — Delta Specs: Specs are deltas (changes) on top of what already exists, not full replacements.

  • If there is no existing spec: I write a complete spec
  • If a spec already exists: I write ADDED/MODIFIED/REMOVED sections

Skill resolution

When the orchestrator launches this sub-agent, it resolves the skill path using:

1. .claude/skills/sdd-spec/SKILL.md     (project-local — highest priority)
2. ~/.claude/skills/sdd-spec/SKILL.md   (global catalog — fallback)

Project-local skills override the global catalog. See docs/SKILL-RESOLUTION.md for the full algorithm.

Claude execution wiring

These notes bind the tool-neutral logic above to the Claude Code harness. They are the EXECUTION layer that does not port to other tools.

  • Step 0a/0c preload — follow skills/_shared/sdd-phase-common.md Section F (Project Context Load) and Section G (Spec Context Preload). Non-blocking.
  • Step 0b domain preload — list .md files in ai-context/features/ and Read each matching file. Read errors are treated as a miss (skip silently).
  • Proposal read — use the harness Read("docs/sdd/{change-name}/proposal.md") tool. If the disk file is absent (legacy change), fall back to mem_search(query: "sdd/{change-name}/proposal") → mem_get_observation(id). If neither exists and Engram is not reachable, the orchestrator passes proposal content inline.
  • Spec persistence — write the disk artifact first with Write("docs/sdd/{change-name}/spec.md", …), then mem_save a pointer + summary with topic_key: sdd/{change-name}/spec, type: architecture, project: {project}, content = "path: docs/sdd/{change-name}/spec.md\n\n{1-3 sentence summary}". If Engram MCP is not reachable, still write the disk artifact (source of truth) and skip the engram pointer only.
  • Orchestrator output — return the neutral Output Contract as the JSON block the orchestrator expects; the manual next step is /sdd-design <change-name> then /sdd-tasks <change-name>. List the loaded ai-context/features/*.md files in artifacts (read, not written) when domain context was preloaded.

Comments

Markdown supported