CommunitySchreiben & Editierengithub.com

TsekaLuk/objectivize

Verwandle interne Notizen in objektive Analysen für die externe Veröffentlichung – eine wasserförmige Claude-Fähigkeit.

Was ist objectivize?

Diese Claude-Fähigkeit (Skill) wandelt interne, subjektiv gefärbte Notizen in objektive, für die Öffentlichkeit bestimmte Analysen um. Statt eines starren Templates bietet sie einen flexiblen, wahrnehmungsbasierten Ansatz: Zuerst wird die spezifische subjektive Färbung eines Dokuments erfasst (z. B. namentliche Nennung interner Rollen, direkte Ansprache des Lesers, Spekulation als Fakt), dann wird eine maßgeschneiderte Überarbeitung vorgenommen. Der Skill betont die Unterscheidung zwischen subjektiver Einfärbung („Leckage“) und tatsächlichen Beweisen (Zitate, Daten) – letztere bleiben unangetastet, erstere werden umformuliert. Er enthält klare Anleitungen zur Perspektivenwahl, konsistenten Begriffswahl und Skalierung bei mehreren Dokumenten, sowie eine Selbstprüfliste. Der Skill ist für Claude Code oder ähnliche KI-Assistenten konzipiert und folgt dem Prinzip „Form follows Function“ – jede Überarbeitung ist einzigartig.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add TsekaLuk/objectivize

Installed? Explore more Schreiben & Editieren skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

objectivize – Aus internen Notizen öffentliche Dokumente machen

Sie laufen keine Ersetzungstabelle für sensible Begriffe. Jedes Dokument „leakt“ auf seine eigene Weise – erfassen Sie zuerst die spezifische subjektive Färbung dieses einen Dokuments, dann lassen Sie die Überarbeitungsmethode damit isomorph sein. Form follows Function.

Die folgenden Kategorien sind Funken, keine Checkliste: Fehlt eine, erzwingen Sie sie nicht; gibt es mehr, benennen Sie sie spontan. Behandeln Sie diese Anleitung selbst wie Wasser – lesen Sie sie nicht wie eine Vorlage.

Eins: Erst erfassen, dann handeln (nicht überspringbar)

Lesen Sie einmal durch und beantworten Sie drei Fragen: An wen richtet sich das Dokument, aus wessen Perspektive ist es geschrieben, welche Dinge sind nur für Insider verständlich? Klassifizieren Sie die Leckstellen mit Ihren eigenen Worten. Häufige Lichtstrahlen:

  • Namentlich genannte Insider-Rollen – Chef/Vorgesetzter/Auftraggeber/Wir/Die Anderen … Externe Leser müssen nicht wissen, wer das ist.
  • Ansprache in der zweiten Person – „Sie sollten/Sie werden/Denken Sie daran“ – das behandelt den Leser wie einen Teamkollegen und riecht nach Memo.
  • Vermutung als Tatsache dargestellt – Spekulation über die „versteckten Erwartungen/wahren Motive/Loyalität“ einer Person, die aber wie bekannt geschrieben ist.
  • Die vierte Wand durchbrechen – Selbstbezüge wie „Dieses Dokument/Diese Antwort/Wir diesmal/Transkriptanalyse“, die den Produktionsprozess offenlegen.
  • Insider-Jargon und Lagermentalität – Interne Abkürzungen, Parteinahme, interne Witze.
  • Prozess-Metakommentare – Erläuterung, wie etwas entstanden ist (welches Tool/welche Besprechung/welcher Prozess).

Das Ergebnis ist eine für dieses Dokument spezifische Leckkarte, keine allgemeingültige Regel. Für das nächste Dokument zeichnen Sie neu.

Zwei: Unterscheiden zwischen „Leckage“ und „Beweis“ (Herz dieser Fähigkeit)

Der häufigste Fehler bei der Objektivierung ist, auch Beweise zu löschen oder echte Daten zu ändern – das ist nicht Objektivität, sondern Verfälschung oder sogar Fälschung. Das einzige Kriterium: Ist es eine beobachtete Tatsache oder der Tonfall des Autors? Tatsachen bleiben, Tonfall wird geändert.

  • Direkte Zitate = Beweis, behalten (können neutral attribuiert werden). Die Aussage eines Befragten „Software fasse ich nie an“ bleibt, da sie die Argumentation stützt.
  • Wiedergabe in der ersten Person = Leckage, umschreiben. „Gib mir keine Luftschlösser“ ist eine Vertonung für jemand anderen → „Es wird gefordert, dass der Plan nachvollziehbar ist“.
  • Echte Daten sind heilig – Nutzerkommentare, Logs, Statistiken, Screenshots-Originaltext. Selbst wenn genau das zu bereinigende Wort in den Daten erscheint, ändern Sie es auf keinen Fall: Es zu ändern wäre eine Verfälschung von Beweisen. (Wahre Lektion: In einer negativen Nutzerbewertung stand „Chef“ – das muss originalgetreu bleiben.)

Drei: Umschreiben, nicht löschen

Tauschen Sie den Rahmen, nicht den Inhalt. „Die wahren Absichten des Chefs“ → „Projektabsichten“: Die Perspektive ist weg, die Information bleibt. Wenn Sie einen Satz löschen wollen, fragen Sie zuerst: „Welches Urteil/welche Tatsache trägt er?“, und lassen Sie diesen Teil in neutraler Formulierung stehen.

Vier: Einen Spiegel festlegen und durchgängig verwenden

Legen Sie zuerst eine externe Perspektive fest (wer gibt vor, dieses Dokument zu sein und an wen richtet es sich?), weisen Sie jeder internen Rolle eine neutrale Bezeichnung zu, und vereinheitlichen Sie sie dann im gesamten Dokument.

  • Verwenden Sie nicht drei verschiedene Begriffe für dieselbe Person (Projektpartei/Anforderungssteller/Entscheider) – der Leser denkt, es seien drei verschiedene. Die Reihenfolge ist: erst Bezeichnung festlegen → dann Ersetzung durchführen → zuletzt auf Konsistenz prüfen.
  • Auch das „innere Skelett“ eines Abschnitts muss ausgetauscht werden: Verwandle Überschriften wie „Was er gesagt hat / nicht gesagt hat / warum er es so gesagt hat“ (eine Art „jemanden nachbesprechen“) in solche mit „objektiver Analyse“ (Bereits getroffene Entscheidungen / blinde Flecken und Ungeklärtes / tiefere Motive und Einschränkungen). Die Struktur soll mit dem Analyseobjekt isomorph sein, nicht mit dem Meeting.

Fünf: Objektiv ≠ falsche Zuversicht

Subjektivität zu entfernen bedeutet nicht, auch „Konfidenzgrad/Einschränkungen/Zweifel/Ebene der Schlussfolgerungen/Bedarf an praktischer Überprüfung“ zu glätten. Gerade diese ehrlichen Markierungen sind Kennzeichen von Objektivität – behalten Sie sie.

Sechs: Disziplin bei Skalierung (bei Bearbeitung eines ganzen Satzes von Dokumenten)

  • Begriffsvereinheitlichung kann skriptbar sein, aber das Wörterbuch wird jedes Mal neu erstellt – Erfassen Sie zuerst die für diese Charge spezifische Menge an Bezeichnungen, dann schreiben Sie die Ersetzung für diese Charge; übernehmen Sie nicht die Tabelle des vorherigen Projekts.
  • Nach mechanischer Ersetzung muss auf Nebenwirkungen geprüft werden – Längere Begriffe vor kürzeren ersetzen, sonst entstehen Krüppelwörter wie „wurde bereits wurde“ oder „Anforderungsstelleranforderungssteller“; durchsuchen Sie mit grep nach Resten und Deformationen.
  • Rahmen, Diktion, zweite Person usw. können nur von Hand Satz für Satz bearbeitet werden – Skripte kommen da nicht ran.
  • Nachgelagerte Produkte müssen neu erstellt werden – Wenn die Quelle geändert wurde, müssen auch das gerenderte HTML/PDF, das Inhaltsverzeichnis, das Deckblatt neu generiert werden – ändern Sie nicht nur die Quelle.

Selbstprüfung: Stellen Sie sich vor, das fertige Produkt wird von einem Fremden auf einer öffentlichen Plattform gelesen

  • Gibt es noch Wörter wie „du/wir/der andere/der Chef“, die den Leser oder Insider einbeziehen (außer in Zitaten)?
  • Wurde eine Vermutung als Tatsache dargestellt? Wurde offengelegt, „wie das erstellt wurde“?
  • Hat dieselbe Rolle im gesamten Dokument die gleiche Bezeichnung?
  • Sind echte Daten und direkte Zitate unverändert geblieben?
  • Sind Konfidenzgrad und Einschränkungen noch vorhanden?

Wenn auch nur eine Bedingung nicht erfüllt ist, gehen Sie zurück zu Schritt eins – aber denken Sie daran: Jedes Dokument erfordert eine andere Vorgehensweise. Machen Sie auch diese Selbstprüfliste nicht zu einer neuen Vorlage.

Verwandte Skills