| name | agent-feedback-partner |
| description | Sammelt Paul Baders Workshop-Beobachtungen zu Kollegen und bereitet sie für Feedback-Gespräche auf. Paul spricht ein, was ihm auffällt; der Skill legt jede Beobachtung als SBI (Situation/Verhalten/Wirkung) anonymisiert in der Notion-DB „Feedback-Beobachtungen" ab und ruft vor einem Gespräch einen strukturierten Spickzettel ab — Stärken/Entwicklungsfelder nach Thema, jeder Punkt mit konkretem Beispiel. Drei Modi: (1) Capture — Beobachtung(en) einsprechen, Beispiel-Pflicht; (2) Prep — „bereite mein Feedback für X vor"; (3) Close — Zyklus nach dem Gespräch archivieren. Aktivieren bei: „Feedback festhalten", „mir ist bei X aufgefallen", „Beobachtung zum Workshop", „bereite mein Feedback-Gespräch mit X vor", „Feedback-Prep", „was habe ich zu X notiert", „Feedback-Gespräch abschließen". NICHT für Netzwerk-/Beziehungs-Gedächtnis (→ agent-network), NICHT für Selbst-Vorsätze/Routinen (→ agent-productivity-hacks), NICHT für den Tages-/ Wochenüberblick (→ agent-brief).
|
Feedback-Partner
Zweck
Paul beobachtet Kollegen in Workshops und will ihnen danach Feedback mit konkreten
Beispielen geben. Dieser Skill ist sein Gedächtnis dafür: er nimmt laufend
Beobachtungen auf (Capture), hält jede an einem konkreten Anker fest und gibt vor
dem Gespräch einen strukturierten Spickzettel aus (Prep) — Punkte gruppiert, jeder
mit dem Moment dahinter. Nach dem Gespräch wird der Zyklus archiviert (Close), der
nächste startet sauber.
Der Wert liegt im Abrufen zur richtigen Zeit und in der Beispiel-Pflicht —
Feedback ohne konkreten Moment verpufft. Der Skill entscheidet nie über den Inhalt des
Feedbacks; er strukturiert, was Paul beobachtet hat.
Abgrenzung (harte Regel)
Leistungs-/Verhaltensbeobachtung zu einem Kollegen aus einem Workshop → diese DB.
Wer-kennt-wen, Beziehungs-/Kontakt-Gedächtnis → agent-network (Vault).
Eigener Vorsatz/Routine („ich will künftig …") → agent-productivity-hacks.
Akquise/Outreach zu einer Person → agent-outreach-* (Attio).
Datenbank & IDs
IDs kommen ausschließlich aus memory/state/notion-ids.json — nie hart hier. Lade
die Datei zu Beginn:
feedback-partner.feedback_db — Database-ID (für Schema-Fetch)feedback-partner.feedback_data_source — Data-Source-ID, Format collection://<…>
(Parent für notion-create-pages, Ziel für Voll-Reads)- Prep/Close lesen strukturiert über
scripts/notion_query.py --db feedback
(Alias in query_databases)
Name in Notion: Feedback-Beobachtungen, eigenständige private Workspace-Seite.
Schema (verifiziert gegen die Data Source, 07.08.2026)
Ein Eintrag = eine Beobachtung.
| Property | Typ | Werte / Rolle |
|---|
| Person | Title | Anonymisierter Handle — Vorname oder Codename, nie Nachname |
| Rolle | Text | optional, anonym (z. B. Consultant, PL) |
| Thema | Select | Moderation · Kommunikation & Klarheit · Struktur & Vorbereitung · Widerstand & Konflikt · Kundeninteraktion · Team-Zusammenarbeit · Präsenz & Wirkung (wächst organisch) |
| Valenz | Select | Stärke, Entwicklungsfeld |
| Datum | Date | Tag der Beobachtung (Default: heute) |
| Workshop | Text | Kontext/Anlass, anonym (kein Klienten-/Projektname) |
| Situation | Text | SBI-S — wann/wo im Workshop |
| Verhalten | Text | SBI-B — was genau getan/gesagt (der konkrete Anker/Zitat) |
| Wirkung | Text | SBI-I — Effekt auf Gruppe/Ergebnis |
| Feedback-Absicht | Text | was Paul damit ansprechen will |
| Status | Select | Offen (Default beim Erfassen), Archiviert |
| Zyklus | Text | Label des Feedback-Zyklus, z. B. H2/2026 |
Sensibilität — Anonymisierung (nicht verhandelbar)
Es sind benannte Leistungsdaten über Kollegen. Deshalb speichert der Skill nur, was
re-identifizierung vermeidet:
- Person = nur Vorname oder Codename. Nie Nachname. Bei gleichem Vornamen im Team
einen kurzen, von Paul gewählten Disambiguator (z. B.
Anna-M) — bleibt anonym.
- Keine Klienten-, Projekt- oder Firmennamen in
Workshop, Situation etc. —
Branche/Anlass generisch statt konkret.
- Diktiert Paul versehentlich einen vollen Namen oder Klienten, still auf den Handle
kürzen und einmal darauf hinweisen — nie den vollen Namen wegschreiben.
- Die Zuordnung Handle → echte Person bleibt bei Paul, nie im Store.
Damit ist die (committete, cloud-basierte) Ablage vertretbar — der Store selbst
identifiziert niemanden.
Notion-Schreib-Konventionen (verbindlich, MCP-Eigenheiten)
Gleiche Tool-Nutzung wie agent-lessons / agent-productivity-hacks:
- Anlegen:
notion-create-pages, Parent { "data_source_id": "<feedback_data_source>" }.
properties = JSON-Map Name → Wert. Datum als YYYY-MM-DD. Status: Offen.
- Ändern (Close):
notion-update-page mit command: "update_properties",
Status: Archiviert. Property-Änderungen nie im selben Call mit Content mischen.
- Lesen strukturiert:
scripts/notion_query.py --db feedback [--filter …] [--columns …] [--ids] (read-only, headless-tauglich). --ids liefert die Page-IDs für nachfolgende
Updates. notion-fetch von collection://<feedback_data_source> gibt Schema + Einträge.
- Der Personen-Filter
--filter "Person=<Handle>" matcht per contains (Title-Text) —
bei knappen Handles reicht das; clientseitig auf exakten Handle nachschärfen.
Modus 1: Capture
Trigger: Paul spricht/schreibt Beobachtungen ein („mir ist bei Anna aufgefallen …",
„Beobachtung Workshop:", „Feedback festhalten"). Oft ein Batch — mehrere
Beobachtungen, ggf. zu mehreren Personen, in einem Diktat.
Ablauf:
- Abgrenzungstest (oben). Gehört es zu Network / Hacks / Outreach → dort hinweisen,
nicht hier anlegen.
- Aufsplitten: Diktat in einzelne Beobachtungen zerlegen, je Person/Moment eine.
- In SBI zerlegen je Beobachtung:
- Situation — wann/wo im Workshop.
- Verhalten — was genau getan/gesagt; der konkrete Anker (Moment, Zitat).
- Wirkung — Effekt auf Gruppe/Ergebnis.
Dazu Thema und Valenz (Stärke/Entwicklungsfeld) vorschlagen,
Datum = heute,
Zyklus = laufender Halbjahres-Zyklus (H1/H2 + Jahr), falls Paul keinen nennt.
- Beispiel-Pflicht: Fehlt das Verhalten (der konkrete Anker) — Paul nennt nur
eine Wertung ohne Moment („war unstrukturiert") — genau einmal nachfragen:
„Woran konkret? Welcher Moment?" Ohne Anker keine brauchbare Rückmeldung. Situation
und Wirkung dürfen knapp/inferiert sein; das Verhalten ist der Kern.
- Anonymisierung (oben) durchsetzen: Handle statt Name, keine Klienten/Projekte.
- Anlegen via
notion-create-pages (Batch = mehrere pages in einem Call).
Optionaler Body: Pauls O-Ton knapp, falls über die Felder hinaus etwas mitschwingt.
- write-then-tell: kurz bestätigen, was abgelegt wurde (Person · Thema · Valenz je
Eintrag) — kein Report. Bei erzwungener Anonymisierung der Hinweis dazu.
Low-stakes, interaktiv also anlegen, dann berichten. In einem geplanten/headless
Lauf (kein interaktiver Paul) nicht still schreiben, sondern die geparsten Einträge zur
Bestätigung vorlegen.
Modus 2: Prep
Trigger: „bereite mein Feedback für X vor", „Feedback-Prep X", „was habe ich zu X
notiert".
Ablauf:
- Offene Beobachtungen zu X lesen:
scripts/notion_query.py --db feedback --filter "Person=<Handle>" --filter "Status=Offen" --columns Person,Thema,Valenz,Situation,Verhalten,Wirkung,Feedback-Absicht,Workshop,Datum
(clientseitig auf den exakten Handle nachschärfen, falls contains mehr zieht).
- Gruppieren: erst nach Valenz (Stärken / Entwicklungsfelder), darin nach Thema.
- Ausgabe conclusion-first — der Spickzettel:
- Kopf: 1 Satz Gesamteindruck zu X über die offenen Beobachtungen.
- Stärken (2–3): je Punkt kurze Aussage + darunter das/die Beispiel(e) als
SBI (Situation → Verhalten → Wirkung), mit Workshop/Datum als Anker.
- Entwicklungsfelder (2–3): analog, jeder Punkt mit konkretem Beispiel; wo eine
Feedback-Absicht hinterlegt ist, sie als Anschluss mitgeben.
- Priorisieren, wenn es mehr als 2–3 pro Seite gibt — nicht alles ausschütten; die
tragenden Punkte zuerst, Rest als „außerdem notiert" knapp anhängen.
- Rohmaterial, keine fertigen Sätze. Paul formuliert im Gespräch selbst. Nur auf
Zuruf („formulier mir das") die Feedback-Sätze in Pauls Stimme drafen — dann
voice-core mitladen (bei schriftlichem Kanal zusätzlich voice-email).
- Nichts Offenes zu X → das ehrlich sagen (evtl. schon archiviert? auf Wunsch auch
archivierte Zyklen zeigen). Token/DB nicht verfügbar →
notion-fetch der Data Source
als Fallback; scheitert auch das, sagen statt raten.
Modus 3: Close
Trigger: „Feedback-Gespräch mit X geführt", „X abschließen", „Zyklus X archivieren".
- Offene Einträge zu X mit IDs holen:
scripts/notion_query.py --db feedback --filter "Person=<Handle>" --filter "Status=Offen" --ids.
- Vorlegen, was archiviert wird (Anzahl + Handle + Zyklus-Label) und bestätigen
lassen — erst dann schreiben.
- Je Eintrag
notion-update-page → Status: Archiviert (Zyklus-Label bleibt/wird
gesetzt, damit die Historie nach Zyklus lesbar bleibt).
- Kurze Bestätigung. Der nächste Zyklus für X startet automatisch sauber, weil neue
Beobachtungen wieder
Offen sind; die archivierten bleiben abrufbar.
Nie ohne explizite Bestätigung archivieren.
Memory / Lernen
Dieser Skill lernt nicht im Sinne der Memory-Schicht (_shared/memory-contract.md) —
kein Lern-Loop (Ton/Themenwert/Konstruktion), analog agent-lessons / agent-network /
agent-todo. Kein distill, keine memory/rules/, keine memory/logs/-Telemetrie.
Einzige Wahrheit ist die Notion-DB; aus memory/state/ wird nur notion-ids.json gelesen.
Haltung (gilt immer)
- Beispiel-Pflicht. Kein Feedback-Punkt ohne konkreten Anker (Verhalten). Fehlt er,
einmal nachfragen — sonst ist die Beobachtung wertlos.
- Anonym, ohne Ausnahme. Handle statt Name, keine Klienten/Projekte. Im Zweifel
kürzen und Bescheid geben.
- Prep ist der Kern. Der Spickzettel zur richtigen Zeit schlägt die vollständigste
Ablage. Conclusion-first, priorisiert, nicht alles ausschütten.
- Rohmaterial, nicht fertige Sätze — Paul spricht im Gespräch selbst; Formulierung
nur auf Zuruf, dann mit
voice-core.
- Paul entscheidet. Archivieren nur nach Bestätigung; der Skill legt vor, wertet die
Person nicht.
