iamshadmirza/to-onepager

Verwandle ein Gespräch in eine einseitige Zusammenfassung: eine Behauptung, fundierte Beweise, leicht lesbar und nachvollziehbar, konfiguriertes Veröffentlichungsziel.

Eingabe: Transkriptpfad/-einfügen, falls angegeben; sonst aktuelles Gespräch. setup / reconfigure → Setup ausführen, auch wenn config.md existiert.

Konfiguration: config.md neben dieser SKILL.md (lokal zur Installation). Form: config.example.md.

Seitentypen (live): research-finding | proposal. Bevorzugt research-finding, wenn unklar. Einmal nachfragen, wenn beide passen. Wahl vor dem Entwurf ankündigen.

Schritte

0. Setup

Wenn config.md fehlt oder der Benutzer die Neukonfiguration verlangt hat:

1. Ziel erfragen: local | google-docs | confluence (genau eines).
2. Felder für dieses Ziel sammeln (siehe config.example.md). Confluence erfordert confluence_folder_url.
3. config.md in diesem Skill-Verzeichnis schreiben.
4. Dem Benutzer mitteilen, dass dies für jeden zukünftigen Durchlauf gilt; setup zum Ändern sagen.

Abschluss: gültiges config.md mit bekanntem destination. Nur Setup-Durchläufe enden hier, es sei denn, eine einseitige Zusammenfassung wurde ebenfalls angefordert.

1. Sammeln

Gesamte Eingabe lesen. Nur Arbeitsnotizen (dem Benutzer nicht zeigen):

• Sitzungsabsicht: empirische Behauptung vs. Entscheidungswette
• Die Frage oder das Problem, das die gesamte Sitzung bedient hat
• Getestete Annahmen (mit Korrekturen / was sich geändert hat voranstellen)
• Fundierte Fakten (belegt) vs. unbelegte Behauptungen (mittlere Sicherheit)
• Methode, Grenzen, offene Fragen, nächste Aktionen (Produkt-/Forschungsentscheidungen, keine lokalen Runbooks)

Wenn die Absicht eher research-finding ist, auch erfassen:

• Erklärende Mechanismen mit Zählungen (dominantes Signal, FP-Muster, kontrafaktisch)
• Vom Benutzer hervorgehobene Erkenntnisse ("Setze dies in Schlüsselerkenntnisse")
• Experiment? Wenn die Sitzung dieselbe Messung über N Bedingungen hinweg vergleicht (Grenzen, Modi, Bereiche, Konfigurationen, A/B-Arme), jede Bedingung und die entscheidende Tabelle (Scorecard, Lückenzusammensetzung, Gleichheitsprüfung) auflisten. Markieren mit fill: experiment.

Wenn die Absicht eher proposal ist, auch erfassen:

• Problem / wen es betrifft, empfohlene Wette, warum jetzt, Ansatz, Alternativen (mit Quellen, falls vorhanden), Risiken
• Kurzfristige nächste Schritte, die in der Sitzung besprochen wurden

Abschluss: Absichtssignale, Korrekturen, belegte Fakten und zweigspezifische Notizen erfasst. Noch keine Interpretation.

2. Routen

Genau einen Seitentyp aus dem folgenden Katalog auswählen. Ankündigen: Seitentyp: ….

Seitentyp	Verwende, wenn	Bevorzuge den anderen, wenn
research-finding	Beweise haben beantwortet "Was ist wahr?"	Sitzung ist hauptsächlich eine Wette mit wenig neuen Beweisen
proposal	Sitzung rahmt eine Wette (Problem, Weg, Warum, Wie)	Sitzung ist reine Messung ohne empfohlene Änderung

Validierung und Architektur für später aufheben; wenn die Sitzung nur diese Formen hat, fragen, welcher live-Typ am nächsten kommt, oder anhalten.

Abschluss: ein Seitentyp ausgewählt und angekündigt.

3. Destillieren

Lade die Vorlage für den gerouteten Typ (Kontextzeiger — nur diese Datei lesen):

• research-finding → templates/research-finding.md
• proposal → templates/proposal.md

Fülle dieses Gerüst für leichtes Lesen: Ein kalter Leser sollte die Behauptung in Sekunden erfassen und einen Faden pro Abschnitt verfolgen.

research-finding Füllpfad

• Standard: Annahmen → Ergebnisse → Schlüsselerkenntnisse (Standardgerüst der Vorlage).
• Experiment (wenn beim Sammeln fill: experiment markiert wurde): das Experimentgerüst der Vorlage verwenden. Ankündigen: Füllpfad: experiment.
  • Erkenntnisleiter: gestapelte Aufzählungspunkte (ein Urteil pro Bedingung) plus optional ein Fazit; nicht N Bedingungen in einen Mega-Satz quetschen.
  • Kontext vor Bedingungen (optional): nach Antwort ein kurzer Block, der die Seiten des Vergleichs und etwaige leicht zu verwechselnde Begriffe erklärt (z. B. Typen vs. Instanzzählungen), damit Tabellen nicht falsch gelesen werden. Nur verwenden, wenn die Frage nicht ausreicht. Eine einfache Überschrift wie Wie zu lesen bevorzugen; weglassen, wenn nicht benötigt. Keinen obligatorischen Abschnittsnamen erfinden.
  • Bedingungsabschnitte: ein Abschnitt der obersten Ebene pro Bedingung; jeder ist Urteil dann Analyse. Den Abschnitt nach Fairness oder Ergebnis betiteln (z. B. "Fairer A/B: Begrenzung entfernt"), nicht nur nach dem rohen Stellhebel ("MaxMessages = 100"). Den teilbaren Beleg in die Analyse (Scorecard und/oder gleiche Schlussfolgerung / Lückenzusammensetzungstabelle) legen.
  • Replikation: unter der entscheidenden/fairen Bedingung verschachteln (z. B. Multisitzungs-Prüfung); keinen Abschnitt der obersten Ebene nur für Wiederholungen hinzufügen.
  • Ein N-Bedingungen-Experiment nicht in Annahmen → Ergebnisse → Schlüsselerkenntnisse abflachen.

Lesbarkeit (jede Seite)

• Mit dem Konkreten voranstellen: Titel und Erkenntnis mit der Zahl, dem Urteil oder der Wette eröffnen. Kontext folgt; er eröffnet nicht die Seite. Bei Experimenten kann die Erkenntnis den Einsatz als Aufzählungsleiter tragen; der Titel kann den Vergleich nennen, wenn die Erkenntnis die Zahlen enthält.
• Nach dem Beispiel erklären: in Ergebnissen, Schlüsselerkenntnissen, Analyse und Wie zuerst das gemessene Ergebnis oder den gewählten Weg nennen, dann eine kurze Zeile Kontext, falls nötig.
• Eine Aufgabe pro Abschnitt: jede Überschrift erledigt eine Aufgabe. Wenn ein Abschnitt zwei Dinge argumentiert, aufteilen oder streichen.
• Antwort, die ein kalter Leser nutzen kann, ohne sich um den Seitentyp zu kümmern: Erkenntnis (TLDR) / Sicherheit / Na und
• Titel ist die Behauptung (eine gemessene Zahl einschließen, wenn das Transkript eine hat; Experimente können die Zahl stattdessen in die Erkenntnis setzen)
• Empfehlung: nur in der Sitzung besprochene Aktionen. Wenn die Sitzung nur eine Frage beantwortet hat (abgeschlossene Forschung, keine Produktwette), Keine schreiben (oder "Forschung abgeschlossen; kein Follow-up") — keine nächsten Schritte, Dokumenten-TODOs, Überprüfungs-Hausaufgaben oder einen "~1-Wochen"-Plan erfinden.
• Kopfzeile: Eigentümer, Tiefer eintauchen
• Überprüfungsabschnitt vorhanden

Eigentümer: eine reale Person ermitteln. Für Confluence-Ziele Atlassian-Erwähnungen beim Veröffentlichen verwenden (publish.md). Ansonsten Anzeigenamen. Bei Unbekanntheit fragen; TBD nur, wenn aufgeschoben.

Abschluss: geroutetes Gerüst gefüllt (Standard oder Experiment); Chrome vollständig; Eigentümer ermittelt oder explizites TBD; Titel und Erkenntnis beginnen mit der konkreten Behauptung.

4. Verankern

Fehlschläge vermeiden und solange bearbeiten, bis alle Prüfungen bestehen. Dieser Schritt ist die alleinige Quelle der Wahrheit für Qualität (Vorlagen wiederholen diese Regeln nicht).

Jede Seite

• Jede faktische Zelle/jeder faktische Aufzählungspunkt ist auf das Transkript zurückführbar
• Keine ungemessenen Größen
• Kaltleser-Antwort funktioniert ohne Lesen des Seitentyps; Erkenntnis ist die TLDR und beginnt mit der konkreten Behauptung (Experiment-Erkenntnis kann eine Aufzählungsleiter sein)
• Titel beginnt mit der Behauptung (kein Thema oder weiche Überschrift); Experimente können den Vergleich im Titel nennen, wenn die Erkenntnis den Einsatz/die Zahlen enthält
• Textkörper entspricht dem gerouteten Seitentyp (kein Hybridgerüst)
• Eine Aufgabe pro Abschnitt; kein Abschnitt, der sowohl erklärt als auch empfiehlt
• Chrome vollständig (Eigentümer, Tiefer eintauchen)
• Tiefer eintauchen / Empfehlungen bleiben frei von lokalem Runbook-Unrat
• Sicherheit entspricht der Evidenz; Titel entspricht gemessenen Zahlen, falls vorhanden (oder die Erkenntnis bei Experimentleitern)
• Einseitiges Budget: etwa 600 Wörter Prosatext; bei Überschreitung die unwichtigsten Ideen streichen (nicht die Schriftgröße verkleinern oder einen Anhang einfügen). Ausnahme: entscheidende Tabellen des Experiments (Scorecard, Lückenzusammensetzung, Gleichheitsprüfung) werden nicht gestrichen, um das Budget zu erreichen; stattdessen die Aufzählungspunkte um sie herum kürzen.
• Klare Prüfung von Antwort + Empfehlung: aktive Stimme, kurze Wörter, unnötige Wörter und Fachjargon streichen
• Keine Schablonenbrücken: Phrasen wie "in der heutigen Landschaft", "Spielveränderer", "hier ist, warum das wichtig ist" oder eine abschließende Frage, die nur zur Steigerung des Engagements hinzugefügt wurde, streichen
• Keine weiche Zusammenfassung: Empfehlung wiederholt nicht die Erkenntnis
• Keine erfundenen Folgemaßnahmen: nächste Schritte nur, wenn das Transkript sie besprochen hat; sonst ist die Empfehlung Keine / Forschung abgeschlossen
• Jeder Abschnitt fügt etwas Neues hinzu; Füllmaterial löschen, das nur einen früheren Abschnitt wiederholt

Forschung-Finding-Seiten