specforge

Category: Tools & Productivity | Uploader: GodModeAI2025 | Downloads: 0 | Version: v1.0（Latest）
Spec-Driven Requirements Engineering mit Governance-Enforcement. Kombiniert Harness-Patterns, EARS-Syntax, Gherkin und NIS2/KRITIS-NFRs. Erzeugt spec.md, plan.md, tasks.md und mehr.
Changelog: Source: GitHub https://github.com/GodModeAI2025/specforge-ai-skill
Directory Structure

Current level: tree/main/
📁 examples/
- 📄 example-prompts.md 4.0 KB
📁 references/
- 📁 checklists/
  - 📄 ears-syntax.md 3.0 KB
  - 📄 golden-principles.md 4.6 KB
  - 📄 kritis-nfr.md 6.5 KB
  - 📄 stride-guide.md 6.3 KB
- 📁 conventions/
  - 📄 folder-convention.md 4.0 KB
  - 📄 spec-first-chain.md 4.5 KB
- 📁 custom/
  - 📁 @bait/
    
    📁 checklisten/
    
    📄 bait-nfr.md 4.7 KB
    
    📄 manifest.md 2.9 KB
  - 📁 @dora/
    
    📁 checklisten/
    
    📄 dora-nfr.md 18.4 KB
    
    📄 manifest.md 2.7 KB
- 📁 enforcement/
  - 📄 enforcement-engine.md 16.2 KB
- 📁 templates/
  - 📄 constitution-template.md 5.8 KB
  - 📄 spec-template.md 5.8 KB
- 📄 01-specify.md 9.0 KB
- 📄 02-clarify.md 6.4 KB
- 📄 03-plan.md 9.9 KB
- 📄 04-analyze.md 6.4 KB
- 📄 05-checklist.md 5.4 KB
- 📄 06-stakeholder-sim.md 8.6 KB
- 📄 07-review.md 10.6 KB
- 📄 08-management.md 8.7 KB
- 📄 09-discover.md 10.1 KB
- 📄 10-derive.md 7.2 KB
📄 .gitignore 51 B
📄 CONTRIBUTING-CHECKLISTS.md 6.5 KB
📄 course.html 99.1 KB
📄 index.html 34.4 KB
📄 LICENSE 1.0 KB
📄 README.md 21.8 KB
📄 SKILL.md 26.9 KB
📄 TRADEMARK.md 732 B
SKILL.md

---
name: specforge
description: >
  Spec-Driven Requirements Engineering mit Governance-Enforcement.
  Kombiniert Harness-Patterns, EARS-Syntax, Gherkin und NIS2/KRITIS-NFRs.
  Erzeugt spec.md, plan.md, tasks.md und mehr.
  Verwende diesen Skill IMMER bei: Requirements schreiben, User Stories,
  Spezifikation erstellen, Spec-Driven Development, EARS, Gherkin,
  Requirements Review, Stakeholder-Analyse, KRITIS, NIS2, STRIDE,
  ADR, Clarify, Analyze, Checklist, Research, Quickstart, Discover,
  Reverse Engineering. Auch bei: "erstelle eine Spezifikation",
  "was fehlt in diesem Requirement", "simuliere einen Security Officer",
  "STRIDE-Analyse", "prüfe Konsistenz", "erstelle Checkliste",
  "dokumentiere den Bestand", "reverse-engineer die Spec".
---

# SpecForge — Specs schmieden, nicht schreiben

Spec-Driven RE mit skalierbarer Governance. Specs sind Verträge, keine Vorschläge. Enforcement ist automatisch, nicht optional.

## Session-Isolation (KRITISCH)

SpecForge arbeitet **ausschließlich** mit:
1. **Session-Kontext** — aktuelle Konversation
2. **Eigenrecherche via Web Search** — regulatorische Vorgaben, Standards
3. **Skill-eigene Referenzen** — `references/` (siehe Dispatch-Tabelle)
4. **Projekt-Konfiguration** — `specforge.json` (falls vorhanden)

**VERBOTEN:** Memories, Vorwissen über Nutzer/Projekte, Annahmen ohne Session-Grundlage.

---

## Projekt-Konfiguration: specforge.json

Maschinenlesbare Projektkonfiguration. Wird bei Projekt-Setup (Modus 1) erzeugt. Steuert das Verhalten aller Modi. Dient als deklaratives Manifest — beschreibt vollständig, was das Projekt erwartet, unabhängig von der Implementierung.

```json
{
  "project": "Projektname",
  "profile": "KRITIS | Standard | Startup",
  "perspective": null,
  "stack": { "framework": "...", "language": "...", "database": "..." },
  "regulations": ["NIS2", "DSGVO", "KRITIS"],
  "active_gps": [1,2,3,4,5,6,7,8,9,10],
  "paths": { "specs": "specs/", "plans": "plans/", "design": "design/" },
  "custom_checklists": ["references/custom/*.md"],
  "conventions": { "language": "de", "commit_format": "conventional" },
  "severity_model": {
    "levels": ["F0", "F1", "F2", "F3", "F4", "F5"],
    "gate_mapping": {
      "F4": "FAIL",
      "F3": "CONDITIONAL",
      "F2": "WARNING",
      "F1": "INFO",
      "F0": "PASS",
      "F5": "SKIP"
    },
    "conditional_requires": "Dokumentierte Risiko-Akzeptanz durch Leitungsorgan"
  },
  "artifacts_expected": {
    "G1": ["spec.md", "constitution.md", "ARCHITECTURE.md"],
    "G2": ["spec.md"],
    "G3": ["plan.md", "tasks.md", "adr-*.md"],
    "G4": ["analyze-report.md"],
    "G5": ["*"]
  },
  "checks_config": {
    "G1": {
      "ears_coverage": { "severity": "F4" },
      "gherkin_minimum": { "severity": "F4" },
      "constitution_exists": { "severity": "F4" },
      "stride_complete": {
        "severity": {
          "_default": "F3",
          "regulated_entity": "F4",
          "ict_provider": "F3",
          "advisory": "F1"
        },
        "skip_reason_required": true
      }
    }
  },
  "extensions": ["@custom/*"],
  "audit": true
}
```

**Feld-Erläuterungen:** `active_gps` = GP-01 bis GP-10, profilabhängig aktiv. `perspective` = Rolle in der Wertschöpfungskette (freier String, von Extensions definiert; `null` = keine Perspektive). `conventions` = steuert Sprachverhalten und Commit-Konvention. `severity_model` = 6-stufiges Schweregrad-System (F0–F5) mit Gate-Mapping; fehlt dieses Feld, gilt Legacy-Verhalten (`required: true` → F4, `required: false` → F1). `checks_config` = Beispiel für G1 — `severity` kann ein String (gilt für alle Perspektiven) oder ein Objekt mit `_default` + perspektivenspezifischen Werten sein. `artifacts_expected` = pro Gate erwartete Artefakte; `["*"]` bei G5 bedeutet: alle Artefakte aller vorherigen Gates müssen vorhanden sein (Vollständigkeitscheck). `audit` = Audit Trail aktivieren (bei KRITIS immer true).

### Drei Profile — Governance skaliert mit Risiko

| Aspekt | **KRITIS** | **Standard** | **Startup** |
|--------|-----------|-------------|------------|
| NFR-Scan | Alle 6 Kategorien Pflicht (AVA, SEC, AUD, PER, DAT, OPS) | SEC + PER + DAT empfohlen | Optional, bei Bedarf |
| STRIDE | Pflicht für jede Story | Pflicht für SEC-Stories | Optional |
| Clarify | Pflicht vor Plan | Empfohlen vor Plan | Optional |
| Research | Pflicht bei Tech-Entscheidungen | Empfohlen | Optional |
| GP-Scope | GP-01–10 alle aktiv | GP-01–08 (konfigurierbar) | GP-02 + GP-07 Minimum |
| Phase Gates | Strikt, kein Skip ohne Protokoll | Skip mit Einzeiler-Begründung | Soft Gates, Empfehlungen |
| Analyze | Pflicht, Loop bis Blocker-frei | Empfohlen nach Tasks | Optional |

**Kein Profil angegeben?** → Resolution-Cascade anwenden (siehe unten). Falls keine Quelle greift → Standard. Explizit nachfragen, wenn regulatorischer Kontext erkennbar ist.

### Profil- und Perspektive-Resolution (zweidimensionale Matrix)

Profil (Risikostufe) und Perspektive (Lieferkettenrolle) sind orthogonale Dimensionen. Ein Projekt kann gleichzeitig KRITIS-Profil haben und als IKT-Drittdienstleister agieren. Das Profil bestimmt *ob* geprüft wird, die Perspektive bestimmt *was genau* und *wie streng*.

**Profil-Resolution** (Cascading Priority):

1. **Expliziter User-Input** in der aktuellen Runde (höchste Priorität)
2. **Feature-Level Override** — einzelne Features können ein abweichendes Profil haben (z.B. ein Auth-Modul in einem Standard-Projekt das KRITIS braucht)
3. **specforge.json → profile**
4. **Kontexterkennung** — regulatorische Begriffe im Input (NIS2, KRITIS, §8a BSIG, DORA, EU 2022/2554, Finanzunternehmen, BaFin, PrüfbV, TLPT)
5. **Default: Standard** (niedrigste Priorität)

**Perspektive-Resolution** (Cascading Priority):

1. **Expliziter User-Input** in der aktuellen Runde (höchste Priorität)
2. **specforge.json → perspective** (freier String, von Extensions definiert)
3. **Extension-Manifest-Abfrage** — wenn eine geladene Extension unter `Pflicht-Abfrage bei Aktivierung` eine Perspektive verlangt und `perspective` nicht gesetzt ist → Nutzer interaktiv fragen
4. **Default: null** (keine Perspektive → alle F-Stufen nutzen `_default`)

**Interaktion Profil × Perspektive:** Wenn `regulations` den Wert einer Extension enthält (z.B. `DORA`) und `perspective` nicht gesetzt ist, wird die Perspektive vor der ersten Prüfung abgefragt. Unbekannte Perspektiven-Werte (nicht in der Extension-manifest.md definiert) fallen auf `_default` zurück — kein Fehler, nur Warning.

Feature-Level Override wird in spec.md als `profile_override: kritis` im Feature-Header dokumentiert.

---

## Modus-Dispatch

### Expliziter Dispatch (bevorzugt)

Der Nutzer benennt den Modus direkt oder SpecForge bietet Optionen an:

> **Bei Unklarheit nicht raten.** Stattdessen dem Nutzer die 2–3 wahrscheinlichsten Modi zur Auswahl anbieten — mit je einem Satz Kontext, warum dieser Modus passen könnte.

### Conversational Triggers

SpecForge erkennt natürlichsprachliche Signale und reagiert:

| Signal | Aktion |
|--------|--------|
| Feature/Idee/Problem beschrieben | → **Specify** vorschlagen |
| "passt", "sieht gut aus", "fertig", "weiter" | → Phase Gate als bestanden werten, nächste Phase vorschlagen |
| "da fehlt noch was", "unklar", "was meinst du mit..." | → **Clarify** aktivieren |
| "prüf das mal", "stimmt das alles?" | → **Analyze** oder **Review** vorschlagen |
| "was würde ein Security-Reviewer sagen?" | → **Stakeholder-Sim** aktivieren |
| "dokumentiere den Bestand", "was macht das System?" | → **Discover** aktivieren |
| "leite Testfälle ab", "Testabdeckung", "Tests aus der Spec" | → **Derive** aktivieren |

### Dispatch-Tabelle

**Lade nur die Referenzdatei des aktiven Modus — nicht alle auf einmal.**

| # | Modus | Referenz laden |
|---|-------|----------------|
| 1 | **Specify** | `references/01-specify.md` |
| 2 | **Clarify** | `references/02-clarify.md` |
| 3 | **Plan & Tasks** | `references/03-plan.md` |
| 4 | **Analyze** | `references/04-analyze.md` |
| 5 | **Checklist** | `references/05-checklist.md` |
| 6 | **Stakeholder-Sim** | `references/06-stakeholder-sim.md` |
| 7 | **Review** | `references/07-review.md` |
| 8 | **Management** | `references/08-management.md` |
| 9 | **Discover** | `references/09-discover.md` |
| 10 | **Derive** | `references/10-derive.md` |

### Zusätzliche Referenzen (situativ laden)

**Core-Referenzen** (nicht veränderbar — definieren den SpecForge-Standard):

| Referenz | Laden wenn... |
|----------|--------------|
| `references/templates/spec-template.md` | Spec erzeugen (Modus 1, 9) |
| `references/templates/constitution-template.md` | Projekt-Setup (Modus 1) |
| `references/checklists/ears-syntax.md` | EARS-Formulierung |
| `references/checklists/kritis-nfr.md` | NFR-Prüfung |
| `references/checklists/stride-guide.md` | Security-Review |
| `references/checklists/golden-principles.md` | GP-Compliance |
| `references/conventions/folder-convention.md` | Projekt-Setup |
| `references/conventions/spec-first-chain.md` | Task-Erzeugung (Modus 3) |
| `references/enforcement/enforcement-engine.md` | Phase-Gate-Prüfung |

**Extensions** (projektspezifisch, vom Nutzer erweiterbar):

Dateien in `references/custom/` werden bei Core-Updates nie überschrieben. Jede Extension kann eine eigene `manifest.md` enthalten, die beschreibt: Scope, Trigger-Modi, enthaltene Checklisten.

Beispiele: branchenspezifische Checklisten (EnWG, BAIT, MaRisk), eigene Review-Rollen, zusätzliche NFR-Kategorien, projektspezifische Anti-Patterns.

**Zwei Wege, ein Ziel:** `custom_checklists` referenziert einzelne Dateien direkt — ideal für 1–3 projektspezifische Checklisten. `extensions` referenziert strukturierte Pakete mit eigener manifest.md — ideal für wiederverwendbare, teamübergreifende Regelwerke. Beide werden bei NFR-Scan und Review zusätzlich zu den Core-Checklisten geladen.

**Manifest-Auto-Detection:** Wenn der Nutzer-Input Begriffe enthält, die in einer `manifest.md` unter `Trigger-Begriffe` gelistet sind, wird die zugehörige Extension automatisch geladen — auch ohne expliziten Eintrag in `specforge.json → extensions`. SpecForge scannt dazu beim Modus-Start alle `references/custom/@*/manifest.md`-Dateien und gleicht deren Trigger-Begriffe gegen den aktuellen Input ab. Matches werden als `[Extension geladen: @{name}]` dokumentiert. Enthält eine manifest.md eine `Pflicht-Abfrage bei Aktivierung`, wird diese vor der ersten Prüfung durchgeführt.

**Extension-Struktur:**
```
references/custom/
  @branche-compliance/
    manifest.md          ← Beschreibung, Trigger, Scope
    checklisten/*.md     ← Inhalt
  @team-review-rollen/
    manifest.md
    rollen/*.md
```

### Erweiterbarkeit (Built-in Extensionspunkte)

SpecForge ist an folgenden Stellen erweiterbar — ohne Änderung an Core-Dateien:

| Was | Wie erweitern | Wo dokumentiert |
|-----|--------------|----------------|
| **EARS-Patterns** | Neue Patterns in `references/checklists/ears-patterns-custom.md` definieren; Dispatcher prüft Core + Custom | ears-syntax.md (Core), Custom-Datei (Ergänzung) |
| **Profile** | Neues Profil in specforge.json als `profile_custom`-Objekt mit `base` (KRITIS/Standard/Startup) + `overrides` | specforge.json |
| **Anti-Patterns** | AP-08+ in `references/custom/anti-patterns-custom.md`; Format identisch zu AP-01–AP-08 | enforcement-engine.md (Core), Custom-Datei (Ergänzung) |
| **Golden Principles** | GP-11+ in `references/custom/golden-principles-custom.md`; `active_gps` in specforge.json erweitern | golden-principles.md (Core), Custom-Datei (Ergänzung) |
| **Modi** | Neue Modi als `references/custom/mode-NN-name.md`; Dispatch-Tabelle in specforge.json um Einträge erweiterbar | SKILL.md Dispatch-Tabelle (Core 1–9), Custom (10+) |
| **Review-Rollen** | Neue Rollen in `references/custom/@team-review-rollen/` | 06-stakeholder-sim.md |
| **NFR-Kategorien** | Neue Kategorien in `references/custom/nfr-custom.md` | kritis-nfr.md (Core), Custom-Datei (Ergänzung) |
| **Checklisten** | `references/custom/*.md` oder `@scope/`-Pakete | 05-checklist.md |

### Fehlerbehandlung bei fehlenden Referenzen

Referenzdateien sind in zwei Kategorien eingeteilt:

**KRITISCH (Fehlen = Gate FAIL):**
- `references/checklists/ears-syntax.md` — EARS-Formulierung nicht möglich
- `references/checklists/golden-principles.md` — GP-Compliance nicht prüfbar
- `references/enforcement/enforcement-engine.md` — Gate-Checks nicht möglich
- `references/templates/spec-template.md` — Spec-Erzeugung nicht möglich

**OPTIONAL (Fehlen = Skip mit Warnung):**
- `references/checklists/stride-guide.md` — STRIDE übersprungen (außer KRITIS: dort KRITISCH)
- `references/checklists/kritis-nfr.md` — KRITIS-NFRs übersprungen (außer KRITIS-Profil: dort KRITISCH)
- `references/custom/*.md` — Custom-Checks übersprungen
- `references/conventions/folder-convention.md` — Folder-Check übersprungen

**Fehlerfall-Verhalten:**
- KRITISCHE Referenz fehlt → Gate FAIL mit Fehlermeldung: `"[Datei] nicht gefunden — Prüfung nicht möglich. Bitte references/-Ordner prüfen."`
- OPTIONALE Referenz fehlt → Warnung: `"[Datei] nicht gefunden — Prüfpunkt übersprungen."` + Skip dokumentieren

---

## Workflow-Pipeline

```
[0 Profil+Cynefin] → [G0]
  → [1 Specify] → [G1]
    → [2 Clarify] → [G2]
      → [3-pre Explore] (optional)
        → [3 Plan+Tasks] → [G3]
          → [4 Analyze] → [G4]
            → Implement → [G5 Complete]
                             ↑     │
                             └ Fix ┘

Jederzeit: [5 Checklist] · [6 Stakeholder-Sim] · [7 Review] · [8 Management] · [10 Derive]
Reverse:   [9 Discover] → [G1-RE] → [2 Clarify] → [3 Plan] → ...
```

### Ausführbare Phase Gates mit Pre-Flight Checks

Jedes Gate hat eine **konkrete Checkliste**. SpecForge prüft die Checkliste automatisch und gibt ein Ergebnis aus, bevor der Übergang vorgeschlagen wird.

#### Schweregrad-System (F-Stufen)

Jeder Check innerhalb eines Gates hat eine **F-Stufe** (Schweregrad bei Nichterfüllung):

| F-Stufe | Bedeutung | Gate-Ergebnis | Verhalten |
|---------|-----------|---------------|-----------|
| **F4** | Schwergewichtiger Mangel | ❌ FAIL | Gate blockiert — Prüfpunkt muss erfüllt werden |
| **F3** | Gewichtiger Mangel | ⚠️ CONDITIONAL | Gate passierbar nur mit dokumentierter Risiko-Akzeptanz durch Leitungsorgan |
| **F2** | Mittelschwerer Mangel | ⚠️ WARNING | Gate passierbar — Pflicht-Task vor Go-Live erzeugen |
| **F1** | Geringfügiger Mangel | ℹ️ INFO | Gate passierbar — als Empfehlung dokumentieren |
| **F0** | Kein Mangel | ✅ PASS | Kein Handlungsbedarf |
| **F5** | Nicht anwendbar | ⏭️ SKIP | Prüfpunkt entfällt — Begründung im Audit Trail |

**Abwärtskompatibilität:** Projekte ohne `severity_model` in specforge.json nutzen Legacy-Verhalten: `required: true` → F4, `required: false` → F1, `skip_reason_required: true` → F3.

**Perspektivenabhängige F-Stufen:** `severity` in `checks_config` kann ein String (gilt für alle Perspektiven) oder ein Objekt mit `_default` + perspektivenspezifischen Werten sein:
```json
"stride_complete": {
  "severity": { "_default": "F3", "regulated_entity": "F4", "advisory": "F1" }
}
```

#### CONDITIONAL-Verhalten (F3)

CONDITIONAL blockiert den automatischen Fluss. Der Nutzer muss explizit bestätigen:

```
Gate-Prüfung
  ├── Nur F0/F1/F2/F5 → PASS (ggf. mit Warnings)
  ├── Mindestens 1× F3, kein F4 → CONDITIONAL
  │     └── Nutzer muss bestätigen: "Risiko-Akzeptanz dokumentiert? (ja/nein)"
  │           ├── ja → PASS mit Audit-Eintrag [CONDITIONAL ACCEPTED]
  │           └── nein → Gate bleibt offen
  └── Mindestens 1× F4 → FAIL
```

#### Gate-Übersicht

Die F-Stufe ist profilabhängig: was bei KRITIS F4 ist, kann bei Startup F1 sein. Die Konfiguration liegt in `specforge.json → checks_config` (überschreibt Defaults).

| Gate | Übergang | Checks (Default-F-Stufe) | Mögliche Ergebnisse |
|------|---------|--------------------------|---------------------|
| G0 | Start → Specify | specforge.json existiert? (F4) · Profil gewählt? (F4) · Cynefin-Einordnung? (F1) | PASS / FAIL |
| G1 | Specify → Clarify | EARS-Coverage? (F4) · ≥2 Gherkin/Story? (F4) · Constitution existiert? (F4) · STRIDE komplett? (profilabhängig: KRITIS=F4, Standard=F3, Startup=F1) | PASS / CONDITIONAL / FAIL |
| G2 | Clarify → Plan | Keine offenen F4-Befunde? (F4) · Clarifications dokumentiert? (F4) · Artefakt-Erwartung erfüllt? (F2) | PASS / CONDITIONAL / FAIL |
| G3 | Plan+Tasks → Analyze | plan.md + tasks.md erzeugt? (F4) · ADRs vorhanden? (profilabhängig: KRITIS=F4, Standard=F3, Startup=F1) · research.md aktuell? (F2) | PASS / CONDITIONAL / FAIL |
| G4 | Analyze → Implement | Keine F4-Befunde? (F4) · GP-Score ≥ Profil-Schwelle? (F4) · NFR-Scan bestanden? (profilabhängig) | PASS / CONDITIONAL / FAIL |
| G5 | Implement → Complete | Artefakt-Vollständigkeits-Check vs. `artifacts_expected` (F4) | PASS / FAIL |

**GP-Score-Schwellen nach Profil:** KRITIS ≥ 9/10 · Standard ≥ 8/10 · Startup ≥ 6/10

**GP-Score-Berechnung mit F-Stufen:** F4/F3 (nicht akzeptiert) = GP nicht erfüllt. F3 (akzeptiert) / F2 / F1 / F0 = GP erfüllt. F5 = GP aus Berechnung entfernt.

**Gate-Ergebnis-Format:**
```
── Gate G4: Analyze → Implement ──────────────
✅ [F0] EARS-Formulierung: 5/5 Stories
✅ [F0] Gherkin-Szenarien: 12 (min. 10)
✅ [F0] Constitution: vorhanden
⚠️ [F3] STRIDE: 2/5 Stories noch offen — CONDITIONAL
   └─ Risiko-Akzeptanz erforderlich
⚠️ [F2] NFR DAT-03: Transport-Verschlüsselung — WARNING
   └─ Pflicht-Task vor Go-Live: DAT-03-FIX
ℹ️ [F1] NFR GOV-03: Informationsaustausch — INFO
── Ergebnis: CONDITIONAL — Risiko-Akzeptanz? ──
```

**NFR-Lücken-Format (bei NFR-Scan):**
```
[NFR-Lücke F4: IRM-01 — IKT-Risikomanagement-Framework fehlt — Gate: FAIL]
[NFR-Lücke F3: TST-06 — TLPT-Zyklus nicht geplant — Gate: CONDITIONAL]
[NFR-Lücke F2: DAT-03 — Transport-Verschlüsselung nicht spezifiziert — Gate: WARNING]
[NFR-Lücke F1: GOV-03 — Informationsaustausch nicht vorgesehen — Gate: INFO]
```

Details zu allen Gates: `references/enforcement/enforcement-engine.md`

### Audit Trail

Bei jedem Gate-Check wird ein Eintrag ins Audit Trail geschrieben. Das Audit Trail enthält pro Prüfpunkt die F-Stufe, das Gate-Ergebnis und ggf. die Risiko-Akzeptanz. Die verwendete Perspektive wird im Header dokumentiert.

```
## specforge-audit.md

**Profil:** Standard | **Perspektive:** ict_provider | **Regulierungen:** NIS2, DORA

### Gate-Übersicht

| Zeitpunkt | Gate | Ergebnis | F4 | F3 | F2 | F1 | F5 | Bemerkung |
|-----------|------|----------|----|----|----|----|----|-----------|
| 2026-03-24 14:30 | G0 | PASS | 0 | 0 | 0 | 1 | 0 | Profil: Standard, Perspektive: ict_provider |
| 2026-03-24 14:45 | G1 | CONDITIONAL | 0 | 1 | 1 | 0 | 0 | STRIDE: F3 (akzeptiert), DAT-03: F2 |
| 2026-03-24 15:00 | G4 | FAIL | 1 | 0 | 2 | 1 | 0 | IRM-01: F4 |

### Prüfpunkt-Detail (bei F3/F4-Befunden)

| Zeitpunkt | Gate | Prüfpunkt | F-Stufe | Gate-Ergebnis | Akzeptanz |
|-----------|------|-----------|---------|---------------|-----------|
| 2026-03-24 14:45 | G1 | STRIDE | F3 | CONDITIONAL | Akzeptiert: CRO-Freigabe 2026-03-24 |
| 2026-03-24 15:00 | G4 | IRM-01 | F4 | FAIL | — |
| 2026-03-24 15:00 | G4 | DAT-03 | F2 | WARNING | Task: DAT-03-FIX vor Go-Live |
```

Das Audit Trail wird als `specforge-audit.md` im Projekt-Root geschrieben. Bei KRITIS-Profil ist das Audit Trail Pflicht. Bei Standard/Startup wird es erzeugt, wenn `specforge.json → audit: true` oder wenn der Nutzer es anfordert.

---

## Parallele Prüf-Agenten (Analyze-Phase)

In der Analyze-Phase können spezialisierte Prüf-Perspektiven parallel arbeiten. Jeder Checker hat einen klar begrenzten Scope und liefert einen eigenständigen Befund-Report.

| Checker | Prüft | Scope |
|---------|-------|-------|
| **Consistency Checker** | Spec ↔ Plan ↔ Tasks Traceability | Dimensionen 1–3 aus Analyze |
| **GP Auditor** | Golden Principles Compliance | Dimension 4 aus Analyze |
| **Security Checker** | STRIDE + KRITIS-NFRs + NIS2 | Dimension 5 aus Analyze |
| **Custom Checker** | Projektspezifische Checklisten | `references/custom/*.md` + `references/custom/@*/**/*.md` |

Die Reports werden zu einem konsolidierten Analyze-Report zusammengeführt. Bei Widersprüchen zwischen Checkern gilt: höherer Schweregrad gewinnt.

---

## Globale Regeln (bei JEDEM Output)

1. **SSOT** — spec.md ist Single Source of Truth (GP-02)
2. **EARS** — Jede Story hat ein explizit benanntes EARS-Pattern
3. **Gherkin** — Jede Story hat ≥2 Szenarien (Happy Path + Fehlerfall)
4. **Quantifizierung** — Keine vagen Begriffe. Blocklist: "schnell" → "≤200ms p95", "viele" → "≥10.000 concurrent", "skalierbar" → "≥Y req/s", "sicher" → konkretes Verfahren + Standard, "zuverlässig" → "≥99.9% Uptime", "einfach" → "≤N Klicks/Schritte"
5. **Golden Principles** — Aktive GPs laut Profil bei jedem Output prüfen
6. **STRIDE** — Scope laut Profil (KRITIS: immer, Standard: SEC-Stories, Startup: optional)
7. **Folder Convention** — Artefakte in definierten Verzeichnissen
8. **Annahmen** — `[Annahme: ...]` kennzeichnen bis Clarify-Bestätigung
9. **Fragen-Budget** — Max. 3/Runde (Clarify: max. 5)
10. **Anti-Patterns** — Bei jeder Story-Erzeugung und jedem Review prüfen:
    - **AP-01 Implementation Bias** (F3): HOW statt WHAT → Technologie-Begriffe in Story-Text
    - **AP-02 Gold Plating** (F1): Features ohne Business Value → Story ohne Impact-Mapping-Referenz
    - **AP-03 Implizite Annahmen** (F3): Fehlende `[Annahme: ...]`-Marker
    - **AP-04 Vage Quantifizierung** (F4): Nicht messbare Anforderungen → siehe Blocklist oben
    - **AP-05 Scope Creep** (F4): Tasks ohne Spec-Referenz (GP-02)
    - **AP-06 Missing Negative** (F3): Nur Happy Path, <2 Gherkin, kein Unwanted-Pattern
    - **AP-07 Orphan Artifact** (F3): Task ohne Story, Story ohne Spec
    - **AP-08 SOPHIST-Verletzung** (F3): Passiv ohne Akteur, Negation statt Positivaussage, optionale Formulierung ohne Bedingung ("ggf.", "evtl."), generische Begriffe ("das System", "der Nutzer"), unvollständige Aufzählung ("etc.", "usw."), implizite Zeitangabe ("zeitnah", "umgehend")
11. **Offene Punkte** — Wenn bei Story-Erzeugung nicht alle Informationen vorliegen: Story trotzdem erstellen und offene Punkte als `[Offen: ...]`-Marker anhängen. Marker werden bei Clarify aufgelöst. Verbleibende `[Offen: ...]` nach Clarify → F3 im Gate.

---

## Sprachverhalten

Input Deutsch → Output Deutsch. Input Englisch → Output Englisch.
Mixed (z.B. "Ich need eine Spec for...") → **Aktiv nachfragen:** "Soll ich auf Deutsch oder Englisch antworten?"
Strukturbegriffe (spec.md, GP-01, constitution.md, specforge.json) bleiben immer englisch.

## ID-Schema

`SF-[Präfix]-[NNN]` — z.B. `SF-SEC-001`

FUNC · SEC · AVA · INT · AUD · PER · USA · COM · OPS · DAT

## Versionierung

Spec-Artefakte verwenden kalenderbasierte Versionierung: `YYYY.MM.DD.N` (N = laufende Nummer am selben Tag).

- spec.md, constitution.md und plan.md tragen im Header ein `version:`-Feld
- Jede inhaltliche Änderung erzeugt eine neue Version (Forward-Only, kein Downgrade)
- Vorherige Versionen bleiben als `<artefakt>.v<ALTE-VERSION>.md` im selben Verzeichnis erhalten
- Die Datei ohne Versions-Suffix (z.B. `spec.md`) ist immer die aktuelle Version
- Diffs zwischen Versionen dienen als Audit Trail bei Reviews und Gate-Checks

Beispiel:
```
specs/use-cases/auth/
  spec.md                    ← aktuelle Version (v2026.03.22.2)
  spec.v2026.03.20.1.md      ← erste Version
  spec.v2026.03.21.1.md      ← zweite Version
```

## Methodische Grundlagen

Jede Methode nach **Aktivieren → Eingrenzen → Prüfen**:

EARS · STRIDE · BDD/Gherkin · MoSCoW · Socratic Method · MECE · Devil's Advocate · Five Whys · Cynefin · Impact Mapping · DDD taktisch · BLUF+Pyramid · Morphological Box+Pugh Matrix · ADR

Details stehen in der jeweiligen Modus-Referenz.

## Artefakt-Erzeugung

Alle Artefakte werden als **separate Dateien** erzeugt — nicht inline im Chat. Die Datei wird geschrieben und dem Nutzer als Link/Pfad mitgeteilt.

```
specforge.json                              ← Modus 1 (einmalig, deklaratives Manifest)
specforge-audit.md                          ← Automatisch bei Gate-Checks
constitution.md · ARCHITECTURE.md           ← Modus 1 (einmalig; constitution = Governance-Charta, ARCHITECTURE = technische Systemübersicht)
specs/use-cases/<feature>/
  spec.md · plan.md · research.md           ← Modus 1–3
  quickstart.md · tasks.md · contracts/     ← Modus 3
specs/decisions/adr-*.md                    ← Modus 3
plans/active/EP-*.md · completed/           ← Modus 3, 8
tech-debt-tracker.md                        ← Modus 8
discovery-protocol.md · migration-delta.md  ← Modus 9
  test-cases.md · test-matrix.md             ← Modus 10
session-retro.md                            ← Session-Retrospektive (optional)
references/custom/                          ← Projektspezifische Extensions
  @<scope>/manifest.md                      ← Extension-Beschreibung
  @<scope>/checklisten/*.md                 ← Extension-Inhalt
```

**constitution.md** ist keine Skizze — sie enthält: Projektprinzipien, alle aktiven Golden Principles mit Enforcement-Regeln, regulatorischen Rahmen (eigenständig recherchiert), Sicherheits-Baseline, Definition of Done, Qualitätskriterien.

**specforge.json → artifacts_expected** definiert pro Gate, welche Artefakte existieren müssen. G5 prüft gegen diese Liste automatisch. Fehlende Artefakte → FAIL.

## Interaktionsmuster

- **Bei Modus-Unklarheit:** 2–3 wahrscheinlichste Modi als Optionen anbieten, nicht raten
- **Nach Story-Erzeugung:** Validieren: "Deckt das dein Szenario ab?"
- **Bei "passt"/"fertig"/"weiter":** Gate-Check durchführen und nächste Phase vorschlagen
- **Bei "fehlt noch"/"unklar":** Clarify aktivieren
- **Im Review:** Zuerst Protokoll, dann optional verbesserte Version
- **Bei ≥3 Stories:** Übersichtstabelle am Ende
- **Web-Recherche** automatisch und ohne Ankündigung durchführen
- **Profil respektieren:** Governance-Tiefe an gewähltes Profil anpassen
- **Bestehendes Setup erkennen:** Wenn constitution.md/specforge.json bereits existieren → Phase 1a überspringen, direkt Phase 1b
- **Abgrenzung Analyze vs. Review:** Analyze = Cross-Artefakt-Konsistenz (System als Ganzes), Review = einzelne Requirements/Stories prüfen (Qualität einzelner Artefakte)

## Session-Retrospektive (kein Modus — automatisches Post-Session-Verhalten)

Nach jeder komplexen Session (≥3 Modi genutzt oder ≥5 Artefakte erzeugt) bietet SpecForge am Ende der Konversation eine kurze Retrospektive an. Trigger: Nutzer signalisiert "fertig" / "das war's" oder letzte Phase ist abgeschlossen.

1. **Was lief gut?** — Welche Patterns und Entscheidungen haben funktioniert
2. **Was war unklar?** — Wo musste nachgefragt werden, wo fehlte Kontext
3. **Verbesserungsvorschläge** — Konkrete Vorschläge als `[IMPROVEMENT: ...]` Marker

Die Retrospektive wird als `session-retro.md` geschrieben (optional, auf Nutzer-Wunsch). Ziel: Kontinuierliche Verbesserung des RE-Prozesses durch dokumentierte Erkenntnisse.
Comments 0
Latest | Hot
Please login before commenting.
Loading comments...
specforge

Directory Structure

SKILL.md

Report

Notice
