A Claude Code plugin that attempts to fix Claude's terrible writing style

Files
README.md

Manual of Style #

As of Opus 5: do you hate how Claude writes? Yes, me too. This plugin provides a set of rules, distilled from different sources, that provide a very uniform, easy to parse style to the agent. These rules mostly suppress that "voice" the default agent has, and that we have come to associate to AI slop (and in recent models, to extremely convoluted writing). The rules favour a form of text that feels slightly robotic but it's much easier to understand, and the agent has instructions to help that visual parsing using markdown formatting. It features shorter sentences, simpler words and reduced jargon, and bold sentences that serve as a quick visual summary of the answer.

Install #

/plugin marketplace add https://tangled.org/diego.codes/manual-of-style/raw/main/.claude-plugin/marketplace.json
/plugin install manual-of-style@manual-of-style

The hook runs on your next prompt. No restart is needed. To turn it off, you can create the off switch. The hook then prints nothing.

touch ~/.claude/.manual-of-style-off

Delete that file to turn the plugin on again. To remove the plugin, run /plugin uninstall manual-of-style.

Before and after #

The same three questions, asked with and without the plugin. Both answers are reproduced exactly as the agent returned them, including the formatting.

What is a large language model? #

Without the plugin

A large language model (LLM) is a neural network trained on very large amounts of text to predict what comes next in a sequence. Practically, that means:

The architecture. Nearly all modern LLMs are transformers. Text is split into tokens (word fragments), each token becomes a vector, and stacked layers of self-attention let every token's representation be influenced by the others — that's how the model builds context-sensitive meaning rather than treating words in isolation. "Large" refers to parameter count (billions to trillions) and training data size (trillions of tokens).

The training. Pretraining is self-supervised: hide the next token, ask the model to guess it, adjust the weights. No labels needed, which is why the whole web can serve as a corpus. Post-training then shapes the raw predictor into something useful — supervised fine-tuning on demonstrations, plus reinforcement learning from human or AI feedback to make it helpful, honest, and safe. Increasingly there's also RL on verifiable tasks (math, code) that teaches extended reasoning.

Why it works better than it sounds like it should. Next-token prediction seems shallow, but predicting text well at scale requires internalizing grammar, facts, styles, reasoning patterns, and rough world models. Capabilities like translation, summarization, and coding emerge from scale and data rather than being explicitly programmed.

The limits worth knowing. LLMs are probabilistic, not lookup tables, so they can produce fluent, confident falsehoods (hallucination). Their knowledge is frozen at a training cutoff unless given tools or retrieval. They have a finite context window. And they have no persistent memory between conversations by default — each session starts fresh.

Examples include Claude, GPT, Gemini, and Llama. The same base technology now underpins chat assistants, coding agents, and tool-using systems that call APIs and act on their results.

With the plugin

A large language model is a computer program that predicts text. The program reads a sequence of words and produces the word that most probably comes next. This single operation, repeated many times, produces every answer the model gives. The program learns the probabilities from a large collection of text, such as books, articles, and web pages. The word "large" names the size of two things: the collection of text, and the set of internal numbers, called parameters, that the program adjusts during this learning.

The parameters hold the knowledge. A model has billions of parameters, and each one is a number that shapes how the program moves from the input words to the next word. The training process does not store the source text, so the model cannot look up a fact the way a database does. Instead, the training process spreads patterns from the text across the parameters. The model reconstructs a fact from those patterns, and this reconstruction explains a common failure: the model states a wrong fact with the same confidence as a right one.

The prediction method sets the limits of the result. A model that only predicts the next word has no method to check a claim against the world. The alternative design is a system that queries a fixed database, which gives correct answers but only for the questions the designer anticipated. A language model answers questions nobody anticipated, and it pays for that range with the risk of a confident error. Engineers reduce the risk with two additions: a search tool that gives the model real documents, and a training stage where people rate answers and the ratings adjust the parameters.

What is an offside in football? #

Without the plugin

Offside is a rule that stops attackers from camping behind the last defenders.

A player is in an offside position if, at the moment a teammate plays the ball to them, they are in the opponent's half and any part of their body they can score with (head, body, feet — not arms or hands) is closer to the opponent's goal line than both the ball and the second-to-last opponent (usually the last outfield defender, since the keeper is normally the last).

Being in that position is not an offence in itself. It only becomes an offside offence — punished with an indirect free kick from where the player was — if, when the ball is played by a teammate, that player then gets involved: playing or touching the ball, interfering with an opponent (blocking their line of sight, challenging them, or making an obvious action that affects their ability to play), or gaining an advantage from a rebound off the post, crossbar, an opponent, or a deliberate save.

Key exceptions:

  • No offside if the player is in their own half, or level with the second-to-last opponent or level with the ball.
  • No offside directly from a goal kick, corner kick, or throw-in.
  • No offside if the ball is received directly from an opponent's deliberate play (a deliberate pass or clearance resets it), though a deliberate save does not.
  • The position is judged at the moment the ball is played by the teammate, not when it is received — so a player can be onside when the pass is struck and legally run beyond the defence.

VAR reviews this with frozen frames and calibrated lines; several competitions now use semi-automated offside technology, and some (including the Premier League) have moved to a "thicker line" tolerance so only clear daylight counts.

With the plugin

An offside is a rule in football that stops an attacker from waiting near the opponent goal for a pass. A player is in an offside position when they are in the opponent half and nearer to the goal line than both the ball and the second-last defender. The second-last defender is usually a defender, because the goalkeeper is normally the last one. The position alone is not an offence. The referee judges the position at the moment a teammate touches the ball, not at the moment the player receives it.

The offence happens when a player in an offside position joins the play. A player in an offside position commits an offence only when they touch the ball, block an opponent, or gain an advantage from their position. A player who stands still and stays away from the ball is not punished. The punishment is an indirect free kick for the defending team at the place of the offence. This rule keeps the attackers and the defenders close together, and it makes the game a contest for space.

Three cases give no offence at all. A player who receives the ball direct from a throw-in, a corner kick, or a goal kick is never offside. A player in their own half is also safe. A player level with the second-last defender is level enough to count as onside.

What is a roux in cooking? #

Without the plugin

A roux is a cooked mixture of equal parts (by weight) fat and flour, used as a thickener in sauces, soups, and stews. The fat is typically butter, but can be oil, lard, or drippings; the flour is stirred in and cooked to remove the raw-starch taste before liquid is added.

It's the base of the classic French mother sauces — béchamel (roux + milk), velouté (roux + stock), and espagnole (brown roux + brown stock) — and of dishes like gumbo, mac and cheese, and gravies.

Roux is classified by how long it's cooked:

  • White (a few minutes): pale, maximum thickening power. For béchamel.
  • Blond (roughly 5–10 minutes): light golden, faintly nutty. For velouté and cream soups.
  • Brown / dark brown (20 minutes to over an hour): deep color, rich toasted flavor, but progressively less thickening power as the starch breaks down. Essential to Cajun and Creole cooking, especially gumbo.

Practical notes: cook it in a heavy pan over medium-low heat, stirring constantly — dark roux burns easily and scorched roux must be thrown out. To avoid lumps, combine hot roux with cold liquid or cold roux with hot liquid, adding gradually while whisking. A rough guide is about 2 tablespoons each of butter and flour per cup of liquid for a medium-thick sauce. Roux keeps well refrigerated or frozen, so many cooks make dark roux in batches ahead of time.

With the plugin

A roux is a cooked mixture of equal parts fat and flour, and it thickens a sauce or a soup. The roux works because heat coats each starch grain in fat, which stops the grains from clumping when liquid arrives. A cook melts butter in a pan, stirs in the same weight of flour, and cooks the paste while stirring. The starch in the flour then swells in the hot liquid and holds it as a smooth, thick sauce. Flour thrown into liquid alone forms lumps, because the outside of each lump gels first and seals the dry flour inside.

The cooking time decides both the color and the thickening power, and the two move in opposite directions. A white roux cooks for about two minutes and stays pale, and it thickens the most. A blond roux cooks for about five minutes and gets a light gold color with a nutty smell. A brown roux cooks for 15 minutes or more, turns the color of dark copper, and gives a deep toasted taste. The long heat breaks the starch chains into smaller pieces, so a brown roux thickens about half as much as a white roux at the same weight.

One part roux to ten parts liquid gives a pouring sauce, and one part to five gives a thick coating sauce. Add the liquid to the roux in stages and beat the mixture after each stage. Many cooks keep one of the two parts cold and the other part hot, because a large temperature gap helps the mixture stay smooth. Cook the finished sauce for two more minutes to remove the raw taste of the flour. A white roux with milk makes béchamel, and a brown roux with stock makes the base of a gumbo, a stew from Louisiana.

User hook #

This plugin uses the UserPromptSubmit hook, which injects the rules in every user prompt. The rules accumulate, which forces the model to follow them. They do not dilute over a long session, as a custom output style can.

The rules live in rules/core.md, between <!-- CORE:START --> and <!-- CORE:END -->. Edit that block. The change applies on your next prompt, because scripts/emit-core.sh reads the file each time the hook runs.

Two limits apply. Hook output is capped at 10,000 characters, and past that cap Claude Code writes the text to a file and injects a preview instead, which would remove your rules without telling you. The script refuses to emit a block over 8,000 bytes for that reason.

The second limit is cost. The block costs 620 to 730 tokens on every prompt, and each prompt adds another copy to the conversation. A 200-turn session spends roughly 145,000 tokens on repeated copies of the same rules.

Coding hook #

The style rules above cover prose. Code is handled the other way round: the hook injects no rules at all, only a one-sentence pointer at the skill that holds them.

PreToolUse fires on Edit, Write, and NotebookEdit. The script reads the file path from the payload and injects one line when the extension is code:

[coding] Load `Skill(manual-of-style:coding)` before you decide how to structure
this code, unless you already loaded it in this session.

The pointer goes in on every code edit, and that repetition is the point. A pointer is small enough — about 30 tokens — that sending it every time costs less than the bookkeeping needed to send it once. Repetition also survives a compaction with no extra hook, and it puts the skill in front of the agent at the moment it decides how to structure code rather than at session start.

The reminder does not name the language, because the agent already knows it. It just issued an Edit call with the file path, so a line saying "Editing Python" returns information the agent supplied one step earlier. The script reads the extension for one purpose only: to decide whether the file is code. That check is what keeps a Markdown note, a JSON config, or a CSV from firing the hook.

The trade in this design is real and worth naming. A pointer is a request the agent can decline, while an injected rule applies whether the agent cooperates or not. It is far stronger than a skill listing the agent skims once, because it arrives when it applies. It is still softer than delivery, and that is the price of keeping the per-edit cost at one line.

The hook returns additionalContext alone and never returns a permissionDecision. Returning allow would skip the permission prompt on every Edit and Write, which is a far larger change than injecting a reminder.

The reminder text lives in rules/coding.md between <!-- REMINDER:START --> and <!-- REMINDER:END -->. The extension list is CODE_EXTENSIONS in scripts/emit-coding.py, and it covers about a hundred extensions across every common language.

The rules live in skills/coding/SKILL.md, which holds an Always section that applies to every language and an index of the files beside it. The Always section covers the ladder for deciding what to build, naming, comments, guard clauses, levels of abstraction, exception handling, the list of things never trimmed, and the smells that generated code produces most often.

Two kinds of file sit under skills/coding/references/. A language file — Python, SQL, JavaScript and TypeScript, shell — holds the rules for one language. A topic file holds material that applies across languages: design.md for shaping modules and types, testing.md for choosing and writing tests, and refactoring.md for changing shape without changing behaviour. The two topic files cross-reference each other, because a refactor needs a safety net and a characterization test is how you build one.

That split keeps a load to the Always section plus what the work calls for. The whole body is 28 KB, and a typical edit reads the Always section and one language file, about 1,700 tokens. Nothing charges you for the topics until the work matches them.

Add a language by writing skills/coding/references/<name>.md, adding a row to the index in SKILL.md, and adding its extensions to CODE_EXTENSIONS if they are not there already.

Sources and previous work #

This is a not comprehensive list of resources that I have used to distill this style. Besides this, there are some rules that simply adhere to my personal preference on reading these kind of outputs.

Language and sentences

  • ASD-STE100 Simplified Technical English, Issue 9. A controlled language for aircraft maintenance manuals, written so that a technician cannot misread an instruction. The word limits, the verb forms, the one-name-per-thing rule, and the ban on idiom all come from here.
  • George Orwell, "Politics and the English Language", 1946. Four of his six rules arrive here through the standard. His third rule, cut any word you can, is rejected: a shorter ambiguous sentence is worse than a longer clear one.
  • Joseph M. Williams, Style: Toward Clarity and Grace. The topic position and the stress position. Old information starts a sentence and new information ends it, which is why a key term repeats at the start of the next sentence.

Structure and the reader

  • J. Russell Ramsay and Anthony L. Rostain, The Adult ADHD Tool Kit, Routledge 2015. The gap is between knowing and doing. A smaller first step closes it, and more explanation does not.
  • Robert E. Horn, Information Mapping. Chunking, relevance, and labeling. Every block gets a label that says what is in it.
  • Diátaxis. An explanation is a different kind of text from a procedure, and it must carry the reason for a design, the alternative, and the limit.

Formatting and scanning

Vocabulary and the reader

Prior art

  • Orwell-Writer pairs Orwell with ASD-STE100 as a skill. Reaching the same pairing independently is a good sign that it works.
  • The caveman plugin compresses output by talking in fragments. This plugin rejects that trade, because rule 4.2 of the standard forbids dropping a word to shorten a sentence.

Prerequisites #

A POSIX shell for scripts/emit-core.sh, which uses sed and wc and nothing else. Python 3 for scripts/emit-coding.py, which parses the hook payload as JSON. Without Python 3 the coding hook prints nothing and the prose hook still works.

Licensing #

MIT, for the script, the manifests, and the prose written here. Two things it cannot cover.

ASD-STE100 is copyright ASD and is not free to redistribute. This plugin ships no part of the standard, and it ships no part of the STE dictionary. The rules here are written in our own words and adapt the standard rather than reproduce it.

The Adult ADHD Tool Kit by Ramsay and Rostain is a commercial copyrighted work. The structure rules paraphrase its mechanisms. No chapter text appears here.