Was ist SpecForge?

Ein Claude-Skill, der Requirements Engineering von der Idee bis zum implementierungsreifen Backlog automatisiert — mit Governance-Enforcement statt optionalen Richtlinien. Governance ist ein Compiler, kein Komitee.

Specify

Aus einer Feature-Idee wird eine vollständige spec.md mit EARS-Requirements, Gherkin-ACs und STRIDE-Analyse.

Clarify

Sokratische Spezifikationsklärung: gezielte Fragen zu Stakeholder-Konflikten, Annahmen und Systemgrenzen.

Plan & Tasks

Technischer Plan mit ADRs, Explore-Phase, Morphological Box + Pugh Matrix, Brownfield/Greenfield-Erkennung.

Analyze

MECE-Konsistenzprüfung über 5 Dimensionen mit Re-Analyze-Loop (max. 5 Iterationen) bis keine Blocker offen sind.

Checklist

4 Checklist-Typen: Spec-Readiness, Compliance, Security, Domain-spezifisch. Wiederverwendbare Quality Gates.

Stakeholder-Simulation

8 Rollen, deterministische Keyword-basierte Auswahl, Gate-Integration. Findings blockieren Gate G4.

Review

3-Ebenen-Review mit GP-Score-Formel: Requirement-Qualität, Governance-Compliance, Security & Compliance.

Management

7 Funktionen: Traceability Matrix, SFC-Audit, ExecPlan-Übersicht, Tech-Debt, Spec-Diff, Freshness, Analyze-Historie.

Discover

Reverse Spec mit 5W-Pflichtanalyse, zwei QS-Schleifen (max. 5 Iterationen) und eigenen RE Gates (G0-RE bis G4-RE).

Derive

Testfall-Ableitung aus Gherkin-Szenarien: 6 Testfall-Typen, Testabdeckungsmatrix, Traceability-Prüfung und profilabhängiger Scope.

Neu in v3.2 — Governance & Qualität

Regulatorische Tiefe, sprachliche Qualitätsmessung und erweiterbare Compliance-Module.

F-Stufen (F0–F5)

6-stufiges Schweregrad-System nach PrüfbV §27 ersetzt binäres Pass/Fail. Von F0 (formaler Mangel) bis F5 (kritisch, Gate-blockierend).

DORA & BAIT

Custom Extensions für regulatorische Frameworks: DORA (EU 2022/2554, 58 Prüfpunkte) und BAIT (BaFin, 8 Prüfpunkte). Eigenes @dora/ und @bait/ Modulsystem.

★

Story-Quality-Score

Numerische Formulierungsqualität (SQS 0–5) über 5 gewichtete Dimensionen: Titel, Description, Gherkin, SOPHIST, EARS. Non-blocking Quality Gate.

⚠

8 Anti-Patterns

Inkl. AP-08 SOPHIST-Verletzung: Passiv ohne Akteur, Negation statt Positivaussage, generische Begriffe, unvollständige Aufzählung, implizite Zeitangaben.

Multi-File-Architektur

v3.2 wechselt von Single-File (~120 KB) zu einer modularen Architektur. Orchestrator + 10 Fachmodule + 17 Support-Dateien.

Dateien

~4.900

Zeilen

494

Orchestrator

Module

SKILL.md (494 — Orchestrator) references/ 01-specify.md (187) 07-review.md (207) 02-clarify.md (159) 08-management.md (199) 03-plan.md (242) 09-discover.md (215) 04-analyze.md (144) 10-derive.md (172) 05-checklist.md (132) checklists/ templates/ 06-stakeholder-sim.md (155) conventions/ enforcement/ custom/

Jedes Modul folgt einer einheitlichen Struktur:

Profil-Steuerung

Stringenz-Regeln

Erweiterbarkeit

Fehlerbehandlung

GP-Mapping

Erzeugte Artefakte

Fremder Code, keine Doku?

Viele Projekte erben Codebases ohne Spezifikation — zugekauft, gewachsen oder schlicht nie dokumentiert. Modus 9 (Discover) macht daraus eine vollwertige Spec:

Bestand erfassen

Quellen identifizieren, Architektur und Abhängigkeiten kartieren — automatisch per Discovery-Protokoll.

5W-Analyse

Für jedes Modul: Wer, Was, Warum, Wie, Wann — mit Evidenz und Konfidenzlevel statt Vermutungen.

Spec generieren

Zwei QS-Schleifen (max. 5 Iterationen) mit eigenen RE Gates liefern eine vorwärts-kompatible Spezifikation.

Ergebnis: spec.md + discovery-protocol.md + optional migration-delta.md — direkt anschlussfähig an die Modi 1–8.

Workflow

Phase 0 Phase 1 Phase 2 Phase 3 Phase 4 Cynefin+Impact ─── Specify ─── Clarify ─── Plan+Research ─── Tasks │ Phase 8 Phase 7 Phase 6 Phase 5 │ Management ─── Review ─── Implement ─── Analyze ◄──────────────┘ ▲ │ └────┘ Re-Analyze Loop Phase 9: Discover (eigenständiger Einstieg) Bestand ─── Discovery ─── Spec-Gen ─── QS1:Vollständigkeit ─── QS2:Konsistenz ─── Spec Phase 10: Derive (jederzeit nach Specify) Gherkin-Szenarien ─── Testfall-Ableitung ─── Testabdeckungsmatrix ─── Traceability

Der Execution-Handoff: SpecForge 🤝 Get Shit Done & MissionForge

SpecForge generiert makellose, audit-sichere Specs. Aber wer baut sie? Hier kommen die Execution-Pipelines ins Spiel.

💻

Weg A: Get Shit Done (GSD)

Für massive Code-Änderungen im Terminal.
GSD nimmt die SpecForge spec.md entgegen, zerlegt sie in atomare Agenten-Pläne und schreibt parallel Code in frischen, isolierten 200k-Token-Fenstern. Verhindert Context Rot und pusht saubere Git-Commits. Ideal für die Claude Code CLI.

/gsd:plan-phase ➡️ /gsd:execute-phase

🏢

Weg B: MissionForge & TaskPulse

Für komplexe Agenten-Orchestrierung im Chat.
Spawnt eine In-Chat-Company mit Planung, Ausführung und Verifikation. Jeder Sub-Agent erhält spezifische Tasks basierend auf den REQ-IDs aus SpecForge. Führt TaskPulse-Protokolle – voll kompatibel zum Enterprise Skill Governance Framework.

"Spawne Company basierend auf spec.md"

🏛️

Enterprise Governance Ready

SpecForge, MissionForge und GSD integrieren nahtlos in das Skill Governance Framework. SpecForge erzeugt ITIL/CMDB-konforme Anforderungen (Block A-F), und die Ausführungswerkzeuge hinterlassen pflichtgemäße Ausführungsprotokolle (TaskPulse) für das QA-Audit.

15 Methodische Grundlagen

Jede Methode wird nach dem Aktivieren-Eingrenzen-Prüfen-Muster eingesetzt.

Methode	Herkunft	Einsatz
Cynefin Framework	Dave Snowden (1999)	Phase 0 — Komplexitätseinschätzung
Impact Mapping	Gojko Adzic (2012)	Phase 0 — Scope-Validierung
Socratic Method	Platon/Sokrates	Clarify-Modus
Five Whys	Taiichi Ohno (Toyota)	BLOCKER-Analyse
MECE Principle	Barbara Minto (McKinsey)	Analyze-Modus
Devil's Advocate + Steelmanning	Advocatus Diaboli (1587)	Stakeholder-Simulation
Morphological Box + Pugh Matrix	Fritz Zwicky (1940er) / Stuart Pugh (1991)	Technologieentscheidungen
DDD (taktisches Design)	Eric Evans (2003)	Datenmodell in spec.md
BLUF + Pyramid Principle	US-Militär / B. Minto	Spec-Zusammenfassungen
MoSCoW	Dai Clegg (DSDM)	Story-Priorisierung
ADR nach Nygard	Michael Nygard (2011)	Architecture Decision Records
EARS Requirements	Alistair Mavin (Rolls-Royce)	Requirement-Syntax
STRIDE	Microsoft	Threat Modeling
BDD / Gherkin	Dan North	Acceptance Criteria
SSOT (Single Source of Truth)	—	spec.md als autoritative Quelle (GP-02)

10 Golden Principles

GP-01 Schema-Hygiene

GP-02 Spec-before-Code

GP-03 ADR-Disziplin

GP-04 ExecPlan-Pflicht

GP-05 Invariant-Traceability

GP-06 Keine stale Marker

GP-07 Dokument-Platzierung

GP-08 Prinzip-Unverletzlichkeit

GP-09 Abhängigkeitsrichtung

GP-10 Schulden-Tracking

Installation

Claude.ai — Projekt-Knowledge

Claude-Projekt öffnen
Project Knowledge aufrufen
SKILL.md + references/ hochladen
Sofort aktiv

Claude Cowork — Plugin/Skill

Skill-Ordner in Plugin-Verzeichnis kopieren
In plugin.json registrieren
Als Skill verfügbar

Claude Code — Projekt-Kontext

Skill-Ordner in .claude/knowledge/ legen
Optional: In CLAUDE.md referenzieren
Automatisch geladen

Erzeugte Artefakte

`constitution.md`

Projektprinzipien, Golden Principles, regulatorischer Rahmen, Definition of Done

`spec.md`

Funktionale Spezifikation mit EARS-Requirements und Gherkin-ACs

`plan.md`

Technischer Implementierungsplan mit ADRs

`research.md`

Technische Tiefenrecherche (Versionen, CVEs, Kompatibilität)

`quickstart.md`

Entwickler-Schnelleinstieg für sofortiges Onboarding

`tasks.md`

Task-Breakdown mit Spec-First Chain und Parallelisierungsmarkern

`discovery-protocol.md`

Bestandsaufnahme: Quellenverzeichnis, Vollständigkeitsampel, QS-Protokolle (Modus 9)

`migration-delta.md`

Ist/Soll-Abweichungen als Grundlage für Modernisierung (Modus 9, optional)

`test-cases.md`

Strukturierte Testfälle mit Given/When/Then, konkreten Testdaten und Traceability (Modus 10)

`test-matrix.md`

Testabdeckungsmatrix: Story → Testfall-Zuordnung mit Typ, Priorität und Automatisierungsgrad (Modus 10)