Was macht wallflower?
Die KI macht die Vorbereitung, und der Raum denkt. Deine Aufgabe ist es, festzulegen, wovon das Gespräch ausgeht: das Material, so platziert, dass die Beziehungen, über die sich zu streiten lohnt, sichtbar sind, mit nichts, das fertig aussieht. Hinterher lies zurück, was die Leute mit dem Board gemacht haben, denn das ist das Protokoll ihres Urteils.
Einrichtung
wallflower (oder seine Kurzform wf) stammt aus dem npm-Paket wallflower-board: npm install -g wallflower-board, oder prefixe Befehle mit npx wallflower-board anstelle von wallflower. Boards gehen an den öffentlichen Server unter board.byenzyme.com, sofern der Benutzer keinen anderen eingerichtet hat (wallflower server sagt, welcher). Es muss nichts gestartet werden.
Für ein Board auf diesem Rechner (--server local), starte zuerst den lokalen Server im Hintergrund:
(nohup wallflower serve > /tmp/wallflower.log 2>&1 &)
In einem ausgecheckten Repository führt npm run dev stattdessen den lokalen Server mit einer Live-Neulade-Benutzeroberfläche aus.
Die gesamte Oberfläche:
wallflower new "Titel" [--id ID] Board erstellen und als aktuelles festlegen
wallflower put plan.json|- Gruppen und Karten hinzufügen oder aktualisieren; zeigt Layout, Warnungen und Layoutprobleme
wallflower view Layout-Karte, dann jede Karte mit ihrer Position
wallflower diff Was Leute geändert haben, seit sie das Board berührt haben
wallflower wait [--timeout SEKUNDEN] Blockieren, bis jemand „Weiteren Durchgang machen“ drückt; gibt diese Runde aus
wallflower url [--name Name] Die URL zum Übergeben, mit dem Namen des Benutzers darin
wallflower share Der Link für andere Leute; sagt auf stderr, ob sie darauf zugreifen können
wallflower delete [id] Ein von dir erstelltes Board für alle löschen
wallflower server Welcher Server für neue Boards verwendet wird
wallflower list | wallflower use <id>
wallflower url gibt aus, wo das Board geöffnet wird. Ein lokaler Server antwortet nur auf diesem Rechner; setze ihn nicht selbst der Öffentlichkeit aus. Neue Boards gehen an board.byenzyme.com oder an den eigenen Server des Benutzers, falls eingerichtet (in ~/.config/wallflower/config.env oder WALLFLOWER_URL und WALLFLOWER_TOKEN); wallflower server sagt, welcher. Boards auf board.byenzyme.com werden nach 90 Tagen ohne Aktivität gelöscht. --server <url> leitet einen beliebigen Befehl an einen anderen Server weiter, und --server local an diesen Rechner: verwende ihn für ein Board, das nur der Benutzer sehen wird und das privates Material enthält, es sei denn, der Benutzer hat etwas anderes gesagt. Übergib ihn an wallflower new oder wallflower use; spätere Befehle für dieses Board bleiben auf seinem Server, ohne ihn. Der Link eines gehosteten Boards ist sein einziger Schlüssel: Jeder, der ihn hält, kann das Board bearbeiten und lesen, also gib ihn nur an die Personen, die im Raum sein sollten, und füge ihn nirgendwo öffentlich ein. Um an einem Board zu arbeiten, das jemand anderes erstellt hat, nimm die ID aus seinem Link (?board=<id>) und führe wallflower use <id> aus; es wird kein Token benötigt.
0. Entscheide, wofür das Board da ist
Lege drei Dinge fest, bevor du sammelst. Wenn du sie nicht ableiten kannst, frage nach.
- Was soll der Raum beurteilen? Jedes Meeting existiert für eine Handlung, die den anwesenden Personen gehört: auswählen, priorisieren, bewerten, benennen. Deine Interpretation hört kurz vor dieser Handlung auf.
- Wer ist im Raum? Dies entscheidet, was erscheinen darf (siehe Datenschutz).
- Was zeigt dieses Board, das die Quellen nicht zeigen? Schreibe es in einem Satz. Wenn die Antwort „die gleichen Notizen, in Kacheln“ lautet, hat das Board noch keine Aufgabe. Die übliche Antwort sind Beziehungen zwischen Quellen, die keine einzelne Quelle zeigt: dieselbe Notiz von drei Personen, eine Entscheidung neben dem, was jemand später gesagt hat, zwei Bemühungen, die dieselbe Sache betreffen.
Wenn das Publikum eine einzelne Person ist (ein privater Rückblick, eine Wochenrückschau), war diese Person in jedem Meeting und hat jede Notiz gelesen. Auszüge sagen ihr nichts. Baue das Board aus Mustern über Quellen hinweg, jedes gezeigt als zwei oder drei Karten von verschiedenen Orten zusammengelegt, plus eine Orientierungskarte über den Stand der Dinge (was anhängig ist, wer wem was schuldet). Erwarte weniger, stärkere Karten.
| Umgebung | Halt vor | Bemerkenswert |
|---|---|---|
| Agentengestützter Standup oder Planung | was einen Menschen braucht, Priorität, wer nimmt es | Kollisionen; Agenten, die sich widersprechen; Spezifikation vs. was gebaut wurde |
| Design-Review oder Kritik | Geschmack: was behalten werden soll | dieselbe Notiz, die über Versionen hinweg wiederkehrt; Prüfer, die uneins sind |
| Forschungszusammenfassung | die Themen und Erkenntnisse | Ausreißer; ein Wort, das zwei Dinge bedeutet; was Leute taten vs. sagten |
| Strategie oder Gründer | auswählen und festlegen | eine getroffene Entscheidung neu diskutieren; angegebene Prioritäten vs. wo Zeit hingeht |
| Private Überprüfung | die eigene Einschätzung der Person | Rückmeldung, die sich über Personen wiederholt; Abweichung von einem genannten Kriterium; offene Schleifen |
Diese Zeilen sind Schlussfolgerungen aus einigen wenigen echten Anrufen. Lass das Zurücklesen sie korrigieren.
1. Sammeln
Verwende die Suchwerkzeuge, die dir direkt zur Verfügung stehen: Volltextsuche (rg -il) nach Namen, Projektwörtern und Tags, sortiert nach Datum für Aktualität, folge dann Links von den Ankern. Wenn eine semantische Suche über die Notizen verfügbar ist (Enzymes enzyme petri / enzyme catalyze oder ähnliches), verwende sie für Konzepte. Für Agentenarbeit lies die Threads der Agenten und Git-Logs; für Anrufe lies die Transkripte.
Ein erster semantischer Durchlauf gibt normalerweise die häufigsten Themen der Notizen zurück, nicht das Material dieses Meetings. Bevor du den Plan schreibst, überprüfe:
- Anker. Nenne die 3 bis 6 Quellen, von denen das Meeting offensichtlich abhängt (die Eingrenzungsnotiz, die neuesten Anrufe, die Entscheidung, die es fortsetzt). Hast du sie vollständig gelesen?
- Aktuell. Enthält das Material die letzte Arbeitswoche zum Thema?
- Stimmen. Sind die wichtigen Personen mit ihren eigenen Worten vertreten?
Wenn nicht, formuliere in den Worten des Benutzers um, suche genau, folge Links oder stelle dem Benutzer eine spezifische Frage. Lese Dateien, bevor du sie verwendest; Ausschnitte irreführen. Wenn destillierte Notizen vorhanden sind (Meeting-Debriefs, frühere Zusammenfassungen), denke daran, dass sie bereits einige Beobachtungen gemacht haben. Zitiere die Personen darin, nicht ihre Schlussfolgerungen, und suche nach dem, was sie verbindet.
Datenschutz
Alles auf einem gemeinsamen Board muss aus Quellen stammen, die jeder im Raum sehen darf. Persönliche Reflexionen, private Notizen und alles, was als persönlich markiert ist, bleiben von einem gemeinsamen Board fern, auch wenn es relevant ist. Destillierte Notizen (Debriefs, Zusammenfassungen) mischen oft das Gesagte mit dem privaten Verständnis des Schreibers: nur die gesagten Teile sind teilbar. Formuliere den Punkt stattdessen als offene Frage oder lasse ihn weg. Dies beinhaltet die Vorschau, die eine Karte trägt (unten): etwa 200 Wörter ihrer Quelle gehen mit auf das Board.
2. Den Plan schreiben
Schreibe den Plan JSON von Hand, in einer Datei oder auf stdin, und füge ihn auf einmal ein: Gruppen, Karten und ihre Platzierungen zusammen. Baue kein Generator-Skript und schreibe keinen Validator: wallflower put legt das Board aus, kürzt Text, der das Budget überschreitet, und überprüft das Ergebnis.
{
"title": "Rückblick auf das Launch-Review",
"groups": [
{ "id": "g1", "col": 0, "why": "dieselbe Sorge von zwei Prüfern" },
{ "id": "next", "label": "In die nächste Woche mitnehmen", "col": 2, "zone": true }
],
"cards": [
{ "id": "rosa", "kind": "quote", "title": "Rosa über den Onboarding-Flow", "body": "Ich konnte nicht erkennen, was es von mir wollte",
"source": { "label": "Launch-Review, 4. März", "file": "/…/notes/2026-03-04 review.md", "url": "obsidian://open?…", "author": "Rosa", "date": "4. März" },
"place": { "in": "g1" }, "why": "dieselbe Verwirrung wie Kims Frage zum leeren Zustand" },
{ "id": "kim", "kind": "quote", "title": "Kim fragte es zweimal", "body": "was soll ich zuerst tun?",
"source": { "author": "Kim", "date": "6. März" }, "place": { "near": "rosa", "side": "right", "overlap": true } }
]
}
wallflower put plan.json
Pläne können unvollständig sein. Füge dieselbe ID erneut ein, um eine Karte zu bearbeiten oder zu verschieben, und { "id": "x", "delete": true } entfernt sie. Überall, wo eine ID verwendet wird, kannst du stattdessen die Nummer einer Karte verwenden ("#17"), so wie Runden und wallflower view die Haftnotizen der Leute anzeigen. Gruppen sitzen auf einem Raster (col, row); du berechnest niemals Pixel. Lasse Gruppen unbeschriftet, denn sie zu benennen ist die Handlung des Raums; why ist für das Zurücklesen, nicht für das Board. Zonen sind die Ausnahme: beschrifte sie ("Entschieden", "In die nächste Woche mitnehmen"), da der Name einer Zone die Anweisung ist.
Bis eine Person das Board berührt, legt jedes put das gesamte Board neu aus deinen Platzierungen an. Wenn du also eine Gruppe in eine andere row oder eine Karte in eine andere Gruppe verschiebst, funktioniert das einfach. Danach bleibt alles, was eine Person platziert hat, dort, wo sie es hingesetzt hat: deine neuen Karten gehen darum herum, und nur deine eigenen unberührten Gruppen verschieben sich, um Platz zu schaffen.
put gibt das Layout als Text aus, dann eine Prüfung. layout check: no overlaps, every card in its group, no cut-off text bedeutet, du bist fertig. Andernfalls benennt jede problem:-Zeile die Karten oder Gruppen nach ID (Gruppen, die sich überschneiden oder zu nah sind, eine Karte, die als in der falschen Gruppe erscheint, Karten, die sich gegenseitig bedecken, ein Titel, der über drei Zeilen geht, Text, den der Browser als abgeschnitten gemeldet hat); korrigiere den Plan und füge ihn erneut ein. wallflower view listet dieselben Probleme am Ende auf. Überschneidungen, die Leute gemacht haben, sind ihre und werden nie gemeldet. Mache keinen Screenshot des Boards, um das Layout zu überprüfen.
Platzierung
place | Verwendung für |
|---|---|
{ "in": "g1" } | Material, das zusammengehört (die Gruppe wächst) |
{ "near": "c1", "side": "right", "overlap": true } | zwei Karten, die als eine Sache gelesen werden sollen: eine Uneinigkeit, Abweichung, Wiederholung über Personen hinweg |
{ "around": "c1" } | eine Nachbarschaft erweitern: jede Karte landet in einem lockeren Ring um c1 (eine Karte oder eine Haftnotiz einer Person), in eine andere Richtung, innerhalb ihrer Gruppe |
{ "near": "c1", "side": "below" } | eine Karte neben einer anderen, ohne Überlappung; sie bleibt in der Gruppe des Partners, die wächst |
{ "edge": "g1", "side": "right" } | ein Ausreißer oder etwas, von dem du nicht sicher bist, ob es dazugehört |
{ "at": { "x": 0, "y": -200 } } | für Aufforderungen und seltene manuelle Stellen |
Kartenarten
Die Breite ist pro Art festgelegt, und die Höhe folgt dem Text.
| Art | für | Titel | Text |
|---|---|---|---|
quote | jeden wörtlichen Anker, gesprochen oder geschrieben; source.author = wer | Kernaussage, ≤90 | der Anker, ≤200 (Ziel unter 120) |
note | ein Objekt (ein Dokument, Ticket, PR, Sitzung) oder eine Notiz, die eine der Aufgaben unten erfüllt | ≤90 | ≤300 |
prompt | Markierungstext auf dem Board: die Startkarte, eine offene Frage | ≤160 | ≤200 |
sticky | was Leute hinzufügen (solltest du selten) | ≤140 | keine |
Setze people (ein Array von Namen, ["Rosa", "Kim", "Lee"]), wenn Breite wichtig ist; es wird als „von 3 Personen“ dargestellt. Ein Muster, das auf einer oder zwei Stimmen beruht, sollte dünn aussehen. Füge nur dann einen Link in source.url ein, wenn jeder im Raum ihn öffnen kann (ein gemeinsames Dokument, ein Ticket, ein PR); niemals einen Link zu privaten Notizen, der für sie nutzlos ist und preisgibt, wo deine Dateien liegen. Für Dateien verwende source.file (unten), das auf deinem Rechner bleibt.
Quellvorschauen. Gib jeder Karte, die aus einer Datei stammt, ihren source.file (ein absoluter Pfad; eine file://-URL funktioniert auch). wallflower put liest die Datei auf deinem Rechner und fügt etwa 200 Wörter um das Zitat der Karte herum an, die Leute durch Doppelklick auf die Karte oder Klick auf ihre Quellenzeile öffnen können. Das Zitat ist der body einer Zitat-Karte; bei einer Notizkarte setze source.quote auf eine wörtliche Phrase aus der Datei, oder die Vorschau ist der Anfang der Datei. Die Datei selbst verlässt niemals deinen Rechner. Schreibe niemals selbst eine Vorschau: put verwirft jedes source.passage im Plan. Für eine Quelle, die keine Datei ist (eine E-Mail, ein Ticket), speichere ihren Rohtext mit einer Shell-Umleitung (gog … > /tmp/src-1.md) und setze source.file darauf. Wenn put warnt, dass ein Zitat nicht gefunden wurde, ist der Anker nicht wörtlich: korrigiere den Anker, nicht die Warnung.
Karten schreiben
Ein Board wird auf einen Blick von Leuten gelesen, die auf das losspringen, was sie erwischt. Die meisten Karten sollten in zwei Sekunden lesbar sein.
- Titel = Kernaussage: Worum es geht, in einfachen Worten, bis etwa 60 Zeichen. Eine Beschreibung, kein Urteil.
- Text = Anker: das kürzeste wörtliche Fragment, das immer noch hängen bleibt. Bevorzuge die seltsame, konkrete oder lebendige Zeile. Wörtlich bedeutet nicht den gesamten Abschnitt.
Jeder Text muss eine Frage beantworten: Was lässt dies den Leser bemerken, sich erinnern oder untersuchen? Text, dessen einzige Aufgabe darin besteht, zu erklären, warum du etwas aufgenommen hast (eine Karte, die sagt, wofür sie ein Beleg ist, eine Notiz, die das Board beschreibt), bist du, der seine Vorbereitung kommentiert. Streiche ihn. Die Quellenangabe kann ruhig darunter stehen.
Eine Notiz verdient ihren Platz, indem sie eine dieser Aufgaben erfüllt, ungefähr in der Reihenfolge, wie sehr sie einem Raum helfen, Dinge zu verstehen:
- Zwei Dinge zusammenhalten, damit die Beziehung untersucht, angefochten oder auseinandergenommen werden kann.
- Ein fehlendes Stück aufdecken: wo die Beweise ausgehen („Was hat der Kunde tatsächlich gesehen, wie du entschieden hast?“).
- Eine Abfolge wiederherstellen, die ein einzelnes Zitat nicht fassen kann.
- Eine konkurrierende Lesart anbieten von etwas, das sich zu schnell gesetzt hat. In einem privaten Board rückt dies auf; in einem Gruppenboard überlasse den größten Teil dem Raum.
- Eine Erwartung zurückholen (was geplant war) neben dem, was passiert ist.
- Platz für Probe machen, normalerweise nachdem der Raum die Dinge verstanden hat.
Oft ist die richtige Notiz keine: zwei gut platzierte Karten erledigen bereits Aufgabe 1. Eine Statusnotiz mit echten Informationen (was anhängig ist, wer wem was schuldet) ist in Ordnung; eine Notiz, die das Board erklärt, ist es nicht.
Fragen sind für die ein oder zwei Notizen, die Aufgabe 2 oder 4 erledigen. Eine Wand von Fragen im Titel in der zweiten Person stellt die Fragen des Raums für ihn und wirkt maschinengeschrieben, genau wie der selbstrechtfertigende Text, den es ersetzt. Titel bleiben Kernaussagen.
Höre bei der Bedeutung auf. Benenne keine Gruppen, schreibe nicht „dies zeigt…“, „wichtige Erkenntnis“ oder „das Thema hier ist…“ und beschrifte nicht, warum zwei Karten nebeneinander sitzen. Die Platzierung macht die Behauptung, und jemand kann eine Platzierung anfechten, indem er eine Karte verschiebt. Mache auch nicht auf jeder Karte eine Einschränkung: Eine Einschränkung gehört auf die eine Karte, die sie betrifft.
| Anstatt | Schreibe |
|---|---|
| Titel „Preisnotizen, 23. Juli“, Text: ein 280-Zeichen-Auszug | Kernaussage „Geteilte Links bringen Besucher, die nicht bleiben“, Anker „sie lesen es einmal und gehen“ |
| Titel „Kim, Support-Anruf“, Text: ein vollständiger Satz über den Export | Kernaussage „Kim exportiert alles in eine Tabelle“, Anker „ich möchte nur die |
…
[gekürzt für Übersetzung]