fluent-korean: Ein Claude-Code-Output-Style gegen maschinelles Koreanisch

Ein Problem, das nur im Koreanischen so scharf auftritt

Sprachmodelle schreiben Koreanisch schlechter, als ihre allgemeine Leistung vermuten lässt. Das README nennt dafür einen konkreten Grund: Coding-Agenten werden darauf getrimmt, Token zu sparen und Kontextgrenzen einzuhalten, also knapp zu formulieren. Im Koreanischen ist Knappheit teuer. Wer Partikeln, Satzendungen und Funktionswörter weglässt, zerstört nicht Stil, sondern Bedeutung. Übrig bleibt eine telegrafische Substantivkette, die man erst rekonstruieren muss, um sie zu verstehen. Genau hier setzt das Projekt an. Die Zielgruppe ist eng umrissen: Wer Claude Code mit koreanischen Anweisungen füttert oder Artefakte erzeugt, die koreanischen Text enthalten, merkt den Unterschied sofort. Wer auf Deutsch oder Englisch arbeitet, hat keinen Anlass, das Plugin zu installieren. Das README behauptet nicht, ein Übersetzungswerkzeug zu sein. Es beschreibt eine Schreibdisziplin, die verhindern soll, dass der Fehler überhaupt entsteht.

Warum eine Vorab-Anweisung und nicht eine Nachbearbeitung

Das ist die eigentliche Designentscheidung des Projekts. Weil fluent-korean ein output-style ist, landet der Text im System-Prompt und wirkt, bevor das Modell formuliert. Die Nachbearbeitungsschule arbeitet umgekehrt: Sie lässt das Modell schreiben und korrigiert anschließend. Das README benennt diesen Unterschied selbst und verweist für den Korrekturansatz auf im-not-ai, korean-skills und den korean-humanizer aus k-skill. Das ist eine ehrliche Abgrenzung, keine Marketingzeile. Der zweite Teil der Begründung betrifft verkettete Systeme. Wenn mehrere Agenten oder ein Harness koreanische Zwischentexte austauschen, summiert sich der Qualitätsverlust über die Stufen. Aus einer unklaren Formulierung wird eine falsch verstandene Anweisung, und am Ende leidet das Arbeitsergebnis, nicht nur die Prosa. Eine Anweisung, die auf jeder Stufe von Anfang an gilt, greift an einer anderen Stelle als ein Korrekturfilter am Ende. Ob das in der Praxis zuverlässiger ist, lässt sich aus dem Repository allein nicht belegen. Das README räumt selbst ein, dass das Verhalten von der Situation abhängt.

Zwei Varianten und die Frage, ob Claude Code schreiben darf

Das Plugin liefert zwei Output-Styles. fluent-korean behält die Coding-Anweisungen und ist für Arbeiten gedacht, in denen Claude Code selbst Dateien ändert. fluent-korean-not-coding entfernt diese Anweisungen und ist für Fälle gedacht, in denen das Modell keinen Code anfassen soll. Die Trennung ist praktisch, weil sich sonst zwei Instruktionssätze gegenseitig verwässern. Die koreanische Schreibdisziplin und die Coding-Regeln konkurrieren um denselben Prompt-Platz, und je nach Aufgabe ist einer der beiden überflüssig. Wer den Style nur zum Schreiben von Texten nutzt, trägt sonst Coding-Regeln mit, die nie zur Anwendung kommen. Das README weist außerdem darauf hin, dass beide Varianten eine Klausel enthalten, die grob besagt: Was auf Englisch verfasst werden soll, wird nicht auf Koreanisch verfasst. Der Coding-Zweig enthält zusätzlich eine Regel, die Subagenten anhält, den Style zu befolgen, wenn der an sie gerichtete Prompt koreanisch ist. Das README sagt ausdrücklich, dass diese Klauseln je nach Situation unterschiedlich gut greifen und man sie im Zweifel selbst beobachten und anpassen muss. Das ist eine Einschränkung, die man nicht überlesen sollte.

Installation in Claude Code CLI

Das README nennt zwei Befehle, die direkt in Claude Code eingegeben werden: /plugin marketplace add snflkd/fluent-korean und danach /plugin install fluent-korean@fluent-korean. Anschließend wählt man im /config-Menü unter dem Punkt output-style eine der beiden Varianten. Weil Output-Styles beim Sitzungsstart geladen werden, greift die Änderung erst nach einer neuen Sitzung oder nach /clear. Das README empfiehlt einen ungewöhnlichen Weg, der zugleich als Anleitung für das Modell dient: Man solle dem gerade laufenden LLM die README-URL nennen und es bitten, die Installationsanleitung zu lesen und daraus die passende Vorgehensweise abzuleiten. Der Grund steht im Text selbst. Die richtige Anwendung hängt davon ab, in welcher Umgebung gearbeitet wird, ob mehrere LLMs im Spiel sind und ob man Agent, CLI oder App nutzt. Ohne diese Klärung lässt sich nicht sagen, welche Elemente überhaupt einzusetzen sind. Wer nicht über den Plugin-Weg gehen will, legt die md-Datei aus plugins/fluent-korean/output-styles/ direkt unter ~/.claude/output-styles/ oder .claude/output-styles/ ab. Das README nennt zwei Stolpersteine: Dateinamen und die Groß- und Kleinschreibung der Einstellungen, weil es Berichte über fehlgeschlagene Konfigurationen genau aus diesem Grund gibt, sowie die Tatsache, dass bei einer Plugin-Installation eigene Ergänzungen bei einem Update überschrieben werden können.

Feinsteuerung durch Textblöcke am Ende der Anweisung

Der interessanteste Teil des README ist eine Sammlung optionale Blöcke, die man an das Ende der Anweisung klebt. Sie sind als Auswahl gedacht, nicht als Paket. Ein Block für Einsteiger verlangt, Coding so zu erklären, dass Anfänger folgen können, und übertriebene umgangssprachliche Bilder zu vermeiden (im Original genannt: 박아넣다, 치우다, 얹다). Ein Höflichkeitsblock lässt Claude den Nutzer mit einer gewählten Anrede ansprechen und durchgängig Höflichkeitsformen verwenden, mit einem Vorher-Nachher-Beispiel im Text. Ein weiterer Block zielt auf Modelle, die zu seltenen, im Wörterbuch vorhandenen, aber ungebräuchlichen Wörtern neigen: Statt seltener Ausdrücke sollen geläufige mit klarer Bedeutung gewählt werden. Ein Block weitet die Anweisung auf alle koreanischen Ausgaben aus, nicht nur auf Berichte an den Nutzer. Ein Block nimmt stil sensible Arbeiten aus, etwa Roman, Drehbuch, Prüfungsaufgaben oder Forschung, und lässt bei Unklarheit nachfragen. Zwei weitere Blöcke erzwingen koreanisches Denken, Berichten und Ausgeben sowie eine Prüfung unmittelbar vor der Ausgabe. Das ist ein Baukasten für Prompt-Feinjustierung, und man merkt ihm an, dass der Autor die Schwachstellen aus eigener Nutzung kennt. Die Kehrseite: Wer viele Blöcke anhängt, verlängert den System-Prompt und verschärft das Token-Problem, das weiter unten beschrieben ist.

Was das Plugin nicht leistet

Das README beginnt den Abschnitt zu den Hinweisen mit dem Satz, dass es möglicherweise nicht so gut funktioniert, wie man es sich wünscht. Je vielfältiger die Anweisungen, je länger die Sitzung und je mehr priming-wirksamer Text im Kontext liegt, desto stärker diese Tendenz. Die Empfehlung des Autors ist bezeichnend: nicht die Anweisung selbst umschreiben, sondern das Harness so bauen, dass die Anweisung eingehalten wird. In seinem eigenen Aufbau nutzt er den Output-Style als Grundlage, greift bei wichtigen Artefakten auf eine Skill-artige Anwendung zurück und lässt im Harness vor der Fertigstellung eine adversarische Prüfung laufen. Wer das nicht aufsetzt, bekommt eine Anweisung, die im langen Kontext an Wirkung verliert. Zweitens kostet es Token. Das README sagt klar, dass mehr Nachrichtentoken anfallen, weil ausgelassene Satzteile und Morpheme rekonstruiert werden, und dass der Kontext dadurch stärker belegt wird. Dazu kommt der System-Prompt-Anteil in jeder Sitzung. Wer ohnehin an der Kontextgrenze arbeitet, sollte das einkalkulieren. Drittens ist die Anwendbarkeit außerhalb von Claude Code Handarbeit: Der md-Text muss selbst an der richtigen Stelle eingefügt werden, und das README empfiehlt ausdrücklich, die konkrete Platzierung mit einem LLM abzustimmen. Für das Verhalten von Subagenten gibt es keine Zusicherung, nur den Hinweis, selbst zu beobachten und nachzubessern.

Abgrenzung zu korean-skills, im-not-ai und k-skill

Die drei im README genannten Alternativen verfolgen einen anderen Ansatz, und der Unterschied liegt nicht im Umfang, sondern im Zeitpunkt. korean-skills, im-not-ai und der korean-humanizer aus k-skill wirken auf bereits erzeugten Text: Sie korrigieren Übersetzungsstil, reduzieren KI-typische Formulierungen, entfernen Rechtschreibfehler. fluent-korean wirkt davor und verhindert, dass diese Fehler entstehen. Das ist keine Frage von besser oder schlechter, sondern davon, ob man einen Nachbearbeitungsschritt in der Pipeline haben will. Ein Korrekturwerkzeug lässt sich auf beliebige Textquellen anwenden, auch auf Material, das nicht aus dem eigenen Claude-Code-Lauf stammt. Ein Output-Style ist an die Sitzung gebunden, in der er aktiv ist, und wirkt nur auf die Ausgaben dieses Modells. Wer koreanische Texte aus vielen Quellen prüft, braucht die Korrekturschicht. Wer die Qualität der eigenen Agentenausgaben dauerhaft heben will, greift früher an. Beides gleichzeitig zu betreiben ist möglich, aber das README warnt an anderer Stelle davor, das Harness zu überladen.

Pflege, Updates und Lizenz

Das Repository steht unter MIT. Das ist eine permissive Lizenz: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Copyright-Hinweis und der Lizenztext erhalten bleiben. Wer die md-Datei in ein eigenes Produkt einbettet, sollte diesen Hinweis mitführen. Rechtliche Beratung ist das nicht, im Zweifel gehört die Frage zu einer Rechtsabteilung. Zur Pflege: Die letzten Releases sind v.1.0.0 vom 10. Juli 2026, v.1.0.1 vom 18. August 2026 und v.1.0.2 vom 21. August 2026, der letzte Push datiert auf den 23. August 2026. Das Muster zeigt zwei Patch-Releases innerhalb weniger Tage nach der ersten Version, was auf schnelle Korrekturen nach dem ersten breiteren Einsatz hindeutet, mehr aber auch nicht. Wer das Plugin installiert, sollte die Update-Kosten einplanen: Eigene Block-Ergänzungen am Ende der Anweisung können bei einem Update überschrieben werden, und das README nennt das ausdrücklich als Warnung. Wer die Blöcke braucht, ist mit der manuellen Ablage unter ~/.claude/output-styles/ besser bedient, weil dann die eigene Datei die Quelle bleibt. Die Prinzipiendokumentation ist im README als in Arbeit markiert, ein Verweis auf ein Google-Dokument. Wer eine belastbare Erklärung erwartet, warum Modelle Koreanisch so behandeln, findet sie dort derzeit nicht abgeschlossen vor.

Redaktionelles Fazit

Adoptieren sollte es, wer Claude Code mit koreanischen Prompts betreibt und die Ausgabequalität vorab statt nachträglich steuern will, sowie alle, die in einer Kette aus mehreren Agenten arbeiten und dort keine kumulierenden Bedeutungsschäden wollen. Nicht geeignet ist es für Teams, die bereits einen Korrektur-Workflow mit korean-skills oder im-not-ai fahren, und für Nicht-Claude-Umgebungen, in denen niemand den md-Text selbst einsetzen will. Vor dem Einsatz zu prüfen: ob die Dateinamen und die Groß- und Kleinschreibung der Konfiguration stimmen, ob nach der Auswahl im /config-Menü eine neue Sitzung oder /clear nötig war, und ob die Subagenten-Klauseln im eigenen Harness tatsächlich greifen. Am Ende bleibt es eine Prompt-Disziplin, kein Parser: Wer sie nicht beobachtet, bekommt weiterhin das, was das Modell ohnehin produziert hätte.

Offizielle Quellen

1. Issues
2. License: MIT
3. README
4. Releases
5. snflkd/fluent-korean on GitHub