Communitygithub.com

Banger-Detector – Authentizitätsprüfung und ehrliche Offenlegung

Dieses Skill überprüft die Authentizität von Texten, bewertet KI-Erkennungsscores kritisch und stellt sicher, dass Autoren transparent über den Einsatz von KI-Tools kommunizieren.

Was ist Banger-Detector – Authentizitätsprüfung und ehrliche Offenlegung?

Banger-Detector ist ein professionelles Skill für KI-Assistenten (z. B. Claude Code, Cursor, Codex), das die Authentizität von Textentwürfen überprüft und eine ehrliche Offenlegung des KI-Einsatzes fördert. Es klärt über die Grenzen von KI-Erkennungstools auf: Diese messen lediglich statistische Eigenschaften wie Perplexität und Burstiness, nicht die tatsächliche Autorenschaft. Studien zeigen, dass Detektoren Nicht-Muttersprachler und technische Texte systematisch falsch klassifizieren – der Skill warnt daher davor, Scores als Beweis zu werten. Stattdessen führt es sechs Authentizitätsprüfungen durch (z. B. Quellennachweis, Urteilsvermögen, echte Textur) und entscheidet, ob ein Detektor überhaupt eingesetzt werden sollte. Bei Verwendung wird ein Panel aus mindestens zwei Diensten empfohlen, wobei private Entwürfe niemals in Drittanbieter-Tools eingefügt werden dürfen. Der Skill verlangt, dass nur echte inhaltliche Mängel korrigiert werden – nicht der Score. Abschließend wird eine ehrliche, vom Autor genehmigte Offenlegungszeile vorgeschlagen. Der Fokus liegt auf wahrer Autorenschaft und Transparenz, nicht auf Tricksereien oder Score-Optimierung.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Jeff-Kazzee/bangers/tree/main/skills/banger-detector

In Ihrer bevorzugten KI fragen

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

Dokumentation

Was macht Banger-Detector – Authentizitätsprüfung und ehrliche Offenlegung?

Lesen Sie diesen gesamten Abschnitt, bevor Sie etwas ausführen. Die meisten Anfragen, die hier eingehen, fordern das falsche Ergebnis, und dessen Auslieferung würde den Text verschlechtern.

Was ein Detektor-Score ist – und was nicht

KI-Textdetektoren messen meist zwei statistische Eigenschaften: Perplexität (wie vorhersagbar jedes nächste Wort ist) und Burstiness (wie stark Satzlänge und -struktur variieren). Niedrige Perplexität und niedrige Burstiness werden als maschinengeneriert eingestuft.

Das ist ein Proxy für einen Stil, kein Beweis der Autorenschaft. Die Konsequenzen sind messbar und schwerwiegend:

  • Liang et al. (2023, Patterns) fanden heraus, dass Detektoren 61,3 % der Aufsätze von Nicht-Muttersprachlern fälschlich als KI-generiert markierten, während Aufsätze von Muttersprachlern nahezu perfekt klassifiziert wurden. 97,8 % der TOEFL-Aufsätze wurden von mindestens einem Detektor als KI-generiert eingestuft.
  • In derselben Studie senkte die Umschreibung von Nicht-Muttersprachler-Aufsätzen mit elaborierterem Vokabular die Falsch-Positiv-Rate von 61,22 % auf 11,77 %. Der Detektor maß also die Wortschatzbreite, nicht die Autorenschaft.
  • Technische, juristische und wissenschaftliche Texte werden aus demselben Grund markiert. Ein Fachgebiet verwendet zwangsläufig wiederkehrende Terminologie und Strukturen. Detektoren lesen diese notwendige Einheitlichkeit als maschinelle Ausgabe.
  • Jüngste formelle Arbeiten argumentieren, dass das Falsch-Positiv-Problem strukturell ist: Jeder rein textbasierte Detektor mit echter Erkennungsleistung muss bei bestimmten Bevölkerungsgruppen zu Falschbeschuldigungen führen. Bessere Technik beseitigt dies nicht.

Ein Detektor kann weder beweisen, dass ein Mensch etwas geschrieben hat, noch dass eine Maschine es tat. Behandeln Sie jeden Score als schwachen, adversariellen Hinweis.

Die für dieses Suite spezifische Falle

technical-clarity.md erzeugt bewusst kurze Sätze, ein Name pro Konzept, konsistente Struktur und einfaches Vokabular. Das ist von Natur aus niedrige Perplexität und niedrige Burstiness. Die korrekte Anwendung wird den KI-Score eines Entwurfs oft erhöhen, während sie den Text verbessert.

Lösen Sie diesen Konflikt niemals, indem Sie die Klarheit beschädigen. Wenn ein Text klar, belegt und wirklich vom Autor ist, ist ein hoher Detektor-Score ein Fehler des Detektors. Dokumentieren Sie dies und machen Sie weiter.

Schritt 1: Authentizität prüfen – kein Score

Diese Prüfungen entscheiden, ob ein Entwurf wirklich vom Autor stammt. Führen Sie sie zuerst durch, auch wenn kein Detektor verfügbar ist.

  1. Herkunft. Jede Zahl, jedes Zitat, jede Geschichte, jedes Datum, jedes Ergebnis und jedes benannte Detail führt zu einem echten Artefakt: einer Datei, einem Commit, einem Screenshot, einer Messung, einem veröffentlichten Beitrag oder etwas, das der Autor gesagt hat. Alles, was nicht belegbar ist, wird gestrichen, nicht abgeschwächt. Das ist die Prüfung, die wirklich zählt.
  2. Urteilsvermögen. Der Text trifft eine Entscheidung, die nur dieser Autor aus eigener Erfahrung treffen kann. Ausgewogene Zusammenfassung ohne Standpunkt ist das eigentliche Alarmzeichen.
  3. Echte Textur. Das konkrete Detail, das nicht generiert werden konnte: die genaue Fehlermeldung, was es gekostet hat, der Teil, der schiefging, die Sache, bei der der Autor seine Meinung geändert hat.
  4. Echte Variation. Der Satzrhythmus variiert, weil das Denken variiert, nicht weil Variation künstlich erzeugt wurde. Lesen Sie es laut vor.
  5. Einhaltung von Vorgaben. Die verbotenen Satzzeichen, Phrasen und Tonregeln des Autorenprofils sind eingehalten.
  6. Laut-Sprechen-Test. Würde der Autor diesen Satz so zu einem Kollegen sagen? Schreiben Sie jeden Satz um, den er nicht sagen würde.

Ein Entwurf, der alle sechs Prüfungen besteht, ist authentisch – unabhängig davon, was ein Detektor sagt.

Schritt 2: Entscheiden, ob überhaupt ein Detektor verwendet werden soll

Lesen Sie detector_mode aus dem Autorenprofil.

  • off – keinen ausführen.
  • requested – nur ausführen, wenn der Autor danach fragt.
  • panel – für nach außen gerichtete Prosa ausführen, wenn Detektorzugriff besteht. Wenn kein Zugriff besteht, not run notieren. Niemals andeuten, dass eine Ausführung stattfand.

Überspringen Sie Detektoren vollständig für private Entwürfe, interne Dokumente und alles, was der Autor nicht unter seinem Namen veröffentlicht.

Schritt 3: Das Panel ausführen

  • Verwenden Sie mindestens zwei unabhängige, derzeit zugängliche Dienste. Ein einzelner Score ist Rauschen.
  • Fügen Sie niemals private, unveröffentlichte oder vertrauliche Entwürfe in einen Drittanbieter-Detektor ein. Das ist eine Offenlegung von Material des Autors gegenüber einem externen Dienst. Fragen Sie jedes Mal vorher.
  • Dokumentieren Sie jede Ausführung in references/research/detector-runs.md: Datum, Eingabe-ID oder Hash, Dienst und Version, Ergebnis, Lokalisierung der hervorgehobenen Passage, der zugeordnete Schreibfehler, die Überarbeitung und das Ergebnis der Neuausführung.
  • Verwenden Sie für ein öffentliches Protokoll nur bereinigte Proben. Private Entwürfe gehören in ein privates Overlay.

Schritt 4: Hervorhebungen echten Mängeln zuordnen – oder aufhören

Ein Score löst niemals eine Neuschreibung aus. Fragen Sie bei jeder hervorgehobenen Passage, ob sie einem echten Mangel aus writing-quality.md entspricht:

  • generischer Einstieg, leere Überleitung oder dekorativer Schluss,
  • unbelegte Behauptung oder vage Autorität,
  • aufgereihte Dreiergruppen, symmetrische Absätze oder erzwungener Parallelismus,
  • Absicherungen oder atemlose Gewissheit,
  • Vokabular, das der Autor nie verwendet.

Überarbeiten Sie nur diese. Führen Sie einmal eine Neuausführung durch. Stoppen Sie nach zwei Detektor-getriebenen Durchgängen, egal was der Score sagt. Wahrheit, Klarheit, Rhythmus und authentische Stimme stehen über jedem Score.

Verbotene Handlungen

Diese schaden dem Werk und der Glaubwürdigkeit des Autors:

  • Einfügen von Tippfehlern, Grammatikfehlern oder holpriger Formulierung, um menschlich zu wirken.
  • Den Entwurf durch ein „Humanizer“-Tool laufen lassen.
  • Aufpolsterung mit Füllwörtern oder Synonymrotation, um die Perplexität zu erhöhen. Das führt genau das wieder ein, was das Suite entfernt.
  • Änderung einer wahren, klaren, authentischen Passage des Autors nur, um eine Zahl zu bewegen.
  • Präsentation eines Detektor-Scores als Beweis der Autorenschaft – in beide Richtungen.
  • Behauptung, dass Inhalte „KI-Erkennung bestehen“, als Funktion. Dies ist nicht verifizierbar, variiert je nach Dienst und Woche und lädt zu einer einfachen öffentlichen Widerlegung ein.

Schritt 5: Offenlegung

Offen über den Einsatz von KI-Assistenz zu sein, ist eine stärkere Position als jeder Score – und die einzige, die einer Überprüfung standhält.

Das Prinzip: Legen Sie den Prozess ehrlich dar und seien Sie spezifisch, was das Tool getan hat und was der Mensch. Leser haben nichts gegen die Verwendung von Tools einzuwenden. Sie haben etwas dagegen, getäuscht zu werden, wessen Denken sie lesen.

Was eine ehrliche Offenlegung abdeckt:

  • Die Meinungen, Urteile und Schlussfolgerungen stammen vom Autor.
  • Jedes faktische Detail wurde vom Autor gegen ein reales Artefakt verifiziert.
  • Der Autor übernimmt Verantwortung für Fehler.
  • Wo das Tool wirklich geholfen hat: Entwurf, Strukturierung, Bearbeitung, Rechercheunterstützung, Prüfung von Prosa gegen einen schriftlichen Standard.

Was zu vermeiden ist:

  • Behauptung „100 % menschlich geschrieben“, wenn ein Tool verwendet wurde. Ein Screenshot beendet das.
  • Ein pauschaler KI-Haftungsausschluss, der an alles angehängt wird und eher wie rechtliche Absicherung als Ehrlichkeit wirkt.
  • Übertreibung in die andere Richtung, die impliziert, das Tool habe das Denken übernommen, während der Autor es tat.
  • Die Offenlegung zum Thema des Textes machen, wenn sie eine Fußnote sein sollte.

Platzierung: Eine einfache Zeile, dort wo der Leser sie erwarten würde. In einer Autorenzeile, einer Autorennotiz, einer Repository-README oder einer Über-Seite. Nicht in jedem Absatz.

Formulieren Sie die Offenlegung in der Stimme des Autors, bieten Sie sie an und lassen Sie den Autor die Worte wählen. Veröffentlichen Sie niemals eine Offenlegung, die der Autor nicht genehmigt hat.

Ausgabeformat

Berichten Sie in dieser Reihenfolge:

  1. Die sechs Authentizitätsprüfungen, bestanden oder nicht bestanden, mit Angabe der fehlgeschlagenen Prüfungen.
  2. Detektor-Durchläufe: Dienst, Datum, Ergebnis oder not run mit Grund.
  3. Hervorgehobene Passagen, die einem echten Mangel zugeordnet wurden, und die vorgenommene Überarbeitung.
  4. Hervorgehobene Passagen, die verworfen wurden, und warum.
  5. Der vorgeschlagene Offenlegungssatz, falls der Text einen benötigt.
  6. Was noch der Zustimmung des Autors bedarf.

Melden Sie niemals einen Score ohne das dazugehörige Authentizitätsergebnis. Der Score ist das schwächere Signal und darf niemals als Schlagzeile präsentiert werden.

Individual skills in this repo

This repo contains 11 individual skills — each has its own dedicated page.

Verwandte Skills