decision-path — ASCII-Abhängigkeitsgraph ausstehender Entscheidungen
Entscheidungen finden nicht im luftleeren Raum statt. Was isoliert betrachtet sinnvoll erscheint, blockiert häufig nachfolgende Arbeit, setzt nicht gebaute Voraussetzungen voraus oder umgeht etablierte Sicherheitstore. decision-path macht Kausalitäten, Ausführungsreihenfolgen und Widersprüche transparent im Terminal.
Wann verwenden
- Ein vorhandenes Inventar offener Entscheidungen (aus decision-briefing Phase 1, einem Sitzungskontext oder einem Ticket-Master-Entscheidungsbriefing) muss strukturiert werden.
- Sie müssen identifizieren, welche Entscheidungen sofort umgesetzt werden können (Wurzelknoten) und welche von Voraussetzungen oder externen Blockaden abhängen.
- Sie benötigen einen Überblick darüber, welche Empfehlungen harmonisch zusammenpassen und wo zwei Empfehlungen logisch oder operativ kollidieren.
- Auslösewörter:
/decision-path, „welche Entscheidungen hängen voneinander ab“, „Entscheidungsabhängigkeitsgraph“, „Entscheidungspfad visualisieren“, „ASCII-Entscheidungsbaum“, „Widersprüche zwischen Entscheidungen“, „kausale Abhängigkeiten prüfen“. - Nicht verwenden:
- Um offene Fragen erstmals zu entdecken und zu inventarisieren – das erledigt decision-briefing Phase 1.
- Um empfohlene Entscheidungen zu einem kohärenten Gesamtkonzept für die Freigabe zu bündeln – das erledigt decision-draw.
- Für kompakte Fünf-Teile-Blöcke mit Optionen und Pro/Kontra pro Option – das erledigt decision-shot.
- Um eine einzelne komplexe Entscheidung methodisch mit Frameworks zu bewerten (gewichtete Bewertung, Szenarioanalyse) – das erledigt decide.
Abgrenzungen in der Entscheidungsfamilie
| Skill | Rolle | Eingabe | Ausgabe |
|---|---|---|---|
decide | Methodische Strukturierung einer einzelnen Entscheidung | Kriterien, Optionen | Bewertungsmatrix, Einzelentscheidung |
decision-briefing | Zerlegt viele offene Entscheidungen in einzelne Fragen mit Optionen | Liste offener Punkte | Nummeriertes A/B/C/D-Briefing, grobe Abhängigkeitsmarkierungen, Stapelbuchung |
decision-path | Validiert und visualisiert Kausalitäten und Widersprüche über viele Entscheidungen hinweg | Grobe Markierungen aus Briefing / Register | ASCII-Abhängigkeitsgraph mit 5 Knotenbewertungen und Kantenstatus |
decision-draw | Bündelt Empfehlungen zu einem kohärenten Ganzen für die Freigabe | Bündel aus decision-path | Konzept, Zusammenspiel (nur empfohlene Variante), Rückübertragung |
decision-shot | Komprimiert abgeschlossene Analysen auf ihr wesentliches Exekutiv-Essenz (1 Entscheidung oder enges Bündel) | 1 analysierte Frage oder Gruppe | Fünfteilige Kurzform mit Optionen, Pro/Kontra und Link zur vollständigen Analyse |
decision-avatar | Modelliert Benutzerpräferenzen und Verhaltenshistorie | Kontext, vergangene Entscheidungen | Konfidenzbewertung 🟢 / 🟡 / 🔴 |
Vertrag und Verantwortung gegenüber decision-briefing
decision-briefing Phase 1 leitet bereits grobe Abhängigkeiten und Ausführungsreihenfolgen während der Erfassung ab (z. B. aus Signalen wie „Danach automatisch:“, Blockaden oder Ticket-Referenzen). decision-path dupliziert diese Ableitung nicht, sondern baut direkt auf diesen groben Markierungen auf:
- decision-briefing liefert grobe Markierungen: Es liefert das rohe Inventar ausstehender Punkte und erste Kopplungshinweise.
- decision-path validiert, bewertet und visualisiert: Es überprüft Signale anhand dokumentierter Fakten, trennt bestätigte von vermuteten Kanten, weist die fünf Bewertungen pro Knoten zu und deckt Gate-Kollisionen auf.
- Rückkopplungsschleife bei Abweichungen: Wenn
decision-patheine im Briefing fehlende oder falsch dargestellte Abhängigkeit entdeckt, übernimmt es diese nie stillschweigend, sondern meldet sie explizit als Korrekturvermerk an das Briefing zurück.
Die fünf Bewertungen pro Knoten (und Kantenverifikationsstatus)
Die fünf Dimensionen [S E U Z W] bewerten die Knoten (ausstehende oder getroffene Entscheidungen in ihrem systemischen Kontext). Kanten tragen ihren semantischen Beziehungstyp (z. B. freischaltend, blockierend, Voraussetzung) und Verifikationsstatus (bestätigt vs. vermutet).
Jeder Knoten im Graphen zeigt eine kompakte Fünf-Elemente-Bewertungszeichenfolge:
[S+ E:<Option> U<Direction><Confidence> Z+ W-]
-
Sinnvoll (
S) — Technische und architektonische Solidität:S+: Lösung ist robust, adressiert ein echtes Problem, vermeidet künstliche Komplexität.S~: Teilweise solide, aber mit Wartungs- oder Betriebsaufwand verbunden.S-: Falsche Lösung, kosmetischer Aktivismus oder eine nachgewiesene Sackgasse (z. B. Filterung am falschen Hebel).
-
Empfohlen (
E) — Konkrete, evidenzbasierte empfohlene Aktion:E:<Option>: Klare Wahl (z. B.E:A,E:B,E:resolve,E:Step1).E-: Keine handlungsleitende Empfehlung möglich (fehlende Fakten oder grundsatzpolitische Frage).
-
Benutzerüblich (
U) — Übereinstimmung mit den bisherigen Gewohnheiten und kodifizierten Regeln des Benutzers (überdecision-avatar): Codiert Richtung (passt die Option zu den Gewohnheiten?) und Verifikationskonfidenz getrennt:- Richtung (erstes Zeichen nach U):
+: Benutzerüblich – entspricht vergangenen Entscheidungen, Richtlinien (CLAUDE.md) oder expliziten Präferenzen.~: Neutral / offen – keine dominante historische Präferenz dokumentiert.-: Unüblich – weicht vom üblichen Workflow oder etablierten Gewohnheiten ab.
- Verifikationskonfidenz (zweites Zeichen):
- Reines ASCII innerhalb des ASCII-Graphen:
!: Hoch / belegt (im Prosa: 🟢 dokumentiert).~: Mittel / plausibel (im Prosa: 🟡 Abwägung liegt grundsätzlich beim Benutzer).?: Niedrig / unverifiziert (im Prosa: 🔴 Grundsatzfrage, beispiellos). Eskalieren statt raten!
- Reines ASCII innerhalb des ASCII-Graphen:
- Beispiele:
U+!(üblich und dokumentiert),U+~(üblich, aber Benutzerentscheidung),U-!(dokumentiert unüblich),U~?(offen, kein Präzedenzfall -> eskalieren).
- Richtung (erstes Zeichen nach U):
-
Kohärent (
Z) — Weiche architektonische und stilistische Harmonie mit benachbarten Knoten:Z+: Fügt sich nahtlos in Vorläufer und nachgelagerte Entscheidungen ein; bildet ein stimmiges Ganzes ohne Reibung.Z~: Geringfügige stilistische Reibung oder betrieblicher Aufwand, aber funktional tragfähig.Z-: Spürbare Reibung im systemischen Zusammenspiel (z. B. Konfigurationswildwuchs, umständliche Kopplung), verletzt aber keine harte Regel.
-
Widersprüchlich (
W) — Harter Widerspruch und Policy-/Gate-Verstoß (kritischste Ausgabe – Alarm!):W-: Frei von Widersprüchen gegen andere Empfehlungen, Richtlinien und aktive Sicherheitstore.W+: Harte Kollision / Alarm! Entkräftet eine andere Empfehlung, verletzt eine etablierte Richtlinie (CLAUDE.md, P-00x) oder umgeht ein aktives Sicherheitstor. Kollidierende Knoten werden immer explizit im AbschnittCONTRADICTIONSmit Ursache und Lösungsweg hervorgehoben.
Kantentypen und Ableitungsregeln
Abhängigkeiten werden streng aus dem Quelltext abgeleitet, niemals erfunden. Kanten tragen ihren Beziehungstyp und Verifikationsstatus:
| Signal in der Quelle | Kantentyp | Notation | Bedeutung |
|---|---|---|---|
| „Danach automatisch: …“, „schaltet frei“, „ermöglicht“ | Schaltet frei | +--> | Zielentscheidung wird erst nach Quellentscheidung handlungsrelevant (dokumentiert) |
| „blockiert“, „verhindert“, „Sicherheitstor löst aus“ | Blockiert | => | Ziel ist blockiert, bis die Quelle gelöst ist |
| „erfordert“, „benötigt vorher“, „Voraussetzung“ | Erfordert | --> | Ziel logisch und zeitlich abhängig von Quelle |
| „Folgeentscheidung“, „Schritt 2 danach“ | Sequenz | --> | Nachgelagerte logische Progression nach Ausführung |
| „widerlegt durch Messung“, „veraltet“, „abgelöst“ | Entkräftet | --X--> | Quelleneinsicht macht Ziel obsolet |
| Geteilte D-ID, Ticket-ID oder gleiches Subsystem ohne Textbeleg | Vermutet | ?--> | Plausible Kopplung ohne dokumentierten kausalen Beleg (unverifiziert) |
Regel für unverifizierte Kanten: Wenn keine explizite kausale Aussage im Text existiert, muss die Kante als vermutet (
?-->) markiert werden – niemals als bestätigte Tatsache. Wo keine Beziehung dokumentiert ist, bleiben Knoten unverbunden nebeneinander stehen.
Formatrichtlinien für den ASCII-Graphen
- Monospace & Terminaloptimiert: Maximale Zeilenbreite 100 Spalten. Keine breiten Tabellen, die umbrechen und das Terminal-Layout stören.
- Zeichensatz & Reinheit: Reines ASCII. Innerhalb des Graph-Codeblocks dürfen keine Emojis (🟢🟡🔴) erscheinen; Konfidenz wird ausschließlich durch ASCII-Markierungen (
!,~,?) dargestellt. - Knoten-IDs: Nur existierende Identifikatoren (
PD-A,MD-A,BH-A,VM-A,QR-A,CL-A,MO-A,D-001,732597768). Niemals synthetische IDs erfinden! Wenn ein Element keine Abkürzung hat, wird seine Artikelnummer verwendet. Nachfolgende interne Schritte werden als unnummerierte Kantenanmerkungen(...)dargestellt. - Geschichtete Struktur:
LEVEL 0 - unabhängig: Wurzelknoten, nicht blockierte Elemente, externe Auslöser.LEVEL 1 - hängt von genau einem ab: Direkte Nachfolger.LEVEL 2 - hängt von mehreren / tiefer Kette ab: Mehrfachabhängigkeit oder tiefe sequentielle Knoten.WIDERSPRÜCHE: Harte Kollisionen, Gate-Verstöße und widersprüchliche Empfehlungen (W+).LEGENDE: Obligatorisch in jeder Graphausgabe. Jedes im Graphen verwendete Strukturzeichen (|,=Option,(...), Kantenpfeile) muss in der Legende aufgelistet und erklärt werden.
- Optionaler Mermaid-Block: Ein zusätzlicher
mermaid-Codeblock kann angehängt werden, wenn nützlich; der ASCII-Graph bleibt die primäre, maßgebliche Ausgabe.
Beispiel (Pilot-Datensatz: Ticket-Master 2026-09-13)
Realer Auszug aus dem Ticket-Master-Entscheidungsbriefing (732597768, MO-A, CL-A, QR-A, 387521104, CL-B):
====================================================================================================
DECISION-PATH: DEPENDENCY GRAPH (Pilot Ticket-Master 2026-09-13)
====================================================================================================
LEVEL 0 - independent (Root decisions & external blockers)
[732597768] Resolve GitHub billing issue [S+ E:resolve U+! Z+ W-]
| unlocks
+--> [MO-A] Release Wave 2 [S+ E:A U+~ Z+ W-]
[CL-A] clutch admin merge PR #6 & PR #8 [S+ E:A U+! Z+ W-]
| blocked by: [Gate "1 Approving Review" (self-approval impossible)]
--> (follow-up decision: set branch protection to 0 or bot)
[QR-A] Queue rename NTFS junction (_TICKETS -> TICKETS) [S+ E:B U+! Z+ W-]
+--> [387521104] Night window runs (documented: only under B)
[CL-B] Review gate pilot: Mac signing key [S+ E:Step1 U+~ Z+ W-]
--> (follow-up steps 2-4: model automation after key provisioning)
LEVEL 1 - depends on exactly one precursor
[MO-A] Release Wave 2 [S+ E:A U+~ Z+ W-]
| requires: [732597768] (billing resolved, remote CI gates active again)
| requires: [Gate PRIVATE.txt "green remote CI"]
--> (follow-up step: toggling visibility remains user-only action)
LEVEL 2 - depends on multiple / deep chain
[387521104] Autonomous migration run in night window [S+ E:B U+! Z+ W-]
| requires: [QR-A]=B (NTFS junction established)
| requires: (junction set on the second host via transfer ticket -
| ticket number not stated in the briefing)
----------------------------------------------------------------------------------------------------
CONTRADICTIONS & GATE COLLISIONS
----------------------------------------------------------------------------------------------------
[MO-A]=B X [Gate PRIVATE.txt "green remote CI"]
Conflict: Option B would release Wave 2 based solely on local tests,
even though two module contracts explicitly demand green remote CI.
Resolution: Recommendation A forces [732597768] (billing) first, resolving collision.
[CL-A]=StatusQuo X [Gate "1 Approving Review" (self-approval impossible)]
Conflict: master demands 1 review, but sole repository account is lukisch.
Resolution: Recommendation A (admin merge) legitimately breaks the dead end.
----------------------------------------------------------------------------------------------------
LEGEND & RATING KEY
----------------------------------------------------------------------------------------------------
Edges & Structure:
+--> unlocks / enables (causality documented in source)
=> blocks / prevents (gate or external blocker)
--> requires / sequence (precondition or follow-up step)
?--> presumed dependency (plausible coupling, but undocumented)
--X--> invalidates / supersedes (source insight renders target obsolete)
X contradiction / collision (gate or policy violation)
| vertical hierarchy line / attribute mapping
[ID] decision node (item abbreviation or item number from briefing)
[Gate] external gate / rule / contract - NOT a decision node
=Opt specific option for a node (e.g. [MO-A]=B)
(...) unnumbered edge annotation / follow-up step (no invented synthetic ID)
Node Assessment [S E U Z W]:
S: Sensible (+ sound / ~ qualified / - unsound)
E: Recommended (A, B, C, resolve, Step1, - none)
U: User-typical (direction: + typical / ~ neutral / - atypical;
confidence: ! grounded / ~ trade-off / ? escalation)
[! = documented (prose green), ~ = user trade-off (prose yellow),
? = unverified / escalation (prose red)]
Z: Coherent (+ harmonizes / ~ slight friction / - architectural break)
W: Contradictory (- conflict-free / + hard collision with gate or policy)
====================================================================================================
Was decision-path NICHT tut
- Trifft keine Entscheidungen: Der Skill bietet strukturelle Transparenz. Die Entscheidungsbefugnis verbleibt beim Benutzer.
- Erfindet keine Optionen: Der Skill entwickelt keine neuen Alternativen oder Gewichtungskriterien; dies gehört zu decide oder decision-briefing.