--- title: github/spec-kit — Re-Audit 2026-05-24 type: audit tags: [audit, spec-driven-development, re-check, aria-first] date: 2026-05-24 status: aktiv prior_audit: 02-Wissen/github-spec-kit-audit-2026-05-14.md source: https://github.com/github/spec-kit confidence: high --- # github/spec-kit — Re-Audit 2026-05-24 ## 1. Was ist es jetzt + was hat sich seit 14.05 geändert? ### Repo-Metrics | Metrik | 14.05.2026 (Audit 1) | 24.05.2026 (Re-Audit) | Delta | |---|---|---|---| | Stars | 98.334 | 105.000+ | +6.7k in 10 Tagen | | Version | ~0.8.10 | 0.8.13 | 3 Minor-Releases | | Letzter Push | 2026-05-13 | 2026-05-21 | aktiv | | Open Issues | unbekannt | aktiv | — | ### Struktur-Änderungen seit 14.05 Neue Top-Level-Verzeichnisse, die beim ersten Audit NICHT explizit dokumentiert waren: - `workflows/` — NEU: YAML-Workflow-Engine (v0.8.0, 23.04.2026) - `extensions/` — war bekannt, aber deutlich gewachsen - `newsletters/` — Community-Kommunikation - `docs/` — ausgebaut, inkl. High-Assurance-Workflow-Doku ### Versions-Delta 0.8.10 → 0.8.13 (nach 14.05): **0.8.13 (2026-05-21)** - Fix: while/do-while loop condition reads stale iteration-0 step output - `specify check` bekommt self-check tip im Output - Agent Governance Extension auf v1.2.0 - Neue Community-Workflows in Katalog (agentic workflow submissions) **0.8.12 (2026-05-20)** - Codex Skills: dot-to-hyphen hook command injection - Squad Bridge Extension v1.3.0, Architecture Workflow v1.1.0 - `fix(workflow): support integration: auto` — Workflows können jetzt automatisch die initialisierte Integration des Projekts nutzen - Superpowers Implementation Bridge Extension in Community-Katalog - Interactive HTML Preview Extension in Community-Katalog **0.8.11 (2026-05-15)** - Version feature reporting (`specify --version` erweitert) - High-Assurance Spec Workflow dokumentiert (in `docs/`) - Fix: PowerShell UTF-8 BOM - Time Machine Extension im Community-Katalog - Architecture Workflow Extension im Community-Katalog Fazit: Die Post-14.05-Releases sind größtenteils **Extension-Katalog-Wachstum + CLI-Bugfixes**. Kein Redesign des Kern-Workflows. --- ## 2. Was ist NEU oder NOCH NICHT extrahiert? Aria's /spec Skill (SKILL.md) ist ein ausgezeichneter Extrakt der Kernstruktur. Trotzdem gibt es 5 Lücken: ### 2.1 Workflow-Engine (NICHT extrahiert, Tier-1) Das größte neue Feature, das beim ersten Audit nur als "CLI-Funktion" erwähnt wurde, ist jetzt als vollständige YAML-Engine in `workflows/speckit/workflow.yml` deployed. Das echte YAML: ```yaml schema_version: "1.0" workflow: id: "speckit" name: "Full SDD Cycle" steps: - id: specify → command: speckit.specify - id: review-spec → type: gate (approve/reject → abort) - id: plan → command: speckit.plan - id: review-plan → type: gate (approve/reject → abort) - id: tasks → command: speckit.tasks - id: implement → command: speckit.implement ``` **Aria-Relevanz**: Das ist exakt was Aria's /spec Skill macht — aber manuell. Das Workflow-YAML-Format könnte als Inspiration für einen Aria-eigenen `spec-workflow.yml` dienen, der die Phasen + Gates strukturiert als Datei abbildet (statt nur als SKILL.md-Text-Beschreibung). Besonders das **Gate-Konzept** (Kais muss explicit approve/reject geben, sonst abort) ist besser formuliert als der aktuelle "Ready für Phase 2 oder erst Clarifications?"-Prompt in Aria. **Adoption**: Das YAML-Format als Aria-Workflow-Definition übernehmen — nicht die CLI-Runtime, aber die Struktur. Aria könnte einen `spec-flow.yml` in jedem Feature-Folder anlegen, der den State der Gates tracked. ### 2.2 /speckit.clarify + /speckit.analyze — Kern-Commands bestätigt, aber NICHT im Lean-Preset Aus dem Extension-API-Reference sind `before_clarify`/`after_clarify` und `before_analyze`/`after_analyze` als Lifecycle-Events bestätigt. Die Commands existieren als Kern-Commands: - **`/speckit.clarify`** — Klärt `[NEEDS CLARIFICATION]`-Marker in der Spec durch strukturierten Dialog - **`/speckit.analyze`** — Cross-Artifact-Konsistenz-Validierung (spec.md ↔ plan.md ↔ tasks.md auf Widersprüche) **Kritischer Fund**: Aria's /spec Skill hat bereits den `[NEEDS CLARIFICATION: ...]`-Marker-Mechanismus aus dem ersten Audit extrahiert. Was fehlt: ein expliziter **`/clarify`-Phase** (zwischen Phase 1 und Phase 2) und ein **`/analyze`-Phase** (nach Phase 3, vor Kais-Approval für Implementation). **Adoption**: In Aria's /spec Skill eine optionale Phase 1.5 (`/clarify`) und Phase 3.5 (`/analyze`) einführen: - Phase 1.5 Clarify: Aria geht alle `[NEEDS CLARIFICATION]`-Marker durch, stellt Fragen, wartet auf Kais-Antworten, updated spec.md - Phase 3.5 Analyze: Aria checkt spec↔plan↔tasks auf Inkonsistenzen, reported Findings vor Implementation-Gate ### 2.3 Constitution in .specify/memory/ — persistenter Pfad (NICHT dokumentiert) Das erste Audit erfasste das Constitution-Konzept. Was neu ist: spec-kit speichert die Constitution in `.specify/memory/constitution.md` — ein **persistenter, von der CLI adressierbarer Pfad**. Jeder Workflow-Step lädt automatisch von diesem Pfad. Aria's /spec speichert Constitution als Brain-Note (`02-Wissen/kadi-v2-constitution.md`). Das ist gut für Aria. Aber bei Kadi-v2-Repo-Arbeit würde ein analoger `.specify/memory/constitution.md` im Repo-Root bedeuten, dass auch externe Contributor (Adesso) davon profitieren könnten. **Adoption**: Optional: `.specify/memory/constitution.md` als Symlink auf Brain-Constitution-Note oder als kopierte Version im Repo anlegen. KAR-Issue-würdig. ### 2.4 tasks-template.md: [P]-Parallelisierungs-Marker + Checkpoint-System Im re-gelesenen tasks-template.md sind **zwei Additions**, die in Aria's aktuellen templates fehlen könnten: 1. **`[P]`-Marker** für parallelisierbare Tasks: `- [ ] [T011][P] Component X` → kann parallel zu T012 laufen 2. **Checkpoint-Callouts**: nach jeder Phase ein expliziter Checkpoint: "Stop here and validate this phase works independently before proceeding" Aria's tasks-template hat `[depends T003]`-Annotation (aus dem ersten Audit), aber keinen `[P]`-Parallel-Marker. Das ist eine kleine aber wertvolle Addition für Multi-Session-Tasks. **Adoption**: tasks-template.md um `[P]`-Marker und Checkpoint-Sections ergänzen. ### 2.5 High-Assurance Spec Workflow (NEU, in docs/ seit 0.8.11) Eine neue Doku-Seite beschreibt einen "High-Assurance"-Modus mit: - Strengere Pre-Implementation-Gates - Peer-Review-Gates vor jedem Phasen-Übergang - Explizite SLA für Clarification-Runden (z.B. max 2 Runden vor Eskalation) Aria's /spec hat bereits Phase 0-3 mit Gates, aber keine SLA-Idee. Für Kadi-v2-Arbeit mit Adesso (Handover-Szenario) wäre ein High-Assurance-Modus (mehr Review-Gates) interessant. **Adoption**: Als optionales `--high-assurance`-Flag im /spec Skill dokumentieren. Niedrige Prio. ### 2.6 Extension-Katalog: 100+ Community Extensions (Kontext, nicht direkt adoptierbar) Der Community-Extension-Katalog ist von ~30 auf 100+ Extensions gewachsen. Relevant für Aria: - **Critique Extension** — Dual-Lens Review (Product-Strategy + Engineering-Risk) von spec und plan - **MemoryLint** — Prüft Konflikte zwischen Agent-Memory und Constitution - **speckit-utils / spec-validate** — Cross-Artifact-Traceability-Validierung - **Blueprint** — Pre-Implementation Code-Review vor /speckit.implement - **GitHub Issues Integration** — Bidirektionale spec-to-issue Synchronisierung **Für Aria** sind das keine Adoptionen als Software, aber wertvolle Prompt-Patterns: - Critique's "Dual-Lens" (Product + Engineering gleichzeitig) könnte als explizites Prompt in Phase 2 Plan-Review eingebaut werden - MemoryLint-Concept: in Phase 2 explizit prüfen ob Plan-Decisions mit SOUL.md/kadi-v2-constitution.md konfligieren --- ## 3. Konkrete Empfehlung ### Tier-1: Jetzt (< 1h Aufwand) **A) tasks-template.md: `[P]`-Marker und Phase-Checkpoints hinzufügen** Datei: `/root/.claude/skills/spec/templates/tasks-template.md` + Brain-Copy Konkret: Nach "Foundational"-Sektion einen "Checkpoint: Validate foundational tasks work independently"-Block. `[P]`-Marker-Konvention dokumentieren. **B) SKILL.md: Phase 1.5 Clarify + Phase 3.5 Analyze einführen** - Phase 1.5 (Clarify): Optional. Wenn spec.md >3 `[NEEDS CLARIFICATION]`-Marker hat: Aria löst diese durch Dialog auf, updated spec.md, dann weiter zu Phase 2. - Phase 3.5 (Analyze): Optional aber empfohlen. Aria liest spec.md + plan.md + tasks.md und reportet Inkonsistenzen (z.B. "Spec fordert Auth via JWT, Plan nennt keinen Auth-Layer"). ### Tier-2: Bei nächstem Kadi-v2-BIG-Feature **C) `.specify/memory/constitution.md` in Kadi-v2-Repo anlegen** Kopie oder Symlink von Brain-Constitution → Kadi-v2-Repo-Datei für externe Contributor. **D) Workflow-Gate-Syntax in Phase-Outputs** Aria's Phase-End-Messages von "Ready für Phase 2?" zu expliziterem Gate-Format: ``` [GATE] Phase 1 abgeschlossen. Approve → Phase 2 startet. Reject → Spec wird überarbeitet. Abort → Feature gestoppt. ``` ### Tier-3: Nice-to-have, keine Prio - High-Assurance-Modus-Dokumentation in SKILL.md - Critique Dual-Lens als Prompt-Erweiterung in Phase 2 --- ## 4. Aria-First Benefit Die primären Hebel für Aria's Distribution-Strategie (Aria wird als Produkt verkauft): 1. **Gate-Formulierung** (Tier-1-B): Bessere Gate-UX macht /spec-Skill für zukünftige Aria-User intuitiver — "approve/reject/abort" ist klarer als offene Fragen. 2. **Clarify-Phase**: Löst das "Speculation statt NEEDS CLARIFICATION"-Anti-Pattern systematisch auf. Direkte Verbesserung der Spec-Qualität bei Kadi-v2. 3. **Analyze-Phase**: Verhindert den Spec↔Plan↔Tasks-Drift der am 15.05.2026 zu 3 Hotfix-PRs führte. 4. **`[P]`-Marker**: Nützlich wenn Aria Multi-Session-Tasks an mehrere Subagenten delegiert (kommt mit Aria-Distribution). --- ## 5. Prompt-Injection / Security Scan Geprüfte Dateien: README.md, CHANGELOG.md, AGENTS.md, spec-driven.md, alle lean preset commands, EXTENSION-API-REFERENCE.md, EXTENSION-DEVELOPMENT-GUIDE.md, workflow.yml, extension.yml (git) **Befund:** - Keine "ignore prior instructions", "disregard above", "pretend you are", oder ähnliche Injection-Patterns in irgendeiner Datei - Template-Placeholders (`$ARGUMENTS`, `{{ inputs.variable }}`) sind Standard-Template-Syntax, kein Injection-Vektor - Community Extensions sind clearly labelled als "independently created and maintained, not endorsed by GitHub" — potenziell ungeprüfte Inhalte, aber nur bei aktivierter Extension-Nutzung relevant - CLI Python-Code (src/specify_cli/): keine direkte Analyse möglich ohne lokale Ausführung, aber GitHub-official + MIT, 105k Stars + aktive Maintenance → Trust-Level bleibt hoch - GitHub-Token-Nutzung (v0.8.2 feat: catalog download mit GITHUB_TOKEN/GH_TOKEN) ist opt-in für Catalog-Auth, kein obligatorischer Scope → **Clean.** Kein Injection-Risiko in adoptiertem Template-Material. --- ## 6. VERDICT **Hauptaussage: Aria hat 85% des Wertes bereits extrahiert. 3 konkrete Lücken rechtfertigen einen 45-Minuten-Update-Pass, kein größeres Refactor.** | Lücke | Wert | Aufwand | Empfehlung | |---|---|---|---| | Phase 1.5 Clarify + 3.5 Analyze | Hoch — verhindert den nächsten 3-Hotfix-PR-Fall | 20 min SKILL.md-Edit | TUN | | [P]-Marker + Checkpoints in tasks-template | Mittel — bessere Multi-Session-Klarheit | 10 min Template-Edit | TUN | | Gate-Formulierung approve/reject/abort | Mittel — bessere UX für Distribution | 5 min SKILL.md-Edit | TUN | | Workflow-Engine YAML-Format | Mittel — Konzept-Inspiration, nicht Adoption | 0 min (kein Code) | NOTIEREN | | .specify/memory/ Constitution-Pfad | Niedrig für jetzt | 10 min | BEI NÄCHSTEM KADI-FEATURE | | High-Assurance-Modus | Niedrig | — | BACKLOG | | 100+ Community Extensions | Info, kein direkter Wert | — | IGNORIEREN | Stars-Wachstum (+6.7k in 10 Tagen) und aktive Release-Cadence bestätigen: spec-kit ist Industry-Standard in der Entstehung. Weiter beobachten, aber keine weitere Re-Audit-Session nötig bis v0.9.0 oder bei Major-Feature-Announcement. **Confidence**: High