Does GSD Truly Outperform OpenSpec and Superpowers? A Source Code Dive into Their Three Layers of Context‑Rot Defense

Both OpenSpec, Superpowers and GSD aim to mitigate the phenomenon researchers call context rot , where a transformer‑based AI model silently degrades as its context window fills. The degradation manifests in four documented ways: contradictory decisions, drifted code style, ignored historic requirements, and hallucinated signatures.

1. Understanding Context Rot

The GSD documentation states that the issue is not a model bug but an inherent property of attention over long sequences. This premise determines where each framework places its defense.

2. OpenSpec – Guarding the Requirement Layer

OpenSpec targets the first symptom: the AI’s requirements drifting in a long chat. Its README declares that AI coding assistants are powerful but unpredictable when requirements live only in chat history. The solution is to move requirements from the volatile chat into a version‑controlled file system ( docs/overview.md).

2.1 Core Trio: spec / change / delta

openspec/
├── specs/      ← source of truth
│   └── auth/spec.md
└── changes/    ← in‑progress changes
    └── add-2fa/
        ├── proposal.md   ← why & what to change
        ├── design.md     ← how to change
        ├── tasks.md      ← checklist
        └── specs/        ← delta spec
            └── auth/spec.md

The specs/ directory holds the current truth, while changes/ contains incremental deltas that are merged back into specs/ upon completion. This delta‑spec approach avoids rewriting whole specifications.

2.2 Delta Spec – Incremental Changes Only

## ADDED Requirements
### Requirement: Two‑Factor Authentication

## MODIFIED Requirements
### Requirement: Session Expiration
Previously: 30 minutes → 15 minutes

## REMOVED Requirements
### Requirement: Remember Me
Deprecated in favor of 2FA

Three benefits are cited (docs/concepts.md): clarity (review diff only), conflict avoidance (different changes can target the same spec file without stepping on each other), and brownfield fit (you can start with a single change on an existing project).

2.3 What OpenSpec Does Not Enforce

❌ No enforcement of context hygiene – it assumes the main chat stays clean.

❌ No automatic execution control – the apply command lets the AI act freely without atomic commits.

❌ No code‑quality checks beyond spec consistency.

Consequently, OpenSpec works best when the conversation remains short and clean; longer dialogs can cause the AI to misinterpret even a clear spec.

3. Superpowers – Guarding the Workflow Discipline Layer

Superpowers diagnoses the second symptom: the AI skipping TDD, code review, and other disciplined steps in a long conversation.

3.1 Automatic Skill Invocation

Skills are defined in skills/using-superpowers/SKILL.md. The rule reads:

Invoke relevant or requested skills BEFORE any response or action. Even a 1% chance a skill might apply means that you should invoke the skill to check.

Skill checks must happen before any clarifying question, preventing the AI from using “I need more context” as an excuse.

3.2 The Red‑Flags Table

The table maps common faulty thoughts to the correct reality, e.g., “This is just a simple question” → “Questions are tasks. Check for skills.” This acts as a psychological guard against the model’s attempts to bypass skills.

3.3 Skill Landscape (14 Skills)

Test : test-driven-development Debug : systematic-debugging, verification-before-completion Collaboration : brainstorming, writing-plans, executing-plans, dispatching-parallel-agents, requesting-code-review, receiving-code-review, using-git-worktrees, finishing-a-development-branch, subagent-driven-development Meta : writing-skills, using-superpowers Each skill enforces a hard gate, e.g., the brainstorming skill contains the rule: “Do NOT invoke any implementation skill, write any code, or take any implementation action until you have presented a design and the user has approved it.”

3.4 What Superpowers Does Not Cover

❌ No cross‑session state persistence (no .planning/ directory).

❌ No structured parallel execution – parallelism is ad‑hoc.

❌ No delta‑spec merging; design documents live under docs/superpowers/specs/ but changes are not automatically merged.

4. GSD – Guarding the Attention‑Decay Layer

GSD acknowledges that OpenSpec and Superpowers only treat symptoms; the root cause is the model’s attention dilution. Its core insight (docs/explanation/context-engineering.md) is that most work can be split into discrete, bounded tasks handed to specialised sub‑agents with fresh context windows.

4.1 Orchestrator → Fresh‑Context Agent

Orchestrator (workflow .md file)
│
├── Load context (gsd‑tools.cjs init <workflow>)
├── Resolve model (gsd‑tools.cjs resolve-model <agent‑name>)
├── Spawn specialised agent
│   ├── Agent definition (agents/*.md)
│   ├── Context payload (init JSON)
│   ├── Model assignment
│   └── Tool permissions
├── Collect result
└── Update state (gsd‑tools.cjs state update)

The orchestrator stays thin: it does not reason about the domain, write code, or interpret results beyond routing.

4.2 Agent Landscape (34 Agents, 70 Commands, ~44 Core Features)

Source inspection shows 34 agents (e.g., project‑researcher, planner, executor), 70 commands under commands/gsd/, and roughly 44 core features listed in FEATURES.md. Numbers in secondary articles were slightly off.

4.3 Wave Execution – Structured Parallelism

Tasks are grouped into dependency‑based waves; tasks within a wave run in parallel, waves execute sequentially:

Plan 01 (no deps) ─┐
Plan 02 (no deps) ─┤── Wave 1 (parallel)
Plan 03 (depends: 01) ─┤── Wave 2 (waits for Wave 1)
Plan 04 (depends: 02) ─┘
Plan 05 (depends: 03, 04) ─── Wave 3

Two concurrency‑safety mechanisms are unique to GSD:

Atomic lock STATE.md.lock created with O_EXCL and auto‑cleared after >10 s.

Per‑wave hook run using --no-verify to skip pre‑commit checks, then a final orchestrator hook after the wave.

4.4 Cross‑Session Persistence

GSD stores project state in a .planning/ hierarchy (PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, phases/*). The continue‑here.md file enables session‑level checkpointing: when the orchestrator’s context nears its limit, progress is written to this file and a fresh orchestrator resumes later.

4.5 Trade‑offs (Explicitly Listed)

Coordination overhead : spawning each agent incurs 1‑5 minutes of latency, making simple tasks slower than a single‑agent approach.

Opacity during execution : sub‑agents run invisible to the parent session, complicating debugging.

Context stitching cost : the orchestrator must assemble correct context for each agent.

Model cost amplification : running 5 Opus‑tier agents in parallel costs roughly 5× more, though cheaper profiles can handle lightweight tasks.

Because of these costs, GSD provides shortcuts ( /gsd‑quick, /gsd‑fast) to skip full phase loops for tiny tasks.

5. Comparative Summary (Numbers from Source)

Diagnosis layer : OpenSpec – requirement drift; Superpowers – workflow discipline decay; GSD – attention‑level rot.

Core mechanism : spec/change/delta; 14 auto‑trigger skills; orchestrator + fresh‑context sub‑agents.

Persistence : specs/ + changes/; none; .planning/ + STATE.md + continue‑here.md.

Parallel scheduling : none; ad‑hoc model‑driven; wave execution with atomic lock.

Hard gates : none; TDD & design approval enforced; plan‑checker (no forced TDD).

Scale : OpenSpec – small‑to‑medium; Superpowers – medium; GSD – medium‑to‑large.

Learning curve : lowest for OpenSpec, medium for Superpowers, highest for GSD.

6. Ideal User Profiles

OpenSpec : Teams with an existing CI/TDD pipeline that only need a thin AI‑requirement layer; pain point is AI forgetting the original goal.

Superpowers : Teams that already follow good habits but need enforcement; pain point is AI skipping tests or code review in long chats.

GSD : Large, multi‑file, multi‑session projects where attention decay is a show‑stopper; users accept ritualised flows and higher model cost for the guarantee that the AI won’t “forget” after a few files.

7. Conclusion

The three frameworks are not competitors but complementary layers of defense against context rot. OpenSpec secures the outermost requirement layer, Superpowers hardens the middle workflow discipline, and GSD isolates the innermost attention‑decay problem through structured parallelism and cross‑session persistence. Selecting or stacking them depends on where context rot manifests in your workflow.