/supergraph:sdd

SkillDatabases & data

Create a Software Design Document (SDD) defining component architecture, data contracts, API schemas, and platform compatibility before planning. Use in Tier 3 (Full Pipeline) or when modifying interfaces, hooks, databases, or multi-platform contracts.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the /supergraph:sdd skill

What this skill tells your AI

The instructions your AI receives, as published by datit309/supergraph in plugins/supergraph/skills/sdd/SKILL.md and read by ahel’s review.

Draft a machine-readable Software Design Document (SDD) with Mermaid architecture diagrams, strict data/interface contracts, and platform compatibility matrices before task decomposition in /supergraph:plan.

Announce: "📐 /supergraph:sdd — drafting Software Design Document..."

Quick Gate

  • Micro Tier (<20 lines, ≤2 files, no schema/API/hook changes) → skip directly to /supergraph:tdd.
  • Standard Tier (≤5 files, clear local change, no cross-boundary) → optional; draft mini-spec if touching API/data contracts.
  • Full Tier (>5 files, architectural change, API/schema modification, multi-platform runtime) → MANDATORY.

Steps

1. Load Context & Architecture

1a. Read Domain Vocabulary:

head -60 CONTEXT.md 2>/dev/null || echo "No CONTEXT.md"

Always reuse terms from CONTEXT.md for entities, roles, and components.

1b. Read PRD (if exists): Check latest PRD in docs/supergraph/plans/*prd*.md:

ls -t docs/supergraph/plans/*prd*.md 2>/dev/null | head -1

1c. Codebase Architecture Overview: Query codebase-memory-mcp (get_architecture with overview, layers, boundaries) or inspect hub nodes with Serena. Identify affected components and cross-module boundaries.


2. Draft Software Design Document (SDD)

Generate the document using the following structured template:

# SDD: [Feature / System Name]
Date: YYYY-MM-DD
Status: draft | approved

## 1. Context & Scope
- **Problem Statement:** [What technical gap or requirement does this address?]
- **Goals:** [Specific technical capabilities to enable]
- **Non-Goals:** [What this design explicitly does NOT cover]

## 2. Component & Flow Architecture

```mermaid
sequenceDiagram
    autonumber
    actor User/Agent
    participant Orchestrator
    participant SubsystemA
    participant SubsystemB
    User/Agent->>Orchestrator: Trigger action
    Orchestrator->>SubsystemA: Process contract payload
    SubsystemA-->>Orchestrator: Return typed response
    Orchestrator->>SubsystemB: Apply changes / sync
    SubsystemB-->>Orchestrator: Ack / Status

3. Interface & Data Contracts

3.1 Input / Output Schemas

[Define exact JSON schemas, TypeScript interfaces, Protobuf, or CLI stdin/stdout contracts]

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["status", "data"],
  "properties": {
    "status": { "type": "string", "enum": ["ok", "error"] },
    "data": { "type": "object" }
  }
}

3.2 Data Models & Persistence

  • Entity definitions, table schema migrations, or state files.
  • Invariants & validation rules.

4. Platform Compatibility Matrix

(Mandatory for multi-platform tools, hooks, and CLI integrations)

Feature / HookClaude CodeAntigravityOpenCodeCodex
Lifecycle EventSessionStartPreInvocation (turn 1)session.idleSessionStart
Output ProtocolTerminal stdoutinjectSteps (ephemeral)chat.messagehookSpecificOutput
FallbackSilent exit 0Fallback allowNo-opExit 0

5. Failure Modes & Fallback Matrix

Failure ScenarioTrigger ConditionSystem BehaviorFallback / Recovery
Timeout / HangTool/command > 30sAbort executionReturn error JSON, notify caller
Contract MismatchPayload missing fieldReject with validation errorLog diagnostic warning
Missing DependencyCLI/MCP not availableSoft degradeSkip feature non-blockingly

6. Architecture Decision Records (ADRs)

  • ADR-1: [Decision Title]
    • Context: [Why was this decision needed?]
    • Options Considered: [Option A vs Option B]
    • Decision: [Chosen approach]
    • Rationale & Trade-offs: [Why it won and what trade-offs were accepted]

---

### 3. Save SDD File

Save the design document to:
```bash
mkdir -p docs/supergraph/sdd
# Path: docs/supergraph/sdd/YYYY-MM-DD-sdd-<slug>.md

4. Present for Approval (MANDATORY GATE)

Present a summary of the SDD to the user in their language:

  • Key architectural flows
  • Critical interface contracts & schemas
  • Platform compatibility trade-offs

Ask: "Does this design meet your technical requirements? [yes / adjust / reject]"

Incorporate any feedback before proceeding.


5. Handoff to Planning

Once approved (Review: Approved):

  • Hand off to /supergraph:plan.
  • In /supergraph:plan, every TDD task and contract test must strictly reference the schemas and flows defined in this SDD.

Signals

GitHub stars
22
Forks
5
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
sdd-datit309
Source
github.com/datit309/supergraph