mcpField
S
sdd-design

sdd-design

github.com/fearovex-labsDevelopment56 installs
Repository

About sdd-design

sdd-design is a software-development skill that turns specifications into a technical design covering architecture decisions, data flow, and planned file changes. It is for workflows that need an explicit implementation plan between requirements and code.

Key features

  1. 01Create designs from specifications
  2. 02Record architecture decisions and rationale
  3. 03Plan data flow and file changes
  4. 04Resolve project-local skills first

Use cases

  1. 01Choose an implementation approach for a change
  2. 02Document architecture decisions and data flow
  3. 03Prepare a design for subsequent task planning

Install

Copy the command and run it in a terminal.

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

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

Details

From the project README

sdd-design

Produces the technical design with architecture decisions, data flow, and a file change plan.

Triggers: /sdd-design <change-name>, technical design, change architecture, sdd design

Purpose

The design defines HOW to implement what the specs say the system MUST do. It is the bridge between requirements and code. It documents technical decisions and their justification.

Skill resolution

When the orchestrator launches this sub-agent, it resolves the skill path using, project-local → global, in order:

1. .claude/skills/sdd-design/SKILL.md     (project-local — highest priority)
2. ~/.claude/skills/sdd-design/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 0 preload — follow skills/_shared/sdd-phase-common.md Section F (Project Context Load) and Section G (Spec Context Preload). Non-blocking.
  • Artifact reads — use the harness Read("docs/sdd/{change-name}/<artifact>.md") tool for the proposal and spec. If a disk file is absent (legacy change), fall back to mem_search(query: "sdd/{change-name}/<artifact>") → mem_get_observation(id). If neither exists and Engram is not reachable, the content is passed inline from the orchestrator.
  • Skills Registry cross-reference — the neutral "the project's technology guidance" resolves to the global catalog under ~/.claude/skills/ plus any project-local .claude/skills/. Mark catalog skills not registered in the project as [optional — not registered in project; add via /skill-create <name>].
  • Design persistence — write the artifact via the harness Write("docs/sdd/{change-name}/design.md", <full design markdown>) FIRST, then mem_save a pointer + summary with topic_key: sdd/{change-name}/design, type: architecture, project: {project}, content = "path: docs/sdd/{change-name}/design.md\n\n{1-3 sentence summary}". If Engram MCP is not reachable, still write the disk artifact; skip the engram pointer only.
  • ADR generation (Step 4) — perform the copy/edit via harness file tools (Read/Write/Edit); non-blocking, any failure is a warning only.
  • Orchestrator output — return the neutral Output Contract as the JSON block the orchestrator expects; the artifacts list uses the engram pointer engram:sdd/{change-name}/design alongside the disk path, and the manual next step is /sdd-tasks <change-name>.

Comments

Markdown supported