Decision Briefing

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 nur einen Buchstaben kostet:

• Nummerierung: [E01], [E02], … — stabile Referenz über die ganze Session
• Kurze Frage + 1–2 Sätze Kontext
• Optionen als Buchstaben A/B/C/D (2–4 Optionen, mehr nur wenn nötig)
• Markierte Empfehlung mit 1-Satz-Begründung (z.B. → Empfehlung: A — weil …)
• Optional: Konsequenz-Hinweis (was folgt aus der Wahl)

Antwortformate des Users:

Einzeln:   "E01: A"  oder  "1A"
Batch:     "1A 2C 3B"  oder  "E01: A, E02: C, E03: B"
Vertiefen: "E02: mehr Info"  oder  "2?"
Vertagen:  "E03: später"

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] <Kurze Frage>
  Kontext: <1-2 Sätze: Warum steht das an? Was hängt dran?>
  A) <Option>
  B) <Option>
  C) <Option>
  → Empfehlung: <Buchstabe> — <1-Satz-Begruendung>
  (optional) Konsequenz: <Was folgt aus der Wahl / naechste Aktion>

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)

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

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.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)