Skip to content
/
Tier A A8 Cross-runtime harness

SpecD

specd-sdd · specd-sdd/SpecD · ★ 9 · last commit 2026-05-25

Pre-assembles deterministic context packages for agents at each lifecycle step, combined with a multi-language code graph and customizable schema that defines artifact workflow per project.

Best whenContext should be compiled and delivered to agents, not discovered by them — deterministic context resolution prevents agents from missing relevant specs.
vs seeds
kiroin its closed-loop lifecycle (design → implement → verify) and schema-defined artifact workflow, but SpecD is open sourc…
Primitive shape 2 total
Commands 1 MCP tools 1
00

Summary

SpecD — Summary

SpecD is the most architecturally sophisticated framework in this batch: a TypeScript monorepo (@specd/*) shipping a full CLI (specd), an MCP server, a multi-language code graph engine, and agent plugins for Claude Code, GitHub Copilot, Codex CLI, and OpenCode. Its core architectural thesis is "context compiled, not discovered" — SpecD pre-computes which specs are relevant to a change and delivers a single ordered instruction block to the agent, eliminating the need for agents to search for context. A customizable schema.yaml defines artifact workflow, section structure, and dependency order per project. The change lifecycle (drafting → designing → ready → implementing ⇄ verifying → done → archivable) has mandatory verification and optional human approval checkpoints. Lifecycle hooks (pre/post, shell commands or AI instructions) attach to state transitions. The code graph supports TypeScript, Go, Python, and PHP for impact analysis. Compared to seeds, SpecD is the closest thing to kiro in its closed-loop spec-to-verification lifecycle and lifecycle hook model, but SpecD is open source and multi-agent-tool; it goes beyond all seeds in the context compilation + code graph integration.

01

Overview

SpecD — Overview

Origin

SpecD is developed by the specd-sdd organization (1 contributor). Published on npm (@specd/specd). Version 0.2.0. Active development as of May 2026.

Philosophy

SpecD positions itself as a "ground-up redesign" of spec-driven workflows for professional teams:

"Context compiled, not discovered. At every lifecycle step, SpecD computes which specs are relevant to the current change and delivers their content as a structured, ready-to-consume block. The agent does not decide what to read; SpecD resolves it."

"Deterministic where correctness matters. Spec merging, validation, status resolution, and delta application are computed algorithmically — not delegated to the LLM."

"Customizable schema model. A default schema is included, while projects can define their own artifact workflow, section structure, and dependency order in schema.yaml. SpecD does not hardcode any particular convention."

Change Lifecycle

drafting → designing → ready → [optional approval] → implementing ⇄ verifying → done → [optional approval] → archivable

Verification is mandatory — after implementation, the agent enters verifying where a dedicated skill checks implementation against specs and can return the change for revision.

Optional approval checkpoints at ready → implementing and done → archivable provide human governance.

Key Differentiators vs. Earlier SDD Tools

  1. Context compiled: SpecD resolves which specs to inject; agents don't guess
  2. Code graph built in: TypeScript, Go, Python, PHP indexing with impact analysis
  3. Deterministic operations: Merging, validation, status resolution = algorithmic
  4. Customizable schema: Projects define their own artifact workflow
  5. Lifecycle hooks: Shell commands + AI instructions on state transitions
  6. Multi-workspace: Spans multiple repos (coordinator repo pattern)

Status

Active development (April 2026 status page in README). Core packages published to npm; MCP server in progress.

02

Architecture

SpecD — Architecture

Distribution

  • Type: npm monorepo (TypeScript)
  • Install: npm install -g @specd/specd
  • Language: TypeScript/Node.js
  • Version analyzed: 0.2.0

Monorepo Package Structure

packages/
├── cli/                    # @specd/cli — complete command surface
│   └── src/commands/
│       ├── archive/
│       ├── change/
│       ├── config/
│       ├── discarded/
│       ├── drafts/
│       ├── graph/
│       ├── plugins/
│       ├── project/
│       ├── schema/
│       └── spec/
├── core/                   # @specd/core — business logic
├── code-graph/             # @specd/code-graph — codebase indexing
├── mcp/                    # @specd/mcp — MCP server (in progress)
├── plugin-agent-claude/    # @specd/plugin-agent-claude
├── plugin-agent-codex/     # @specd/plugin-agent-codex
├── plugin-agent-copilot/   # @specd/plugin-agent-copilot
├── plugin-agent-opencode/  # @specd/plugin-agent-opencode
├── plugin-agent-standard/  # @specd/plugin-agent-standard
├── plugin-manager/         # @specd/plugin-manager
├── schema-std/             # @specd/schema-std — default schema.yaml
├── skills/                 # @specd/skills — skill registry
└── specd/                  # @specd/specd — metapackage
apps/
└── public-web/             # Documentation site (Docusaurus, in progress)

CLI Commands

specd project init          # Initialize project (wizard)
specd change ...            # Change lifecycle management
specd spec ...              # Spec CRUD
specd schema ...            # Schema management
specd graph ...             # Code graph queries
specd plugins ...           # Plugin management
specd skills ...            # Skill registry
specd drafts ...            # Draft management
specd discarded ...         # Discarded changes
specd archive ...           # Archive management
specd config ...            # Configuration
specd context              # Compile context for current change

Required Runtime

  • Node.js (npm install)
  • Git

Target AI Tools

Claude Code, GitHub Copilot, Codex CLI, OpenCode (agent plugins). Plus standard MCP clients when MCP server completes.

Configuration Files

  • specd.yaml — project configuration, schema overrides
  • schema.yaml — artifact workflow definition (customizable)
  • .specd/ — project state directory

Context Compilation Process

  1. Project-level include patterns
  2. Project-level exclude patterns
  3. Workspace-level include/exclude patterns
  4. dependsOn traversal (transitive)
  5. Assembly into single ordered instruction block
03

Components

SpecD — Components

CLI Commands (10 command groups)

Command Purpose
specd project Project initialization, multi-workspace setup
specd change Change lifecycle (create, advance, approve, verify)
specd spec Spec CRUD (create, read, update, delete)
specd schema Schema management (validate, inspect, customize)
specd graph Code graph queries (impact analysis, hotspots, staleness)
specd plugins Plugin install/update/uninstall
specd skills Skill registry (bundle resolution)
specd drafts Draft change management
specd discarded Discarded change management
specd archive Archived change management
specd config Configuration management
specd context Compile context block for current change

Agent Plugins (5)

Plugin Target
@specd/plugin-agent-claude Claude Code slash command integration
@specd/plugin-agent-codex Codex CLI integration
@specd/plugin-agent-copilot GitHub Copilot integration
@specd/plugin-agent-opencode OpenCode integration
@specd/plugin-agent-standard Generic agent integration

Skills

SpecD ships a skill registry (@specd/skills) that resolves and delivers skill bundles per agent runtime.

Hooks (Schema-Defined)

Hooks are defined in schema.yaml under the workflow section. Two types:

  • run: — shell commands (non-zero exit blocks pre hooks)
  • instruct: — AI instructions injected into agent context

Hooks fire on state transitions (pre/post per lifecycle step):

  • pre hooks: run before entering a step; failure blocks transition
  • post hooks: run after entering a step; failure does not rollback

MCP Server

@specd/mcp — in progress as of April 2026.

Code Graph Engine

@specd/code-graph — multi-language codebase indexing for:

  • TypeScript, Go, Python, PHP
  • Impact analysis (upstream/downstream reach)
  • Hotspot detection
  • Staleness detection (specs out of sync with code)

Templates

Schema-defined. @specd/schema-std ships default schema.yaml and template files. Projects can override with their own schemas.

State Files

  • specd.yaml — project config
  • schema.yaml — artifact workflow definition
  • .specd/ — project state
  • .specd/changes/ — change lifecycle state
  • .specd/specs/ — spec files
05

Prompts

SpecD — Prompts

Prompt 1: SpecD Skill — Entry Point (/specd)

Source: SpecD README (skill invocation pattern)

Technique: State-machine routing prompt — the /specd skill inspects project state and routes to the next workflow step automatically.

From README:

# Coding agent
/specd

When invoked, the SpecD skill:

  1. Reads .specd/ project state
  2. Determines current change lifecycle step
  3. Routes to appropriate action (e.g., "creating a change", "continuing a change")

This is a stateful router, not a command-per-phase invocation.

Prompt 2: Context Compilation Block

Source: SpecD README (Context compilation section)

Technique: Pre-assembled context injection — SpecD computes a structured instruction block before the agent starts work.

From README:

"The output is a single, ordered instruction block combining project context, schema instructions for the active artifact, spec content, and lifecycle hooks — ready to inject into the agent's context window. The agent doesn't search, doesn't guess, and doesn't miss a spec that wasn't mentioned by name."

The compiled context includes:

[Project-level specs matching include patterns]
[Workspace-level specs for active workspaces]
[Transitively resolved dependsOn specs]
[Schema instructions for current artifact type]
[Lifecycle hooks for current step]

Notable technique: Context is deterministically computed, not LLM-resolved. The agent receives a pre-structured package rather than a list of files to read.

Prompt 3: Lifecycle Hook Types

Source: SpecD README (Hooks section)

Technique: Two-tier hook injection — hooks can be shell commands (deterministic) or AI instructions (LLM-evaluated).

# In schema.yaml (simplified)
workflow:
  steps:
    implementing:
      pre:
        - run: "npm test"          # Shell: blocks if non-zero exit
        - instruct: "Before implementing, verify all acceptance criteria are testable."
      post:
        - run: "npm run lint"      # Shell: non-blocking post

Notable technique: The instruct hook type injects natural language guidance into the agent's context at a specific lifecycle transition point — guidance that is relevant only at that moment, not throughout the entire session.

09

Uniqueness

SpecD — Uniqueness & Positioning

differs_from_seeds

SpecD is closest to kiro in its closed-loop lifecycle (spec → design → implement → verify), schema-defined artifact workflow, and lifecycle hooks that fire on state transitions. However, SpecD is open source, CLI-native, and multi-agent-tool vs. kiro's closed IDE. SpecD's "context compiled, not discovered" principle — where a CLI command assembles the exact spec context package for each lifecycle step — is unique across all 11 seeds: no seed pre-assembles context deterministically. The multi-language code graph (@specd/code-graph) for impact analysis and staleness detection goes beyond any seed's state management. The customizable schema.yaml that lets projects define their own artifact workflow is also unique — all seeds hardcode their artifact types. The mandatory verifying step that can return implementation to revision is most similar to superpowers' verification-before-completion, but implemented as a lifecycle state rather than a skill.

Positioning

SpecD targets professional teams needing spec governance across multi-repo microservice architectures. The coordinator-repo pattern and workspace model make it the only framework in this batch that explicitly addresses the monorepo/multi-repo scenario. At 9 stars and 1 contributor, it is early-stage but architecturally the most complete framework analyzed.

Distinctive Opinions

  1. "Context compiled, not discovered" — agents should receive pre-assembled spec packages, not lists of files to read
  2. Deterministic where it matters — merging, validation, status resolution are algorithmic (LLM is fallible for these)
  3. Customizable schema — no framework should hardcode artifact types; projects should define their own workflow

Observable Failure Modes

  1. Early stage: v0.2.0, 1 contributor, MCP server still in progress
  2. High complexity: 13+ packages in the monorepo — significant install and maintenance burden
  3. Low adoption signals: 9 stars; the architecture is impressive but unvalidated at scale
  4. Schema learning curve: Custom schema.yaml is powerful but requires understanding SpecD's domain model

Explicit Antipatterns

Not documented explicitly.

Cross-References

The artifact structure (spec → design → implement) echoes kiro. The context compilation approach is novel. No explicit seed citations in the README.

04

Workflow

SpecD — Workflow

Change Lifecycle

drafting → designing → ready → [optional approval] → implementing ⇄ verifying → done → [optional approval] → archivable

Phase-to-Artifact Map

Phase Artifact
drafting Change draft (proposal artifact per schema)
designing Design artifact (architecture, design decisions per schema)
ready All pre-implementation artifacts complete
implementing Code + implementation
verifying Verification report (spec conformance check)
done Verified implementation
archivable Archived change record

Approval Gates

Gate Type When
Design approval (optional) file-review Before ready → implementing
Implementation approval (optional) file-review Before done → archivable
Mandatory verification automated After implementing (spec conformance check)
Pre hooks (schema-defined) automated Any state transition

Spec Format

Schema-defined. Default: Markdown. The schema.yaml defines section structure, artifact types, and dependency order. Projects can define their own formats.

Schema.yaml

The schema defines:

  • Artifact workflow: What artifacts exist, their dependency order
  • Section structure: What sections each artifact has
  • Validations: Per-artifact validation rules
  • Instructions: AI guidance for each artifact type
  • Hooks: Shell commands + AI instructions on state transitions

Context Compilation

At every lifecycle step, specd context computes and delivers:

  1. Project-level specs (always relevant)
  2. Workspace-level specs (for active workspaces)
  3. dependsOn traversal (transitive dependencies)
  4. Schema instructions for active artifact
  5. Lifecycle hooks for current step

Output: single ordered instruction block injected into agent context.

Multi-Workspace Support

A coordinator repo can govern specs across multiple service repos:

  • Each workspace declares its own specs/ path and code_root
  • A single specd.yaml can reference multiple workspace paths or remote repos
  • Enables microservice architecture governance from one central repo

Execution Mode

Interactive loop / event-driven. User or agent advances lifecycle via CLI or agent plugin commands.

06

Memory Context

SpecD — Memory & Context

State Storage

File-based with schema-defined structure:

Path Purpose
specd.yaml Project configuration, schema overrides
schema.yaml Artifact workflow definition
.specd/changes/ Change lifecycle state
.specd/specs/ Spec files
.specd/ root Project state index

Memory Type

File-based (YAML + Markdown).

Persistence Scope

Project-level (per workspace). Multi-workspace support enables cross-repo persistence.

Context Compilation

SpecD's primary memory mechanism is the context compilation step (specd context):

  1. Resolve relevant specs via include/exclude patterns
  2. Follow dependsOn dependencies transitively
  3. Assemble into single ordered instruction block

This means agents never hold spec content in their context directly — they receive it as a compiled package at each lifecycle step, then it can be discarded.

Cross-Session Handoff

Strong. Lifecycle state persists in .specd/ and specd.yaml. The /specd skill reads project state to determine the current position in the lifecycle.

Code Graph

@specd/code-graph maintains a queryable graph of:

  • Code symbols (TypeScript, Go, Python, PHP)
  • Spec-to-code relationships
  • Impact analysis (what code is affected by a spec change)
  • Hotspot detection (frequently changed specs/code)
  • Staleness detection (specs whose referenced code has changed)

The code graph is the most sophisticated state artifact in this batch — it enables bidirectional traceability between specs and implementation.

Compaction

Not explicitly handled. Context compilation ensures agents only receive relevant context for the current step, which naturally limits context size.

Code graph queries via specd graph CLI commands.

07

Orchestration

SpecD — Orchestration

Multi-Agent

Supported via agent plugins (Claude Code, Codex, Copilot, OpenCode). Multiple agents can work with the same SpecD project state.

Orchestration Pattern

Sequential lifecycle with verification loop. The implementing ⇄ verifying bidirectional arrow in the lifecycle allows the verification step to return the change to implementing if spec drift is detected.

Isolation Mechanism

Unknown (not documented in available README content for multi-agent parallel execution).

Multi-Model

No explicit multi-model routing. Different agent plugins target different AI tools, but no model-role mapping.

Execution Mode

Interactive loop / event-driven. Changes advance through lifecycle steps either by user command or agent plugin action.

Mandatory Verification

The verifying step is mandatory — the agent cannot move to done without passing verification. This is the most direct "built-in quality gate" in this batch.

Verification: dedicated skill checks implementation against relevant specs and can return {"decision": "block"} (analogous to cc-spec-driven's Stop hook).

Hook Enforcement

Schema-defined lifecycle hooks:

  • pre hooks (blocking): shell commands or AI instructions
  • post hooks (non-blocking): shell commands or AI instructions

Examples: run: "npm test" (blocks if tests fail), instruct: "..." (injects AI guidance).

Prompt Chaining

Yes. Specs feed the design artifact; design feeds the implementation; implementation goes through verification.

Git Automation

Unknown from available sources.

Crash Recovery

Yes — lifecycle state in .specd/ provides resumption. The /specd skill re-reads state to find current position.

Delta Application

SpecD uses "Deltas" — structured artifacts expressing semantic operations over spec documents using selectors. Deltas are applied deterministically by SpecD's core library, not by the LLM. This prevents merge conflicts from corrupting spec content.

08

Ui Cli Surface

SpecD — UI & CLI Surface

Dedicated CLI Binary

Exists: Yes
Name: specd
Package: @specd/cli (v0.2.0)
Is thin wrapper: No — full TypeScript CLI with its own runtime, state management, code graph engine, and context compilation
Install: npm install -g @specd/specd

CLI Command Groups

Group Purpose
specd project Project + workspace management
specd change Change lifecycle (advance, approve, verify)
specd spec Spec CRUD
specd schema Schema management
specd graph Code graph queries
specd plugins Plugin management
specd skills Skill registry
specd drafts Draft management
specd discarded Discarded change management
specd archive Archive management
specd config Configuration
specd context Compile context block

Local UI

Exists: In progress (documentation site at apps/public-web/ using Docusaurus). No local runtime dashboard confirmed.

IDE Integration

Agent plugins for Claude Code, GitHub Copilot, Codex CLI, OpenCode. Installs via specd plugins install.

Observability

  • specd graph — code graph queries for impact analysis, hotspots, staleness
  • Lifecycle state in .specd/ — queryable via CLI
  • Schema-defined audit trail via change lifecycle

Related frameworks

same archetype · same primary tool · same memory type

claude-mem (thedotmack) ★ 78k
A8 Cross-runtime harness

Background worker service captures every tool call as an observation, AI-compresses sessions, and auto-injects relevant past…

pi (badlogic/earendil) ★ 55k
A8 Cross-runtime harness

A minimal, hackable, multi-provider terminal coding agent that adapts to your workflows via npm-installable TypeScript Extensions…

Agent Skills (Addy Osmani) ★ 46k
A8 Cross-runtime harness

Encodes senior-engineer software development lifecycle as 23 auto-routed skills and 7 slash commands for any AI coding agent.

wshobson/agents Plugin Marketplace ★ 36k
A8 Cross-runtime harness

Single Markdown source for 83 domain-specialized plugins that auto-generates idiomatic artifacts for five AI coding harnesses.

TabbyML/Tabby ★ 34k
A8 Cross-runtime harness

Self-hosted AI coding assistant server (alternative to GitHub Copilot) with admin dashboard, RAG-based completions, and multi-IDE…

Compound Engineering ★ 17k
A8 Cross-runtime harness

Make each unit of engineering work compound into easier future work via brainstorm→plan→execute→review→learn cycles.