fluent-korean ships two output styles and admits the prompt is not what fixes it

Three named failure modes instead of a general complaint

The project's argument is specific about what goes wrong. Recent models are not good at Korean, and coding agents configured to be concise in order to reduce token use and cope with context limits are worse at it. The guideline names three failure modes to correct: dropped particles and endings, telegraphic noun strings, and metaphor-swapped vocabulary. It states its own priority as clear, unambiguous meaning over elegant prose, with reasonably natural sentences as the goal rather than ornate ones. The before and after samples come from the same model on the same prompt, and a parenthetical notes that they were produced without context pressure in a clean context, so in practice the degradation is worse than the sample shows. The authorship is stated plainly too: the Korean parts of the README were written by hand by a Korean language and literature major and then revised with AI consultation.

The README hands its own installation to a model

The recommended install path is a single sentence addressed to whatever model you are already using, with the repository link in it: read the README at that link, read the install paragraph, and explain how to install and use it. That sentence appears twice, once at the top and once as step zero of the install section. The paragraph that follows is doing two jobs, and says so: it is guidance for you, and it is also the script the model should follow when explaining installation to someone else. Four considerations are spelled out. Identify which environment is running the model, since you may be using several models across an agent, a CLI and an app, and the scope has to be defined before anything is installed. Gather the purpose of the work and the situation of the person installing. Calibrate the explanation to their level, explaining more if they look new to development and asking instead when it is unclear.

Two slash commands, and the change waits for the next session

The direct path is two commands typed into Claude Code:

/plugin marketplace add snflkd/fluent-korean
/plugin install fluent-korean@fluent-korean

Note the doubled name. The marketplace reference and the plugin name are both fluent-korean, which is why the install argument reads as plugin at marketplace. After installing, the output style is chosen from a menu such as `/config`, and then the third step is the one people miss: because of how output styles work, selecting one has no effect until you start a new session or run `/clear`. The install notes add a second trap for people who skip the plugin entirely and copy files: file names and the letter case of settings have to match, and cases of the configuration simply not taking effect have been reported for exactly that reason. The project also warns that editing an installed markdown file by hand risks having it overwritten when the plugin updates.

Two variants that differ only in whether coding instructions survive

The plugin carries two output styles. `fluent-korean` keeps the coding instructions and is meant for coding work. `fluent-korean-not-coding` has them removed and is meant for the case where Claude should not be changing code directly. Installing is not the only route. The underlying principle is that you take the markdown file you want from the plugin's output-styles directory and insert its body wherever instructions are read, and that also works inside Claude Code if you drop the file into the user directory `~/.claude/output-styles/` or the project directory `.claude/output-styles/` instead of installing the plugin. Note that neither of those paths is where the plugin manifest lives, which sits in a `.claude-plugin` directory at the repository root. For a CLI user who does not want to reselect the style each time, the same guidance says to set the `outputStyle` value in `settings.json` or `settings.local.json` so it becomes the default.

Four environments answered, and one has no menu for it

Because the application method differs by environment, the README hands the conversation to a model and then answers the common cases. For chat and co-work in the Claude web page or desktop app, the answer is personal instructions added in the settings, with the markdown body pasted into the profile or general tab for chat, the collaboration tab for co-work, and project instructions if it should apply to one project only. For people who are not developers and never open Claude Code, that is the whole story. For Claude Code running inside the Claude desktop app, the answer is a negative one: the config menu has no output-style entry, so the text has to go into CLAUDE.md, settings.json or settings.local.json instead. For a CLI where the style should apply without being chosen each time, the outputStyle setting makes it the default. For anything that is not Claude at all, the instruction is to use the guideline text appropriately and to discuss it with the model.

Seven optional blocks, and one of them switches the rules off

The fine-grained section works as a menu: pick what you want and append the block text to the end of your instruction, to the end of the markdown body if you placed the file yourself, or to the end of any instruction text you are using instead of a file. Seven blocks are offered. Describe coding for a beginner and avoid overly situational colloquialisms, with three example verbs named. Address the user formally, never in banmal, with the block containing a rewritten sample sentence that converts a plain question into polite form. Avoid low frequency vocabulary even when it is in the dictionary and unambiguous, because that lowers communication efficiency, which is the block aimed at Opus and Fable. Apply the rules to every Korean output rather than only reports. Think in Korean, report in Korean, output in Korean. And check the guidelines against the answer immediately before printing it. The seventh block cuts the other way: output types that have their own style instructions, such as novels, scripts, exam questions and research, are excluded, and the instruction says to ask the user when it is ambiguous.

The caveat section says the harness is what usually fails

The most useful paragraph is the first caveat, and it is an admission rather than a sales point. The style may not take hold as much as you want. The more varied your instructions, the longer the task runs, and the more priming-inducing text it contains, the stronger that tendency becomes. The recommended response is not to edit the instructions but to configure and optimize the harness so it enforces the style effectively. The maintainer describes their own setup: output-style as the base, promoted to something like a Skill for the main deliverables when the style is not holding, and a harness configured to run adversarial validation before producing a result. Two smaller costs and caveats follow. Token use rises a little, because omitted sentence elements and morphemes are restored, raising both message tokens and context occupancy, plus a small addition to the system prompt in every session. And subagent behaviour has to be checked case by case, since the coding variant has a clause extending the style to subagent prompts in Korean and both variants forbid writing in Korean what should be written in English, but how well those clauses hold varies a lot.

An unfinished principles document and three disagreeing tags

The explanation of why models write Korean badly, how badly, why it is hard to correct and how correction works is delegated to a principles document, linked twice and marked as in progress both times. The same section makes a point about consistency: so that vocabulary priming could be tuned, the prompt body of the output style was itself written to follow those instructions as carefully as possible, and this README follows them only slightly. Three sibling projects are named for the adjacent job this one declines to do, covering translationese correction, minimising AI expressions and removing spelling errors. The version tags disagree with each other: the newest two are v.1.0.2 and v.1.0.1, with a dot between the v and the number and no release name, while the first is v1.0.0 with no dot. All three arrived within six weeks. The repository holds four top level entries and no detected primary language, which fits a project whose entire payload is markdown, and its closing line, an invitation to suggest better installation methods, stops mid sentence.

Editorial conclusion

fluent-korean fits a Korean-speaking developer or writer who wants clearer model output in Claude Code and is willing to add the guideline text as a project or personal instruction file. It does not fit creative work, since the guideline excludes output types that carry their own style instructions, and it does not fit anyone who edits the installed markdown by hand, because a plugin update can overwrite it. Verify four things before relying on it: that you start a new session or clear after selecting a style, that the file name and letter case match what the loader expects, that your subagents actually receive the Korean clause, and that your harness has some check of its own, since the maintainer's own remedy is adversarial validation before the result is produced.

Frequently asked questions

Official sources

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