im-not-ai: Ein Claude-Skill gegen koreanische Übersetzungsprosa
AI가 쓴 한글을 사람 글처럼 윤문하는 Claude 스킬 — Korean AI-text humanizer: detects and rewrites translationese, mechanical parallelism, and 71 other AI tells
Auf einen Blick
- Was ist das?
- Der Skill humanize-korean erkennt 70 Muster, die koreanische LLM-Texte wie Übersetzungen klingen lassen, und schreibt sie span-genau um. Die Dokumentation nennt drei Aufwandspfade und ein hartes Änderungslimit von 50 Prozent.
- Für wen ist es gedacht?
- Wer regelmäßig koreanische LLM-Entwürfe für Redaktion, Report oder Produktkommunikation aufbereitet und Claude Code ohnehin im Terminal nutzt, bekommt mit humanize-korean einen prüfbaren, deterministisch begrenzten Arbeitsschritt statt eines Blackbox-Umschreibers.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 9 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem: Koreanisch, das nach Übersetzung klingt
Koreanische Texte aus ChatGPT, Claude oder Gemini sind selten falsch. Sie klingen nur falsch. Die README benennt die Ursache direkt: Die meisten AI-Spuren in koreanischen Texten stammen aus dem Englischen, also aus Übersetzungsprosa. Ein Satz wie "AI 기술을 통해 효율을 높일 수 있다" ist grammatisch einwandfrei und trotzdem kein Koreanisch, das ein Mensch schreiben würde. Die natürliche Form wäre "AI로 효율을 높인다". Dasselbe gilt für "이에 있어서 중요한 점은" oder für die Passivkonstruktion "~에 의해 생성된".
Genau hier setzt das Projekt an. Es ist kein allgemeiner Textverbesserer, sondern eine Mustersammlung für eine Sprache und eine Fehlerquelle. Die Zielgruppe sind Menschen, die koreanische LLM-Ausgaben weiterverwenden: Redakteure, Produktmanager, technische Autoren. Wer auf Deutsch oder Englisch schreibt, hat von diesem Werkzeug nichts, denn die Taxonomie ist auf koreanische Partikeln, Endungen und Übersetzungskonstruktionen zugeschnitten. Die README formuliert es als Abgrenzung: Englischsprachige Humanizer wie QuillBot, Hix oder Undetectable AI seien für Koreanisch schwach. Das ist eine Behauptung des Projekts, kein von mir nachgemessener Vergleich.
Sieben Kategorien, siebzig Muster, drei Schweregrade
Die Taxonomie ist das eigentliche Produkt. Sie liegt in zehn Hauptkategorien vor, von A bis J, mit insgesamt 70 Unter Mustern plus einem Eintrag im Status hold, also noch nicht freigegeben. Kategorie A heißt Übersetzungsprosa und enthält unter anderem "~를 통해", "~에 대해", "~에 있어서", doppeltes Passiv "~되어진다", das Zwangsmuster "가지고 있다" sowie die Einträge A-16 (erzwungene Verwendung von 그/그녀), A-18 (linksverzweigte Relativsätze) und A-19 (Doppelpartikeln wie "~에서의"). Kategorie C sammelt strukturelle AI-Muster, darunter das mechanische "첫째/둘째/셋째" und Aufzählungen, Überschriften und Emojis im Übermaß. Kategorie D listet die bekannten Floskeln "결론적으로" und "시사하는 바가 크다". Kategorie E betrifft den Rhythmus: geringe Standardabweichung der Satzlängen, wiederkehrende Satzendungen, Verlust der Konsistenz in der Höflichkeitsstufe (E-7). Kategorie J behandelt visuelle Dekoration, also übermäßigen Fettdruck, Anführungszeichen und Gedankenstriche.
Jedes Muster trägt einen Schweregrad. S1 bedeutet: Ein einziges Vorkommen verrät den AI-Ursprung, das Muster wird entfernt. S2 erlaubt ein bis zwei Vorkommen, ab drei Wiederholungen wird eingegriffen. S3 ist nur dann ein Problem, wenn es sich mit anderen Mustern überlagert. Diese Dreistufigkeit ist der Grund, warum das Werkzeug nicht einfach Synonyme tauscht: Es entscheidet zuerst, ob ein Fund überhaupt ein Fund ist. Die vollständige Liste liegt laut README in skills/humanize-korean/references/ai-tell-taxonomy.md, die zugehörigen Umschreibungsregeln in rewriting-playbook.md.
route_hint: der Aufwand richtet sich nach der Textqualität
Vor dem eigentlichen Umschreiben läuft ein Skript namens prepare_monolith_input.py. Es bewertet den Eingabetext quantitativ, nach Angabe der README anhand von KatFish- und post-editese-Metriken, und leitet daraus deterministisch einen von drei Werten ab: light, standard oder heavy. Dieser Wert heißt route_hint und bestimmt, wie viele LLM-Aufrufe folgen.
Bei light genügt ein einziger Aufruf von humanize-monolith. Diagnose und finalize entfallen, es wird konservativ umgeschrieben, und wenn kaum etwas zu tun ist, endet der Lauf früh mit der Rückmeldung, der Text sei bereits gut. Bei standard folgen zwei Aufrufe: zuerst humanize-diagnostician, der drei bis sechs dominante Muster der gesamten Textes mit Taxonomie-ID und Rezeptur benennt, dann ein gezielter Umschreibungsaufruf. Bei heavy kommen drei oder mehr Aufrufe zusammen: Diagnose, Umschreibung und abschließend humanize-finalizer, der den Text direkt gegen das Original prüft, fünfzehn Kriterien zur Bedeutungsbewahrung abarbeitet und lokal nachbessert. Chunking, also das Aufteilen langer Texte auf parallele Aufrufe, ist ausschließlich heavy vorbehalten und wird unter 15.000 Zeichen ausdrücklich nicht empfohlen.
Scheitert die Vorab bewertung, läuft der Prozess laut README ohne Punktzahl im standard-Pfad weiter. Eine Nutzeranweisung kann die Route übersteuern: "--strict" oder "정밀 모드" erzwingt heavy, "가볍게" erzwingt light. Nach allen Pfaden läuft verify_change_rate.py, ein deterministisches Gate, das die Änderungsrate per Exit-Code beurteilt. Das ist der architektonisch interessante Teil: Die Qualitätsgrenze liegt nicht im Prompt, sondern in ausführbarem Code.
Vier Regeln, die den Eingriff begrenzen
Die README nennt vier Grundsätze. Erstens Bedeutungsinvarianz: Fakten, Behauptungen, Zahlen, Eigennamen und wörtliche Zitate bleiben zu hundert Prozent erhalten. Zweitens Evidenzbindung: Geändert wird nur an erkannten Spans, alles andere bleibt unberührt. Drittens Genreerhalt: Aus einer Kolumne wird kein literarischer Text, aus einem Report kein Essay. Viertens ein Verbot der Überbearbeitung, und dieses Verbot ist beziffert. Überschreitet die Änderungsrate 30 Prozent, warnt das System. Überschreitet sie 50 Prozent, bricht es den Lauf ab.
Diese 50-Prozent-Grenze ist die wichtigste Zusage des Projekts, weil sie das Grundproblem jedes Humanizers adressiert: Ein Modell, das Stil entfernen soll, entfernt gern auch Inhalt. Ob die Grenze in der Praxis greift, hängt daran, wie verify_change_rate.py Änderungen zählt. Die README beschreibt das Verfahren nicht im Detail, und aus dem Repository-Auszug geht es ebenfalls nicht hervor. Wer das Werkzeug produktiv einsetzt, sollte diesen Zähler an einem eigenen Text mit bekannter Bearbeitung nachvollziehen, bevor er sich auf die Schranke verlässt.
Installation: vier CLI-Ziele, zwei Aufrufklassen
Unterstützt werden Claude Code, GitHub Copilot CLI, OpenAI Codex CLI und Gemini CLI, die vollständige Anleitung liegt in INSTALL.md. Für Copilot CLI läuft die Installation über den Plugin-Marktplatz ohne Klonen: copilot plugin marketplace add epoko77-ai/im-not-ai, dann copilot plugin install humanize-korean@im-not-ai, zur Kontrolle copilot plugin list. Aktualisiert wird mit copilot plugin update humanize-korean@im-not-ai, entfernt mit copilot plugin uninstall humanize-korean@im-not-ai. Für Claude Code sind die entsprechenden Befehle /plugin marketplace add epoko77-ai/im-not-ai und /plugin install humanize-korean@im-not-ai, aufgerufen wird danach mit /humanize-korean.
Der zweite Weg ist ein Klon plus Skript: git clone https://github.com/epoko77-ai/im-not-ai.git, dann cd im-not-ai und ./install.sh. Das Skript erkennt installierte claude- oder codex-Binaries und legt globale Symlinks an. Mit ./install.sh --claude-only oder --codex-only lässt sich das auf ein Ziel beschränken, ./uninstall.sh entfernt die Installation, ./update.sh prüft auf neue Versionen und führt git pull samt Neuinstallation aus, wobei --check nur erkennt statt zu installieren. In Claude Code heißt der Aufruf /humanize-korean, in Codex $humanize-korean.
Entscheidend ist eine Einschränkung, die in der README zweimal auftaucht: Copilot CLI und Codex CLI bieten nur einen einzigen Aufrufpfad. Die Mehrfachaufrufe mit Diagnose und finalize sind Claude Code vorbehalten. Wer also die heavy-Route mit Bedeutungsprüfung will, braucht Claude Code. Alles andere bekommt eine einzelne Umschreibung.
Wo das Werkzeug versagt
Die schwerste Einschränkung steht im Installationsabschnitt und ist leicht zu überlesen: Ohne Claude Code gibt es keine Diagnose und keine Abschlussprüfung. Der Nutzer erhält dann eine einzelne Umschreibung ohne die fünfzehn Prüfkriterien des finalizer. Für einen kurzen Blogpost mag das reichen. Für einen Text, in dem Zahlen oder Zitate vorkommen, ist es der schwächere Modus, und die README macht daraus keine Empfehlung, sondern eine Tatsache.
Zweitens die Sprache. Die Taxonomie ist koreanisch. Ein englischer oder deutscher Text, der durch den Skill läuft, trifft auf Muster wie "~를 통해" oder die Höflichkeitsstufen E-7, die es in dieser Form nicht gibt. Das Werkzeug ist für genau eine Sprache gebaut, und das ist keine Schwäche, sondern der Grund, warum es überhaupt funktioniert.
Drittens das Genre. Die Regel "장르 유지" verhindert, dass ein Report zum Essay wird, aber sie verhindert nicht, dass ein Text mit bewusst gesetzten Wiederholungen oder absichtlich gleichen Satzendungen als AI-Muster gelesen wird. Ein Manifest, ein Gedicht oder ein Text mit rhetorischer Anapher wird von einer Mustersammlung, die Wiederholung als Signal behandelt, falsch bewertet. Solche Texte gehören nicht in den Skill.
Viertens die Messgrundlage. Die Route beruht auf KatFish- und post-editese-Metriken, und die README nennt für den Chunking-Vergleich konkrete Tokenzahlen: 610K bei sieben Aufrufen gegenüber 134K bei einem einzigen, bei angeblich gleicher Qualität. Diese Zahlen stammen aus der Projektdokumentation, nicht aus einer unabhängigen Messung, und die Qualitätsgleichheit ist eine Behauptung der Autoren.
Was ein anderes Werkzeug anders macht
Der naheliegende Vergleich ist ein generischer Umschreibedienst wie QuillBot. Der Unterschied liegt nicht in der Modellqualität, sondern im Ansatz. QuillBot arbeitet sprachunabhängig und ersetzt Formulierungen durch Synonyme, ohne eine Theorie davon zu haben, warum ein Satz künstlich klingt. humanize-korean arbeitet umgekehrt: Es beginnt mit einer benannten Liste von 70 Mustern, ordnet jedem einen Schweregrad zu und ändert nur an den Stellen, die ein Muster treffen. Ein Paraphrasierer kann einen Satz verbessern, ohne den Grund zu kennen. Dieses Werkzeug kann den Grund nennen, weil die Muster-ID im Diagnoseschritt explizit ausgegeben wird.
Der zweite Unterschied ist die Kostensteuerung. Ein Paraphrasierer läuft immer mit demselben Aufwand über den gesamten Text. Hier entscheidet eine Vorab bewertung, ob ein Aufruf genügt oder drei nötig sind, und die README nennt das ausdrücklich die Kernverbesserung von v2.3: gut geschriebene Texte sollen mit einem Aufruf günstig durchlaufen, statt die schwerste Pipeline zu starten. Der Preis dafür ist eine Abhängigkeit: Wer die Route falsch schätzt, bekommt entweder zu wenig oder zu viel Bearbeitung, und die Korrektur ist ein manueller Schalter wie --strict.
Wartung, Lizenz und was vor dem Einsatz zu prüfen ist
Das Projekt steht unter MIT-Lizenz. Das erlaubt Weitergabe und Veränderung, solange Copyright-Hinweis und Lizenztext erhalten bleiben; für abgeleitete Werke entsteht keine Copyleft-Pflicht. Rechtlich verbindlich ist der Lizenztext selbst, nicht diese Zusammenfassung.
Die Versionshistorie ist eng getaktet. v2.3.0 erschien am 22. Juli 2026 und brachte laut Release-Titel Effizienzgewinne plus eine Validierung gegen ein Vergleichskorpus. v2.3.1 folgte am 18. August 2026 und befasste sich mit Pfadauflösung, Laufzeitgrenzen und Vertragskonsistenz. v2.3.2 am selben Tag korrigierte die Position des Plugin-Skills. Drei Releases, davon zwei am gleichen Tag, deuten auf aktive Pflege, aber auch auf eine Phase, in der Installationsdetails nachjustiert werden. Wer den Skill in eine Pipeline einbaut, sollte die Versionsnummer pinnen und ./update.sh beziehungsweise /plugin update nicht ungeprüft laufen lassen.
Eine strukturelle Eigenheit kommt hinzu: Im Verzeichnis agents/ liegen neben den vier produktiven Agenten fünf Werkzeuge, die laut README nur für die Release-Arbeit an v2.0 gedacht sind, darunter translationese-research-distiller und post-editese-metric-engineer. Sie sind nicht Teil der Umschreibung. Wer das Repository liest, sollte diese Trennung kennen, sonst hält er Entwicklungsballast für Funktionalität.
Vor dem ersten produktiven Lauf bleibt eine konkrete Prüfung: einen eigenen koreanischen Absatz durch /humanize-korean schicken und im erzeugten final.md nachsehen, ob die Änderungsrate unter 30 Prozent bleibt und ob Zahlen, Eigennamen und wörtliche Zitate unverändert dastehen. Das verify_change_rate.py-Gate liefert dafür den Exit-Code, die inhaltliche Kontrolle ersetzt es nicht.
Redaktionelles Fazit
Wer regelmäßig koreanische LLM-Entwürfe für Redaktion, Report oder Produktkommunikation aufbereitet und Claude Code ohnehin im Terminal nutzt, bekommt mit humanize-korean einen prüfbaren, deterministisch begrenzten Arbeitsschritt statt eines Blackbox-Umschreibers. Wer nur Copilot CLI, Codex CLI oder Gemini CLI einsetzt, erhält ausschließlich den Einzelaufruf-Pfad, also weder Diagnose noch finalize; für juristische, medizinische oder anderweitig haftungsträchtige Texte ist ein automatischer Stilumbau ohnehin das falsche Werkzeug. Vor dem ersten Produktiveinsatz sollte man einen eigenen Absatz durchlaufen lassen und im erzeugten final.md prüfen, ob die Änderungsrate unter der 30-Prozent-Warnschwelle bleibt und ob Zahlen, Eigennamen und wörtliche Zitate unangetastet sind.
Community-Notizen