jardis/dev-skills — der Prozess für Jardis-Projekte

Version 1.7.1 · ein Composer-Plugin, das Skills, einen Prozess-Router AGENTS.md und Agent-Dateien für Prüfer in ein Jardis-Projekt installiert · fünf Bereiche auf dieser Seite: Prozess-Landkarte, Wissens-Kreislauf, Skill-Karte, Installationsbild, Werkzeug-Abdeckung

Festgelegt:
Mensch entscheidet Prüfer (unabhängig, frischer Kontext) Artefakt keine Rolle in dieser Phase Skill-Name

Prozess-Landkarte

Aufgabejede Anfrageprocess-choose-tier
0 AntwortFrage, Erklärung, Tippfehler
kein Prozess, direkte Antwort
1 Handgriffeine Sache, ein Ort, kein offener Entscheid
die Hauptsession macht es selbst · Hygiene: Doku aktualisieren, Tests für geänderte Logik, nur die Gates ausführen, die die Änderung berührt, Diff gegenlesen
2 Kleinauftraggroß, laut oder isoliert oder mehrere Teilaufgaben
ein Sub-Agent je Teilaufgabe · die Hauptsession führt die Aufgabenliste und prüft gegen Ground Truth, sie setzt nicht selbst um · Hygiene wie bei 1
3 Vorhabenoffener Entscheid, abhängige Schritte, neue Architektur, öffentliche API, Daten, Security
Stadien unten · im Zweifel die niedrigere Stufe · taucht ein Kriterium von Stufe 3 auf, entscheidet es für Stufe 3
▼
Phase
KonzeptStadium 0process-concept
PRDStadium 1process-write-prd
WAS-Gremiumam PRD · einmal je Vorhabenprocess-review-board
PlanStadium 2process-write-plan
WIE-Gremiumam Plan · einmal je Vorhabenprocess-review-board
Umsetzungje Etappe des Plansprocess-run-stage
Verifikationje Etappe des Plansprocess-verify
Abnahmenach der letzten Etappeprocess-verify
Abschlusseinmal je Vorhabenprocess-close
Mensch entscheidet
Interview: Antworten Punkt für Punkt · nimmt Verständnisblatt und Zielbild ab (ohne Ja kein nächstes Stadium)
bestätigt das PRD
Jeder Befund wird beschieden; jede Gabel geht an den Menschen, auch kleine
gibt den Plan frei
Jeder Befund wird beschieden; jede Gabel geht an den Menschen
Höchstens 2 Rückfrage-Punkte je Etappe · Commit und Merge sind Gates des Menschen
Sicht-Gate, wo eine Oberfläche gebaut wird: Zielbild neben Screenshot, blockiert immer
Nimmt ab: das Verdikt des Gates
Jeder offene Punkt erhält einen von vier Entscheiden · entscheidet über Prozessänderungen aus der Retro
Prüfer
Vor allem Neuen: was das Umfeld schon leistet
existing-capability-check
—
Skeptiker immer, weitere Rollen nur mit Grund (Domäne, DDD-Strategie, Frontend-UX) · blind, parallel · eine zusammengeführte Liste
—
Standard zwei Rollen: Architektur, Teststrategie · Packages nur bei neuen Package-APIs · weitere nur mit Grund
Code-Review je Phase (code-review-change) · Rückfrage-Gate · Fehlerdiagnose
Verifier der Etappe, blind, einmal je Etappe, Umsetzer ≠ Prüfer · QA-Gates einmal je Etappe durch die Hauptsession
Akzeptanz-Gate, Ende-zu-Ende gegen das ganze PRD, einmal
—
Artefakt
UNDERSTANDING.md · KONZEPT.html (+ KONZEPT.png bei der Abnahme) · PROGRESS.md mit Kopf: Phase, Stage, Next step, Open decisions
PRD.md ergänzt Blatt und Bild um einen Lösungsteil, Fehlerfälle, Zustände, Grenzen, Datenpfade und nummerierte Entscheide
Eine Befundliste, jeder Befund gelöst oder verworfen
PLAN.md: Etappen → Phasen; je Etappe erzeugt, von Hand, fertig wenn, Halt; Datei-Scope, Akzeptanzkriterien je Phase
Befunde in den Plan eingearbeitet
Ein Brief je Phase (≤ 6 KB, ≤ 8 Zusagen, ≤ 30 KB Kontextlast) · ein Commit je Phase
Verdikt GREEN oder RED (≤ 5 Posten, ≤ 3 Rot-Belege) · Screenshot · Merge
Je Kriterium MET oder GAP · Verdikt GREEN oder RED
Digest docs/digests/… · Ordner archiviert · einmalige Auslieferung
Etappen-Schleife
Je Phase: Brief → Umsetzer (frische Session) → Commit. Je Etappe: Verifier → QA-Gates → Sicht-Gate → Kopf aktualisieren → Merge. Nach RED: ein Fix-Lauf und ein Nachlauf des Verifiers, dann STOPP: im Kopf der Fortschrittsdatei.
Fehlerpfad
A erholbar → ein frischer Wiederholungslauf · B beantwortbare Frage → Rückfrage-Gate (open-question-gate; die Antwort wird aus PRD, Zielbild, Verfassung und Code hergeleitet) · Diagnose durch failure-diagnosis · nie delegiert: destruktive Operationen, Änderungen an der öffentlichen API, Scope über das PRD hinaus, Veröffentlichung, Kosten, Dritte
Wissen
knowledge-* · vor einem Format-, Architektur- oder Emissions-Entscheid den Pool lesen · jeder Commit mit feat: oder fix: trägt eine Vermerkzeile Wissen:
Wiederanlauf
process-resume · eine frische Session findet die aktive PROGRESS.md (höchstens 60 Zeilen, nur die Hauptsession schreibt sie), beachtet STOPP:, führt den Preflight aus und nimmt genau einen nächsten Schritt auf · jede Etappe läuft in einer frischen Agent-Session
Rollen
Hauptsession = Orchestrator: schreibt Briefe, beobachtet, prüft gegen Ground Truth, baut nichts · Umsetzer = Sub-Agent je Phase, schreibt keine Fortschrittsdatei und keinen Git-Befehl, der den Zustand ändert · Prüfer = eigener Sub-Agent, der nur das Ziel-Artefakt, die Akzeptanzkriterien und den Code sieht · ohne Sub-Agenten: ein frischer Headless-Lauf je Rolle (claude -p, codex exec, agent -p, copilot -p, gemini -p)

Quelle: der Prozess-Router in AGENTS.md und die Skills process-choose-tier, process-concept, process-write-prd, process-write-plan, process-review-board, process-run-stage, process-verify, process-close, process-resume.

Wissens-Kreislauf

R lesen W schreiben G Git-Hook oder Prüfung D Rechenschaft (docs/)
Drei Schichten: Schicht 1 Chat (Rohmaterial, nie die Quelle der Wahrheit) → Schicht 2 Projekt-Arbeitsunterlagen docs/vorhaben/<name>/ → Schicht 3 Wissen .claude/wissen/. Die Richtung ist fest: Chat, dann Projekt-Arbeitsunterlagen, dann Wissen.

WO · Wissenspool (Warum und Fallen)

.claude/wissen/INDEX.md ist der Einstieg · je Thema eine Seite .claude/wissen/<topic>.md
StandEntscheideFallenErsetztVerweise
verdichtet, nicht angehängt · ein Entscheid trägt Datum, Urheber und Quelle · Themenseite ≤ 16.384 Bytes und 160 Zeilen, Index < 10.240 Bytes

WO · Rechenschaft

docs/vorhaben/<name>/ enthält PROGRESS, UNDERSTANDING, KONZEPT, PRD, PLAN
→ beim Abschluss: docs/digests/digest-<name>-<yyyy-mm>.md, der Ordner wird vor der Auslieferung archiviert (nach tmp/archiv/ verschoben)

WO · Skills (Was)

.claude/skills und .agents/skills kommen über Composer. Das Plugin schreibt die Skills und nie den Pool; das Pool-Gerüst legt der Agent über process-concept an.

IM REPO?

committed (Standard): alles bleibt dem Commit überlassen
local (Schalter process-docs): der Exclude-Block in .git/info/exclude enthält zusätzlich .claude/wissen/, docs/vorhaben/ und docs/digests/; .gitignore bleibt unberührt
A · Projektstartnoch kein Pool, erstes Vorhaben
WGerüst: leere INDEX.md, nur wenn .claude/wissen/ fehlt.claude/wissen/INDEX.md
WInterview: jeder geklärte Punkt gehört ins Konzept-Artefakt, nicht in eine Chat-ZusammenfassungUNDERSTANDING.md · KONZEPT.html
DPRD, Plan und Fortschrittsdatei als Rechenschaftdocs/vorhaben/<name>/
RDer Brief nennt die Themenseiten des Pools, die den Bereich berühren, ausgewählt aus INDEX.mdINDEX.md → Themenseiten
WGEin Entscheid wird eine Zeile unter Entscheide; der feat:-Commit trägt den VermerkWissen: <page>#<section>
RDer Verifier erhält die Themenseiten, die die Briefe genannt haben
WDAbschluss: Sichtung · Lehren in den Pool · Digest · Ordner archiviert · Auslieferungdocs/digests/
Pool und docs committed · Modus local: alles unter dem Exclude-Block, auch der Digest
B · FeatureHandgriff oder Vorhaben
RVor einem Format-, Architektur- oder Emissions-Entscheid die zuständige Themenseite lesenINDEX.md → <topic>.md
Wfeat: erweitert Stand oder Entscheide; ein ersetzter Fakt wandert nach Ersetzt
WEine Themenseite, der die Änderung widerspricht, wird im selben Commit korrigiert
Gcommit-msg-Hook: ein Commit mit feat: oder fix: ohne den Vermerk erzeugt eine Warnung, der Commit geht durchWissen: <page>#<section> | Wissen: keins – <reason>
GPool-Prüfung: Abschnitte, Links, Pfadverweise und Größen-Deckelpool-check.php
Der Vermerk steht in der Git-Historie · Themenseiten committed oder local
C · Bugfixmit oder ohne Vorhaben
WFix und ein Test für die geänderte Logik
WPool-Eintrag nur wenn alle vier Kriterien zutreffen: nicht offensichtlich aus dem Code · Regression · Falle · Pool falsch oder unvollständig
W2 bis 4 Zeilen unter Fallen: Symptom, Ursache, Regel, Quelle<topic>.md#Fallen
Gfix: trägt Wissen: <page>#fallen oder Wissen: keins – <reason>
WEine falsche Themenseite wird im selben Commit korrigiert
wie B
Prüfungen
G pool-check.php liest nur; Exit-Code 0 sauber, 1 Verstöße, 2 Aufruffehler oder kein Pool · der Hook commit-msg warnt nur und endet immer mit Exit-Code 0 · check-commit-messages <from>..<to> führt dieselbe Prüfung über einen Commit-Bereich aus, zum Beispiel in der CI · install-commit-msg-hook schreibt den Hook, git-setup-repository führt ihn aus

Was das Package für den Kreislauf bereitstellt

Pool-Verweis im Router — der verwaltete Block in AGENTS.md trägt die Zeile „Wissenspool: .claude/wissen/INDEX.md — vor Entscheiden lesen, Vermerk-Pflicht“, damit eine Session den Pool ohne private Einstellung findet.
Mit dem Package gelieferte Werkzeuge — der commit-msg-Hook, sein Installer install-commit-msg-hook und die Pool-Prüfung pool-check.php kommen mit jardis/dev-skills unter scripts/.
Gerüst beim ersten Vorhaben — process-concept kopiert nur INDEX.md nach .claude/wissen/, und nur wenn der Ordner fehlt; ein vorhandener Pool wird nie geändert.
Angebot am Ende eines Chats — ein Chat, der mehr als eine Antwort erzeugt hat, endet mit zwei Angeboten: einen Projektordner (docs/vorhaben/<name>/) anlegen und Wissen in den Pool übernehmen. Die Regel steht in process-choose-tier; ohne ein Ja wird nichts angelegt.
PROGRESS.md mit festem Kopf — ## Kopf ist die erste Überschrift, mit vier Zeilen in dieser Reihenfolge: Phase, Stage, Next step, Open decisions. Danach können fünf freiwillige Zeilen folgen: Title, Type, Ticket, BC, Skipped.
Frische Session je Etappe — jede Etappe und jede Umsetzer-Session darin läuft in einer frischen Agent-Session; der Kopf der Fortschrittsdatei und der Brief sind die einzige Übergabe. Die Regel steht in process-run-stage.

Quelle: die Skills knowledge-maintain-pool, knowledge-record-decision, process-concept, process-close, process-run-stage und die Skripte unter scripts/.

Skill-Karte

Namensschema: <area>-<what-it-does> · Englisch · kebab-case
Der Bereich sagt, wo im Lebenszyklus ein Skill verwendet wird: start, packages, process, knowledge, git, design, generated-code, foundation; der Review-Skill trägt code-review. Skills der Jardis-Packages (adapter-*, core-*, support-*, tools-*) gehören zu diesen Packages und kommen zusätzlich dazu.

start · packages Einstieg

start-orientation
Einstieg: führt durch die Phasen des Lebenszyklus und verweist auf jeden anderen Skill
packages-find-existing
Vor dem Handbau einer wiederverwendbaren Komponente prüfen, welches Jardis-Package sie schon liefert, dann composer require

process immer installiert · Stufenwahl, Stadien 0 bis 4, Review

process-choose-tier
Entscheiden, wie viel Prozess eine Aufgabe braucht: Antwort, Handgriff, Kleinauftrag oder Vorhaben
process-check-existing
Vor etwas Neuem fragen, was das Umfeld schon leistet, über einen blinden Prüfer
process-concept
Stadium 0: Konzept-Interview, Verständnisblatt, abgenommenes Zielbild, Projektordner mit Fortschrittsdatei
process-write-prd
Stadium 1: das PRD ergänzt einen Lösungsteil, Fehlerfälle, Zustände, Grenzen, Datenpfade und nummerierte Entscheide; WAS-Gremium einmal
process-write-plan
Stadium 2: in Etappen und Phasen schneiden, mit Datei-Scope, Akzeptanzkriterien und den Zeilen erzeugt, von Hand, fertig wenn und Halt; WIE-Gremium einmal
process-review-board
Rollen mit Grund wählen, blind ausführen, eine Liste zusammenführen, jeden Befund bescheiden
process-run-stage
Ein Brief je Phase, ein frischer Umsetzer, Commit, blinde Verifikation, QA-Gates, Merge
process-verify
Ein blinder Verifier je Etappe und am Ende ein Ende-zu-Ende-Akzeptanz-Gate
process-close
Offene Punkte sichten, Lehren in den Pool übernehmen, den Digest schreiben, einmal ausliefern, danach den Ordner löschen
process-resume
Ein laufendes Vorhaben in einer frischen Session anhand seiner Fortschrittsdatei fortsetzen
code-review-change
Nach jeder Codieraufgabe und vor jedem Commit: Befunde nach Blocker, Major oder Minor eingestuft, ändert nie Code

knowledge Entscheid-Pool

knowledge-maintain-pool
Aufbau, Größen-Deckel und Pflege des Pools unter .claude/wissen/; die Pool-Prüfung
knowledge-record-decision
Einen Entscheid oder eine Bugfix-Lehre mit Datum, Urheber und Quelle festhalten; der Vermerk Wissen: an Commits mit feat: und fix:

git Gitflow

git-setup-repository
Einmalige Gitflow-Einrichtung: develop-Branch, Repository-Einstellungen, Branch-Ruleset, Git-Hooks
git-start-branch
Einen Gitflow-Branch anlegen, mit Issue-Nummer und Typ-Erkennung
git-commit-change
Conventional Commit aus den aktuellen Änderungen, nach dem Review
git-push-and-open-pr
Pushen mit dem Quality-Gate und einen Pull Request öffnen
git-check-compliance
Prüfen, ob das Repository den Gitflow-Konventionen folgt

design vor dem generierten Code · Profil jardis

design-draft-schema
Den Inhalt einer Schema.json für den Designer aus einer Domänenidee in Klartext entwerfen
design-headless-mcp
Einen Jardis-Workspace ohne Browser über jardis mcp steuern: Tools, Resources, Fehler-Envelopes

generated-code nach dem Designer · Profil jardis

generated-code-extend
Generierten Code erweitern: der hermetische, dem Generator gehörende Baum, die Entwickler-Oberfläche, die Verbote
generated-code-wire-transport
Generierte Queries und Prozesse in HTTP-, CLI-, Queue- oder Worker-Code einbinden
generated-code-versioning
ClassVersion-Auflösung und das Versionierungs-Modell
generated-code-workflow-api
Workflow-Engine-API hinter den generierten Prozess-Orchestratoren
generated-code-recipes
Rezepte und Fehlersuche für generierten Code

foundation Standards, übergreifend · immer installiert

foundation-architecture
Fünf Säulen, hexagonale Abhängigkeitsrichtung, Closure-Orchestrator-Muster
foundation-patterns
Katalog der zehn in Jardis verwendeten Entwurfsmuster
foundation-testing
Integration vor Unit, Mocks nur an Ports, ein fester Ablauf für fehlschlagende Tests
foundation-frontend-review
Stack-unabhängige Review-Regeln für das Frontend
foundation-php
PHP-8.3-Referenz: strict types, PHPStan Level 8, PSR-4, keine Traits
foundation-working-principles
Erst der Skill, dann der Quellcode, dann nachfragen; Werte prüfen, statt zu raten

Ketten prerequisites / next aus dem Skill-Frontmatter

Vorhaben: process-choose-tier → process-concept → process-write-prd → process-write-plan → process-run-stage → process-verify → process-close → knowledge-record-decision
Andere Ketten: git-start-branch → git-commit-change → git-push-and-open-pr · design-draft-schema → generated-code-extend → generated-code-* · foundation-working-principles → knowledge-maintain-pool → knowledge-record-decision · code-review-change → git-commit-change

Prüfer-Rollen (Sub-Agent-Definitionen in process-review-board/reviewers/)

RolleVerwendet vonGewählt, wenn
prd-review-skepticWAS-Gremiumimmer
prd-review-domain-expertWAS-Gremiumdas PRD eine Domäne modelliert oder ein Domänen-Entscheid offen ist
prd-review-ddd-strategyWAS-GremiumKontexte, Domänensprache oder eine öffentliche API geschnitten oder geändert werden
prd-review-frontend-uxWAS-Gremiumdas PRD eine Benutzeroberfläche hat
plan-review-architectureWIE-GremiumStandard
plan-review-test-strategyWIE-GremiumStandard
plan-review-packagesWIE-Gremiumder Plan neue Package-APIs berührt
plan-review-ddd-tacticsWIE-Gremiumder Plan Aggregate, Value Objects oder Repositories schneidet
plan-review-phpWIE-Gremiumder Plan überwiegend aus PHP-Code besteht und Fehlerbehandlung und Randfälle zählen
plan-review-frontend-architectureWIE-Gremiumder Plan eine Benutzeroberfläche hat
plan-review-frontend-testsWIE-Gremiumder Plan eine Benutzeroberfläche hat
plan-review-frontend-a11yWIE-Gremiumeine Phase eine Benutzeroberfläche erzeugt, die Menschen bedienen
plan-review-frontend-typesWIE-Gremiumeine Phase Typen oder den Datenfluss im Frontend berührt
plan-review-frontend-uxWIE-Gremiumder Plan Zustände und Interaktionen der Benutzeroberfläche ausführt
stage-verifierprocess-verifyeinmal je Etappe
acceptance-gateprocess-verifyeinmal je Vorhaben, nach der letzten Etappe
existing-capability-checkprocess-check-existingbevor etwas Neues eingeführt wird
open-question-gateprocess-run-stagebevor eine Frage den Menschen erreicht
failure-diagnosisprocess-run-stagenach RED, wenn der Bericht die Ursache nicht erklärt

Quelle: das Frontmatter der 33 Skills unter skills/ und docs/SKILL-FORMAT.md (Bereichs-Präfixe).

Installationsbild in einem Jardis-Projekt

# composer require --dev jardis/dev-skills  →  post-install / post-update
your-project/
├── AGENTS.md                         verwalteter Block BEGIN/END jardis/dev-skills
│     Prozess-Router: Stufen · Phase → Skill · Prüfer-Rollen · Verweis auf den Pool
│     + zusammengeführte AGENTS.md der Jardis-Vendor-Packages   Warnung über 32.768 Bytes (Codex)
├── CLAUDE.md                         verwalteter Block: importiert @AGENTS.md
├── .claude/
│   ├── skills/<name>/SKILL.md          33 mitgelieferte Skills (25 im Profil core) + Vendor-Skills · Claude Code, Copilot
│   ├── skills/.jardis-managed.json     Manifest: jeder Skill-Ordner, den das Plugin installiert hat
│   ├── agents/<role>.md                Prüfer-Agent-Dateien (Claude Code)
│   └── .jardis-backup/                 Kopien von Ordnern, die vom verwalteten Zustand abwichen
├── .agents/skills/<name>/SKILL.md     dieselben Skills für Codex, Cursor, Copilot, Gemini CLI
├── .codex/agents/<role>.toml          Prüfer-Agent-Dateien (Codex)
├── .cursor/agents/<role>.md           Prüfer-Agent-Dateien (Cursor)
├── .github/agents/<role>.agent.md     Prüfer-Agent-Dateien (Copilot)
├── .gemini/agents/<role>.md           Prüfer-Agent-Dateien (Gemini CLI)
├── .gemini/settings.json             context.fileName führt AGENTS.md auf
└── .git/info/exclude                 verwalteter Block: immer .claude/.jardis-backup/; Modus local ergänzt

# später vom Prozess angelegt, nicht von der Installation
├── .claude/wissen/                    Wissenspool · INDEX.md + Themenseiten · Gerüst durch process-concept
├── .claude/PROJECT_PROFILE.md          Projektfakten: QA-Einstieg, Ports, Build · durch process-concept
├── docs/vorhaben/<name>/             PROGRESS.md · UNDERSTANDING.md · KONZEPT.html/.png · PRD.md · PLAN.md · Briefe
├── docs/digests/digest-<name>-<yyyy-mm>.md
└── commit-msg-Hook                    geschrieben von scripts/install-commit-msg-hook, warnt nur

Prüfer: eine Definition, dünne Dateien je Werkzeug

SchichtInhalt
Quelle (einmal)Der Rollentext in process-review-board/reviewers/<role>.md. Er wird mit dem Skill nach .claude/skills und .agents/skills kopiert.
Datei je WerkzeugEine Agent-Datei je Rolle und Werkzeug, vom Plugin geschrieben. Eine Datei, die das Plugin nicht geschrieben hat, wird nie überschrieben; das Plugin lässt sie stehen und warnt.
Ohne Sub-AgentenDer Skill nennt den Ersatzweg: ein frischer Headless-Lauf je Rolle mit einem reinen Review-Auftrag.

Konfiguration composer.json

"extra": { "jardis/dev-skills": {
    "bundled-skills": true,
    // standardmäßig die Skills des Profils (33 bei jardis, 25 bei core); eine Liste oder include/exclude schränkt ein
    // foundation-* und process-* werden immer installiert
    "git-rules": true,
    // "delegated": die Session committet selbst, Merge und Push bleiben beim Menschen; false entfernt die Git-Sätze aus dem Router
    "process-docs": "committed"
    // oder "local": Einträge in .git/info/exclude
} }

Was das Plugin für welches Werkzeug schreibt

WerkzeugSkillsRouterAgent-Dateien
Claude Code.claude/skillsAGENTS.md über CLAUDE.md.claude/agents
Codex.agents/skillsAGENTS.md.codex/agents
Cursor.agents/skillsAGENTS.md.cursor/agents
GitHub Copilot.agents/skills, .claude/skillsAGENTS.md.github/agents
Gemini CLI.agents/skillsAGENTS.md über .gemini/settings.json.gemini/agents

Quelle: README-Abschnitte Installation, Supported tools und Reviewer agent files.

Werkzeug-Abdeckung

Prozess-BausteinClaude CodeCodex CLI/IDECursorGitHub CopilotGemini CLIErsatzweg, wo ◐ / ✘ / ?
Router (AGENTS.md) wird gelesen✔✔✔✔◐Gemini CLI: context.fileName in settings.json auf AGENTS.md gesetzt
Phasen-Skills (SKILL.md) werden geladen✔✔✔✔✔Gemini CLI: lädt einen Skill über das Werkzeug activate_skill und fragt vorher nach einer Bestätigung
Unabhängiger Prüfer (Sub-Agent, frischer Kontext)✔✔✔✔✔
Modell je Prüfer✔✔✔✔✔
Gremium aus Prüfern parallel✔✔✔✔?Gemini CLI: vom Hersteller nicht belegt
Fortschritts- und Aufgabenliste◐???✔Claude Code: bei Modellen, die die Dokumentation nicht nennt, mit CLAUDE_CODE_ENABLE_TODO_TOOLS=1 einschalten · Codex, Cursor, Copilot: vom Hersteller nicht belegt
Plan-Modus ohne Schreibzugriff◐◐◐◐✔Claude Code: Änderungen bleiben gesperrt, bis der Plan abgenommen ist, außer in interaktiven Terminal-Sessions, in denen Bypass-Berechtigungen verfügbar sind · Codex, Cursor: ein Plan vor der Umsetzung, keine Schreibsperre angegeben · Copilot: in Visual Studio nicht verfügbar
Headless-Lauf✔✔✔✔✔claude -p · codex exec · agent -p · copilot -p · gemini -p
MCP (jardis mcp)✔✔✔✔✔
commit-msg-Hook mit dem Vermerk Wissen:✔✔✔✔✔ein Git-Hook, unabhängig vom Werkzeug; er warnt und weist einen Commit nie zurück
Garantiestufegetestet
Claude Code 2.1.286
aus Doku belegt, nicht getestetaus Doku belegt, nicht getestetaus Doku belegt, nicht getestetaus Doku belegt, nicht getestetgetestet: der Prozess wurde mit dem Werkzeug ausgeführt und jede aufgeführte Prüfung bestand · aus Doku belegt, nicht getestet: die Herstellerdokumentation sagt, dass das Werkzeug den Baustein bietet
Nicht abgedeckt
Aider und Continue werden nicht bedient. Codex Cloud und der Copilot-Cloud-Agent liegen außerhalb der Garantie, auch für die oben genannten Werkzeuge.

✔ ohne Einschränkung belegt · ◐ mit Einschränkung belegt · ✘ die Dokumentation verneint es · ? in der Herstellerdokumentation nicht gefunden. Quelle: Herstellerdokumentation, abgerufen am 2026-10-01; was das Plugin für jedes Werkzeug schreibt, steht im README-Abschnitt Supported tools.