The Elements of Style as an Agent Plugin: What the obra/the-elements-of-style Repository Actually Ships
William Strunk Jr.'s Elements of Style (1918) in markdown format for AI agents
At a glance
- What is it?
- Strunk's 1918 text is public domain, so the interesting part is not the prose but the packaging: a skill named writing-clearly-and-concisely, a roughly 12,000-token reference, and a single everyharness.yaml that generates manifests for eleven agent harnesses. Here is what that buys you and where it costs you.
- Who is it for?
- Adopt this if your agent writes prose a human reads, especially commit messages, error strings and doc comments, and you are willing to pay roughly 12,000 tokens of context when the full reference is opened. Do not adopt it if your agent's output is read only by machines, or if you cannot regenerate manifests after editing everyharness.yaml.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 34 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Is Not Bad Grammar, It Is Prose an Agent Wrote and a Human Has to Read
Agents produce a specific kind of text: commit messages, error strings, doc comments, pull request descriptions. That text is short, frequent, and read under time pressure. The failure mode is rarely a misspelling. It is a commit message that says 'fix issue' or an error string that says 'something went wrong'. The repository states its purpose directly: the plugin hands your agent Strunk's guidance whenever it writes documentation, commit messages, error text, or any other prose a human will read. The audience is therefore narrow and identifiable. It is not a general writing tool for humans, and it is not a linter that rewrites your code comments. It is a retrieval layer that puts a 1918 style guide in front of a model at the moment the model is generating English. If your agent only emits JSON, SQL or code with no prose surface, nothing here applies to you.
Two Artifacts: A Skill That Decides and a Reference That Costs Tokens
The repository separates judgment from text. The skill is named writing-clearly-and-concisely and, per the README, it lists every rule at a glance, warns that the reference costs about 12,000 tokens, and suggests handing a draft to a subagent when context runs short. The reference is the complete 1918 text, converted to markdown, covering Elementary Rules of Usage (seven rules), Elementary Principles of Composition (eleven rules), and Words and Expressions Commonly Misused, an alphabetical guide. That split is the actual design decision worth noting. The skill is cheap and always loadable. The reference is expensive and loaded only while writing or editing. An agent that keeps the 12,000-token reference resident for an entire session is burning context on rules it may never apply. The README's own mitigation is delegation to a subagent, which is a real answer but also an admission that the reference does not fit comfortably alongside a large codebase in a single window.
Every Harness Manifest Comes From One File, and Hand Edits Are Detected
The install table lists Claude Code, Cursor, Codex, Devin CLI, Kimi Code, Gemini CLI, OpenCode, Pi, Hermes Agent, Agent Plugins 1.0 clients, and a marketplace descriptor covering Factory Droid, Grok and Copilot. Each row points at a file under docs/install/, for example docs/install/claude-code.md or docs/install/agents-marketplace.md. The README states that every supported harness reads the skill from skills/ and that the per-harness manifests differ only in where they point. Generation is handled by everyharness, invoked as npx everyharness generate, from a single everyharness.yaml. Two guardrails matter operationally. Generated files carry a GENERATED by everyharness header, and .everyharness/manifest.json lists them all. Running npx everyharness validate fails on drift, and the next generate overwrites hand edits. The practical consequence: if you fork this to change a rule or trim the reference, you edit everyharness.yaml and the skill, then regenerate. Editing a manifest directly is a dead end.
The 12,000-Token Reference Is the Real Budget Line
The README gives one hard number: the reference is roughly 12,000 tokens. Everything else about cost is unstated. There is no measured latency figure, no accuracy comparison against a baseline agent, and no example of a commit message before and after the skill runs. The repository also has no releases retrieved and no homepage, so there is no changelog to consult about how the reference has changed over time. Treat the token figure as the only quantitative claim you can plan against. If your agent runs with a small context window, or if it already carries several skills, the arithmetic is simple: opening the full reference is a meaningful fraction of the window, and the README's subagent suggestion exists precisely because of that. Whether the writing improves enough to justify the spend is not something this material can tell you. You would have to measure it on your own commit history.
Where This Is the Wrong Tool
Three cases stand out. First, machine-only output. If your pipeline consumes structured data and no human reads the generated English, the skill has no surface to act on. Second, teams that need enforced output. This is guidance delivered to a model, not a linter or a CI check. Nothing in the README describes a validator that rejects a commit message for violating a Strunk rule, so compliance is probabilistic. Third, teams with strict context budgets. The skill's own warning about the 12,000-token reference is a limitation stated by the project itself, and the subagent workaround adds orchestration the README does not document in detail. There is also a currency question. The text is the 1918 edition. Its guidance on punctuation and usage reflects that period, and the README does not describe any editorial layer that reconciles it with current conventions. For commit messages and error strings that is mostly harmless. For user-facing documentation with modern style requirements, a 1918 rulebook may push your prose in directions your team did not choose.
The Alternative Is a Prompt Snippet or a Project Style Guide, and the Difference Is Retrieval
The obvious alternative is pasting a short style list into your agent's system prompt or your repository's contributor guide. That approach costs a few hundred tokens, is fully under your control, and can encode your team's actual conventions rather than a canonical text. The difference in approach is where the judgment lives. A prompt snippet is static and always present; it applies whether or not the agent is writing prose. This plugin is conditional. The agent invokes writing-clearly-and-concisely when it writes prose, and opens the full reference only while writing or editing. So the trade is context economy and completeness against control and specificity. A prompt snippet wins when your rules are few, your conventions are unusual, or your context window is tight. This plugin wins when you want the breadth of an alphabetical usage guide and eleven composition principles available on demand without paying for them on every turn. Neither approach enforces anything, which is worth remembering before you pick.
Licence and Maintenance: Public Domain Text, No Repository Licence File
The README states that the text is public domain, that the 1918 edition came from Project Gutenberg as entry #37134, and that it was converted to markdown. The licence field for the repository itself is unknown. Those are two different things, and the gap matters. The Strunk text carries no restrictions, but the skill definition, the everyharness.yaml configuration, the generated manifests and the install docs are repository content with no stated licence. If you plan to redistribute a fork, that is the question to resolve before you do, and it is a question for whoever handles licensing on your side rather than something this material answers. Maintenance cost is tied to the generator. Any upstream change to everyharness, or any new harness you want to support, means editing everyharness.yaml and rerunning npx everyharness generate. The skill and reference themselves are close to static, since the source text is fixed at 1918 and the README describes no ongoing editorial work. The moving part is the packaging, not the prose.
Editorial conclusion
Adopt this if your agent writes prose a human reads, especially commit messages, error strings and doc comments, and you are willing to pay roughly 12,000 tokens of context when the full reference is opened. Do not adopt it if your agent's output is read only by machines, or if you cannot regenerate manifests after editing everyharness.yaml. Verify three things first: that your harness appears in the install table, that your client reads the skill from skills/ rather than a copied path, and that your licence review accepts a public domain text shipped without a repository-level licence file.
Community notes