SDD Framework Comparative Assessment Superpowers - TerrenceMcGuinness-NOAA/global-workflow GitHub Wiki

SDD Framework Comparative Assessment: EIB SDD vs. Superpowers

(June 24, 2026)

A comparative assessment of two community "Superpowers" agentic-development frameworks β€” obra/superpowers and its Copilot CLI repackaging DwainTR/superpowers-copilot β€” against the EIB Spec-Driven Development (SDD) Framework that powers the MDC MCP-RAG Server for the NOAA Global Workflow.

TL;DR β€” The two are solving different problems with overlapping vocabulary. Superpowers is a portable, harness-agnostic skills library that shapes how an agent behaves during a coding session (brainstorm β†’ plan β†’ TDD β†’ review). EIB SDD is a domain-anchored, stateful methodology that governs what gets coded in a single safety-critical repository, with server-side session tracking, a live code-graph + RAG knowledge base, and an auditable spec-first gate. They are complementary, not substitutes. The highest-value takeaways for us are Superpowers' enforced TDD red/green loop, two-stage subagent review, and automatic skill triggering.

1. What Each Framework Is

1.1 obra/superpowers

  • Author / community: Jesse Vincent (Prime Radiant). ~238k stars, 43 contributors, MIT licensed, very active (v6.0.3 released the week of this assessment).
  • Nature: "An agentic skills framework & software development methodology that works." A library of composable skills (each a SKILL.md with YAML frontmatter) plus bootstrap instructions that make the agent automatically consult relevant skills before acting.
  • Harness coverage: Claude Code, Antigravity, Codex App/CLI, Cursor, Factory Droid, Gemini CLI, GitHub Copilot CLI, Kimi Code, OpenCode, Pi. Distributed via per-harness plugin marketplaces.
  • Core loop: brainstorming β†’ using-git-worktrees β†’ writing-plans β†’ subagent-driven-development / executing-plans β†’ test-driven-development β†’ requesting-code-review β†’ finishing-a-development-branch.
  • Philosophy: TDD-always, systematic over ad-hoc, complexity reduction, evidence over claims.
  • State model: Largely stateless between sessions β€” behavior lives in skill markdown and git worktrees/branches; there is no central session ledger or domain knowledge base.

1.2 DwainTR/superpowers-copilot

  • Nature: A faithful repackaging of obra/superpowers' 14 skills + 1 code-reviewer agent for the GitHub Copilot CLI native plugin/skills system. ~65 stars, single packager, MIT (skills remain Jesse Vincent's original work).
  • Added value: Copilot CLI plugin manifest, install.sh one-command setup, and a snippet injected into ~/.copilot/copilot-instructions.md that replicates the Superpowers session-start hook (check for relevant skills before every task).
  • Caveat: Explicitly a stopgap "until obra/superpowers ships native GitHub Copilot CLI support." No independent methodology β€” it inherits everything from upstream.

1.3 EIB SDD Framework (ours)

  • Nature: A domain-anchored, stateful Spec-Driven Development methodology embedded in the MDC MCP-RAG Server. Version 6.0 / Phase 31 session-oriented execution model (evolved from the 5.0 ISD/USD architecture).
  • Governing rule: "If it's not in the SDD, it doesn't get coded." A spec-first gate requires a committed spec (under .kiro/specs/ or sdd_framework/workflows/phaseN_*.md) before any non-trivial implementation commit.
  • Execution surface: 9 MCP tools β€” list_sdd_workflows, get_sdd_workflow, start_sdd_session, record_sdd_step, get_sdd_session, complete_sdd_session, get_sdd_execution_history, validate_sdd_compliance, get_sdd_framework_status.
  • State model: Stateful and auditable. Sessions persist to JSONL execution history (59 workflows, 43 sessions, 31 completed / 2 abandoned at time of writing). Each phase is tracked step-by-step with tags and velocity analytics.
  • Knowledge backing: A live code graph (Neptune/Neo4j β€” ~19.7K–148K nodes, 2.65M relationships) + vector RAG (OpenSearch/ChromaDB β€” 206K–220K docs) feeding GraphRAG, EE2-compliance, and operational-guidance tools.
  • Execution modes: dry_run (spec parse, terraform-plan analogue), supervised/ISD (human approves each side-effect), auto_approved (manifest pre-approval), autonomous/USD (disabled for safety-critical systems).
  • Domain: Singular focus on the NOAA Global Workflow / GFS operational forecasting infrastructure, with EE2 (EMC Environment 2.0 / NCO) compliance as a first-class concern.

2. Side-by-Side Comparison

Dimension obra/superpowers superpowers-copilot EIB SDD (ours)
Primary goal Shape agent behavior via skills Same, repackaged for Copilot CLI Govern what gets coded in one critical repo
Unit of work Skill (SKILL.md) Skill (SKILL.md) Spec / phase workflow + tracked session
State Stateless (git worktrees) Stateless Stateful JSONL session ledger
Knowledge base None (general) None Code graph + vector RAG (GraphRAG)
Domain coupling Domain-agnostic Domain-agnostic NOAA Global Workflow / EE2-specific
Harness portability 11 harnesses Copilot CLI only MCP clients (Kiro, Copilot, Claude, CLI)
TDD enforcement Enforced RED-GREEN-REFACTOR Enforced (inherited) Recommended, not gated
Subagent review Two-stage (spec + quality) Two-stage (inherited) Single-agent + validate_sdd_compliance
Auto-triggering Yes (session-start hook) Yes (instructions snippet) Partial (spec-first gate is manual discipline)
Approval/safety model Human checkpoints in plan Human checkpoints Formal modes (ISD/USD, manifest gates, autonomous disabled)
Auditability Git history Git history Execution history + compliance validation
Maturity / reach 238kβ˜…, very active 65β˜…, stopgap Internal, production for one program
License MIT MIT Internal (NOAA/OMD)

3. Philosophy & Architecture Contrast

3.1 Behavior-shaping vs. work-governing

Superpowers is fundamentally about agent discipline: it injects mandatory workflows ("not suggestions") so any agent, on any project, brainstorms before coding, writes a plan, follows red/green TDD, and reviews its own work. It is horizontal β€” broad portability, zero domain knowledge.

EIB SDD is about change governance in a single high-stakes codebase. The spec-first gate, session ledger, and compliance validation exist because an AI agent editing operational weather-forecasting code must leave an auditable trail and must not silently introduce gaps. It is vertical β€” deep domain anchoring (code graph, EE2 standards, HPC platform configs), narrow portability.

3.2 Stateless skills vs. stateful sessions

Superpowers carries no memory between runs beyond what git and the skill files encode. EIB SDD's session model (start_sdd_session β†’ record_sdd_step β†’ complete_sdd_session) produces a durable, queryable record with velocity trends and phase-status analytics β€” closer to a lightweight project-management substrate than a behavior library.

3.3 General TDD vs. domain RAG

Superpowers' strongest mechanic is enforced RED-GREEN-REFACTOR with deletion of pre-test code. EIB SDD's strongest mechanic is the GraphRAG knowledge backing β€” the agent can trace callers/callees, env-var dependencies, and execution paths through a real code graph, and ground answers in 200K+ ingested docs. Neither framework has the other's strength.

4. Strengths & Gaps

4.1 Where Superpowers is ahead of us

  1. Enforced TDD loop. Mandatory failing-test-first with code deletion if tests come late. EIB SDD recommends testing but does not gate on it.
  2. Two-stage subagent review. Fresh subagent per task, reviewed first for spec compliance then for code quality. Our flow is mostly single-agent.
  3. Automatic skill triggering. A session-start hook guarantees the right workflow activates without the operator remembering to invoke it. Our spec-first gate relies on human discipline.
  4. Portability & community velocity. Works across 11 harnesses with a large, fast-moving contributor base.

4.2 Where EIB SDD is ahead of Superpowers

  1. Domain grounding. Live code graph + 200K-doc RAG + EE2 compliance β€” none of which Superpowers attempts.
  2. Stateful auditability. JSONL session history, validate_sdd_compliance, and per-phase analytics give an audit trail suited to operational software.
  3. Formal safety modes. Explicit ISD/USD/auto-approved/dry-run semantics with autonomous deliberately disabled for safety-critical systems.
  4. Spec-first traceability. Vision→implementation cross-referencing and a hard gate that prevents undocumented change — critical in an environment where silent gaps surface late (cf. the MPAS path-prefix retrospective).
  5. Integrated infrastructure health. Health snapshots, trend detection, and knowledge-integrity checks are part of the same toolset.

4.3 Shared blind spots

  • Neither provides true sandboxed execution β€” Superpowers leans on git worktrees/branches; EIB SDD's dry_run only parses specs (it is "show me the recipe," not "cook in a test kitchen"). Container isolation is partial in both.
  • Both still depend on human judgment at key gates; full autonomy is either unavailable (ours, disabled) or bounded by checkpoints (theirs).

5. Recommendations β€” What to Adopt

The frameworks are complementary. EIB SDD should keep its domain/state/audit core and selectively borrow Superpowers' behavioral mechanics:

  1. Adopt an enforced TDD step type. Add a gated test_first step to the SDD step-type vocabulary so phases that touch shared pipeline code require a failing test recorded before the implementation step. (Spec-first β†’ test-first.)
  2. Add two-stage review to USD/subagent dispatch. When Phase 4C USD work resumes, dispatch a fresh review subagent that checks (a) spec compliance via validate_sdd_compliance, then (b) code quality β€” mirroring Superpowers' requesting-code-review / code-reviewer agent.
  3. Strengthen auto-triggering. Convert the spec-first gate from manual discipline into a session-start instruction (akin to the Superpowers hook) that prompts start_sdd_session whenever non-trivial change is detected.
  4. Package SDD as portable skills. Where the work is not domain-specific (planning, review, verification-before-completion), expose SDD behaviors as SKILL.md-style assets so they ride the same Copilot/Claude skill surface our agents already use.
  5. Do not adopt Superpowers' stateless model for governed change β€” our audit trail and EE2 compliance posture depend on the stateful session ledger.

6. Verdict

obra/superpowers superpowers-copilot EIB SDD
Best for Any agent, any repo: disciplined coding behavior Copilot CLI users wanting Superpowers today Governed, auditable change in the NOAA Global Workflow
Substitute for ours? No No β€”
Worth borrowing from? Yes β€” TDD loop, two-stage review, auto-triggering Indirectly (it is upstream repackaged) β€”

Superpowers and EIB SDD occupy different layers of the stack: Superpowers is a horizontal behavior library, EIB SDD is a vertical governance and knowledge platform. The pragmatic path is to keep our domain/state/audit foundation and graft Superpowers' best behavioral mechanics β€” enforced TDD, two-stage subagent review, and automatic triggering β€” onto it.

References