agent-feedback-partner

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:

1. Abgrenzungstest (oben). Gehört es zu Network / Hacks / Outreach → dort hinweisen, nicht hier anlegen.
2. Aufsplitten: Diktat in einzelne Beobachtungen zerlegen, je Person/Moment eine.
3. 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.
4. 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.
5. Anonymisierung (oben) durchsetzen: Handle statt Name, keine Klienten/Projekte.
6. Anlegen via notion-create-pages (Batch = mehrere pages in einem Call). Optionaler Body: Pauls O-Ton knapp, falls über die Felder hinaus etwas mitschwingt.
7. 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:

1. 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).
2. Gruppieren: erst nach Valenz (Stärken / Entwicklungsfelder), darin nach Thema.
3. 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.
4. 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).
5. 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".

1. Offene Einträge zu X mit IDs holen: scripts/notion_query.py --db feedback --filter "Person=<Handle>" --filter "Status=Offen" --ids.
2. Vorlegen, was archiviert wird (Anzahl + Handle + Zyklus-Label) und bestätigen lassen — erst dann schreiben.
3. Je Eintrag notion-update-page → Status: Archiviert (Zyklus-Label bleibt/wird gesetzt, damit die Historie nach Zyklus lesbar bleibt).
4. 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.