<img src="banner.png" width="100%" alt="decision-briefing banner">

Decision-Briefing — Viele Entscheidungen eines Themas strukturiert abarbeiten

Aus einem Berg offener Entscheidungen wird ein nummeriertes Briefing mit Empfehlungen, das der User blitzschnell per Buchstaben beantworten kann — einzeln oder im Batch.

---

Wann nutzen?

Immer, sobald mehrere Entscheidungen anstehen — themenunabhängig. Typische Situationen:

• In einem Bereich/Thema haben sich viele offene Entscheidungen angesammelt
• Ein Dokument (Plan, TODO-Liste, Konzept) enthält mehrere unentschiedene Punkte
• Im Gespräch sind nacheinander mehrere Entscheidungsfragen aufgelaufen
• Der Agent hat selbst mehrere Rückfragen an den User — statt sie einzeln zu stellen, als Briefing bündeln
• Der User will offene Punkte schnell und fundiert "wegarbeiten"

Trigger-Wörter: offene Entscheidungen, Entscheidungs-Session, Briefing, abarbeiten, durchgehen, entscheiden wir das mal alles

Abgrenzung: decide liefert Frameworks für EINE Frage. decision-briefing koordiniert die Abarbeitung VIELER Entscheidungen eines Themas — und setzt decide bei komplexen Einzelfällen ein. Ist eine Entscheidung bereits getroffen/analysiert und soll nur noch als executive Kurzform (Pro/Contra, Talking Points, Empfehlung, Link zur Vollanalyse) weitergegeben werden, übernimmt decision-shot die Darstellung — kein Konkurrenzskill, sondern das Ausgabeformat danach.

---

Kern-UX

Das Herzstück ist das Briefing-Format. Jede Entscheidung wird so vorgelegt, dass die Antwort schnell und ohne kognitiven Ballast erfolgen kann:

• Sprechender Klartext-Titel je Punkt (z. B. „Hermes-Sprachunterstützung“, „Rettung alter Arbeitssitzungen“)
• Alltagssprache in Ich-Form (Dreiklang):
  1. Lage: Was ist die Situation / das Problem?
  2. Ich mache ...: Was plane/empfehle ich konkret zu tun?
  3. Rückfall: Was passiert bei Fehlschlag oder was entscheidet der Nutzer danach?
• Keine technischen Kürzel im Fragetext: Keine Ticketnummern (T-...), D-Kennungen, Git-Hashes oder Dateipfade im sichtbaren Text für den Menschen.
• Optionen als Buchstaben A/B/C/D (2–4 Optionen, klar und verständlich formuliert)
• Markierte Empfehlung in Ich-Form (z. B. → Ich empfehle Option A, weil ich damit ...)
• Technische Referenztabelle nur im Anhang: Stabile Nummern ([E01], [E02]), Ticket-IDs und Zielregister werden am Ende in einer kompakten Tabelle geführt.

Antwortformate des Users:

Per Buchstabe:   "E01: A"  oder  "1A"
Batch:           "1A 2C 3B"
Per Klartext:    "Bei der Hermes-Sprachunterstützung Option A"
Vertiefen:       "E02: mehr Info"  oder  "2?"
Vertagen:        "E03: später"
Gesamtabnahme:   "Passt so, alle Empfehlungen umsetzen"

---

Workflow (4 Phasen)

Thema + vorliegende Entscheidungen
     |
     v
Phase 1: ERFASSEN & INVENTARISIEREN
     |
     v
Phase 2: BRIEFING AUFBEREITEN
     |
     v
Phase 3: DECISION-SESSION
     |
     v
Phase 4: PROTOKOLL & RÜCKSCHREIBEN

Phase 1: Erfassen & Inventarisieren

Quellen: Was der User nennt, ein vorliegendes Dokument oder der Gesprächskontext. Kein systemweiter Scan — nur das, was vorliegt.

1. Alle offenen Entscheidungen als Liste aufstellen (je 1 Zeile: Kurztitel)
2. Duplikate erkennen und zusammenführen (gleiche Frage, mehrfach formuliert)
3. Abhängigkeiten markieren ("E04 hängt von E01 ab")
4. Reihenfolge festlegen: Blocker zuerst (Entscheidungen, von denen andere abhängen), dann nach Dringlichkeit
5. Liste dem User kurz zur Bestätigung zeigen ("Habe ich alle? Fehlt etwas?")

Phase 2: Briefing aufbereiten

Pro Entscheidung:

[E01] <Sprechender Klartext-Titel>
  Lage: <1 Satz: Was ist die Situation?>
  Handlung: <1-2 Sätze in Ich-Form: Was schlage ich vor zu tun?>
  Rückfall: <1 Satz: Was passiert bei Fehlschlag oder als nächster Schritt?>
  A) <Option in Alltagssprache>
  B) <Option in Alltagssprache>
  → Meine Empfehlung: A — <Begründung in Ich-Form>

Am Ende des Briefings:

### Technische Referenztabelle (nur für Buchung & Audit)
| Nummer | Klartext-Titel | Empfehlung | Ticket-ID / D-Nummer | Quelle / Pfad |
|---|---|---|---|---|
| E01 | Hermes-Sprachunterstützung | A | T-20260913-989062143 | hermes-agent |

Regeln für gute Optionen:

• Optionen müssen sich gegenseitig ausschließen und das Spektrum abdecken
• Bei Bedarf eine Option "Status quo behalten" oder "vertagen" mit aufnehmen
• Die Empfehlung ist transparent begründet — nie versteckt suggestiv
• Bei unklarer Faktenlage: erst klären (oder als offene Frage kennzeichnen), nicht raten

Phase 3: Decision-Session

1. Briefing vorlegen — einzeln (eine Entscheidung pro Nachricht) oder als Batch (alle auf einmal); bei >5 Entscheidungen in Blöcken von 3–5
2. Buchstaben-Antworten entgegennehmen und quittieren
3. Bei "mehr Info"-Antwort: Entscheidung vertiefen (Methoden-Werkzeugkasten unten)
4. Bei komplexen Einzelfällen (viele Kriterien, hohe Tragweite): an den decide-Skill eskalieren (Weighted Scoring, Scenario Analysis)
5. Vertagte Entscheidungen explizit als offen weiterführen — nicht stillschweigend fallen lassen

Phase 4: Protokoll & Rückschreiben

1. Ergebnis-Tabelle erstellen:

| Nr.  | Entscheidung        | Gewählt | Status   |
|------|---------------------|----------|----------|
| E01  | <Kurztitel>         | A        | getroffen|
| E02  | <Kurztitel>         | C        | getroffen|
| E03  | <Kurztitel>         | —        | vertagt  |

2. Getroffene Entscheidungen in die Quelldokumente/TODO-Dateien eintragen — am Fundort der offenen Frage, z.B.:

ENTSCHEIDUNG: <Frage>
  → GETROFFEN 2026-06-13: Option A (<Kurzfassung>)
  → Nächste Aktion: <falls die Entscheidung eine Folgeaktion impliziert>

3. Vertagtes explizit als offen führen (im Quelldokument oder in der TODO-Liste), damit es beim nächsten Briefing wieder auftaucht

---

Beispiel-Briefing (fiktiv)

Thema: Relaunch einer Vereinswebsite — 3 offene Entscheidungen aus dem Projektplan.

[E01] Welches System für die neue Website?
  Kontext: Aktuelle Seite ist handgepflegtes HTML; 2 Personen sollen künftig Inhalte pflegen.
  A) Static-Site-Generator (schnell, sicher, Pflege via Git)
  B) Klassisches CMS mit Admin-Oberfläche
  C) Website-Baukasten (gehostet)
  → Empfehlung: B — zwei nicht-technische Redakteure brauchen eine Oberfläche, kein Git.

[E02] Wie wird gehostet?
  Kontext: Budget ~10 EUR/Monat, kein eigener Admin im Verein.
  A) Shared Hosting beim bestehenden Anbieter
  B) Eigener kleiner VPS
  C) Managed Hosting passend zum gewählten System
  → Empfehlung: C — am wenigsten Wartungsaufwand ohne Admin; Konsequenz: hängt von E01 ab.

[E03] Wann geht die neue Seite live?
  Kontext: Inhalte sind zu 60% migriert; Vereinsjubiläum in 3 Monaten.
  A) Sofort als Soft-Launch (Rest nachziehen)
  B) Nach vollständiger Inhaltsmigration
  C) Zum Jubilaeum als Stichtag
  → Empfehlung: A — umkehrbar und liefert früh Feedback; finale Inhalte folgen.

User antwortet im Batch: "1B 2C 3A" → Ergebnis-Tabelle, dann werden die drei Entscheidungen im Projektplan als GETROFFEN eingetragen.

---

Methoden-Werkzeugkasten (für "mehr Info" und Vertiefung)

Methode	Wann	Kurzbeschreibung
Pro/Contra-Matrix	2–3 Optionen, schneller Vergleich	Alle Optionen nebeneinander bewerten
Nutzwertanalyse	Mehrere Kriterien	Gewichtete Kriterien, Punkte pro Option (quantitativ wenn möglich)
Second-Order Thinking	Tragweite unklar	Was sind die Folgen der Folgen?
Prämortem	Riskante Entscheidung	"Es ist schiefgegangen — warum?" Schwachstellen vorab finden
10/10/10-Methode	Emotionale/zeitliche Verzerrung	Wie wirkt die Entscheidung in 10 Minuten / 10 Monaten / 10 Jahren?

---

Arbeitsprinzipien

• Keine Entscheidungen aufdrängen: Informationen liefern, Empfehlung transparent begründen — der User entscheidet
• Bias-Erkennung: Denkfehler ansprechen, wenn sie sichtbar werden (Confirmation Bias, Sunk Cost)
• Reversibilität beachten: Umkehrbare Entscheidungen schnell entscheiden, finale gründlicher behandeln
• Zeitdruck berücksichtigen: Schnelle Entscheidungen brauchen einfachere Methoden — nicht jede Frage verdient eine Nutzwertanalyse

Session-Provenienz bei erzeugten Artefakten

Erstellt dieser Skill ein wichtiges neues, dauerhaft gespeichertes Briefing, einen Bericht, ein Handoff oder einen Receipt, endet das Artefakt mit genau einer Zeile:

session: <session-id> | <agent>@<host> | YYYY-MM-DD

• Quellenpriorität: explizite Laufzeit-/CLI-Angabe, dann autoritative Provider-Umgebung oder Hook, sonst unbekannt. Werte nie erraten.
• Ein Subagent verwendet die Session-ID seiner Elternsession.
• Routine-Chat, konsultierte Quelldokumente, Policies, CLAUDE.md, READMEs und bloß rückgeschriebene Entscheidungen erhalten keinen pauschalen Stempel. Altdateien werden nicht blind nachgestempelt.

---

Abgrenzung und Synergien

Funktion	decide	decision-briefing
Einzelne Entscheidung mit Framework strukturieren	✓	—
Viele Entscheidungen eines Themas inventarisieren	—	✓
Nummeriertes Briefing mit A/B/C-Optionen	—	✓
Batch-Antworten ("1A 2C 3B")	—	✓
Rückschreiben in Quelldokumente	—	✓
Fertige Analyse zu einer einzelnen Frage als Kurzform weitergeben	—	— (siehe decision-shot)

Synergie: Bei komplexen Einzelfällen innerhalb einer Session wendet decision-briefing die Frameworks aus decide an (Weighted Scoring, Scenario Analysis). Für den größeren Denkprozess davor (Analyse → Ideen → Entscheidung) siehe structured-thinking.

---

Changelog

1.2.0 (2026-09-18)

• Stilregel für verständliche Entscheidungstexte verankert (T-20260913-883789445, Nutzeranweisung 2026-09-13):
  • Keine kryptischen Ticketnummern, D-Kennungen oder Pfade im sichtbaren Fragetext.
  • Dreiklang in Ich-Form (Lage, „Ich mache …“, Rückfall) für Kontext und Empfehlung.
  • Sprechende Klartext-Titel je Entscheidungspunkt; Antwortformate um Klartext und Gesamtabnahme erweitert.
  • Technische Zuordnung (Kürzel, Ticket-IDs, Registerpfade) in Anhangstabelle am Briefingende verlegt.

1.1.0 (2026-09-09)

• P-018 ergänzt Session-Provenienz für wichtige neu erzeugte Briefings, Berichte, Handoffs und Receipts; Quellenpriorität, Elternsession bei Subagenten und enge Ausschlüsse sind festgelegt.

1.0.0 (2026-06-13)

• Portiert aus dem BACH-Experten decision-briefing v1.0.0; Scanner-Komponente (scanner.py, sources.json, Marker-Scans) bewusst entfernt — Erfassung erfolgt leichtgewichtig aus dem vorliegenden Kontext

---

Portiert aus BACH | Standalone-Version ohne Scanner

Siehe auch: decide (Frameworks für eine einzelne Entscheidung) | structured-thinking (Analyse → Ideen → Entscheidung als Meta-Workflow) | decision-shot (fertige Analyse als executive Kurzform mit Link zur Vollversion präsentieren)