obra/the-elements-of-style: Strunk's 1918 Style Guide Packaged as a Coding Agent Plugin

What this plugin does for an agent that writes prose

Coding agents produce a lot of text that is not code: commit messages, README sections, docstrings, error strings, changelog entries. The repository's stated purpose is to hand the agent Strunk's guidance at the moment it writes any of that. It is not a linter and it does not run on your repository. It is a package of instructions and reference text that a supported agent loads.

The audience is narrow and specific: people running Claude Code, Cursor, Codex, Devin CLI, Kimi Code, Gemini CLI, OpenCode, Pi, Hermes Agent, Agent Plugins 1.0 clients, or a marketplace descriptor for Factory Droid, Grok and Copilot. If you do not use one of those harnesses, the repository has nothing to install into. The README lists the supported harnesses in a table and each row points at a document under docs/install/.

The content itself is the 1918 edition of The Elements of Style, roughly 12,000 tokens, covering the seven elementary rules of usage, the eleven elementary principles of composition, and an alphabetical guide to words and expressions commonly misused. It is the public domain text from Project Gutenberg #37134, converted to markdown.

The skill and reference split, and why the token count matters

The package has two parts. The skill is named writing-clearly-and-concisely, and it holds the decision logic: when to apply Strunk's rules and how. The reference is the full 1918 text. The README describes the skill as listing every rule at a glance, warning that the reference costs about 12,000 tokens, and suggesting that a draft be handed to a subagent when context runs short. The full reference is opened only while writing or editing.

That is the design decision worth noticing. A 12,000-token reference is not free. Loading it into a working session displaces whatever else the agent was holding, which is why the skill defers the load and why the subagent suggestion exists. If your harness has a small context window, or if you are mid-task on a large file, pulling the full text in at the wrong moment is a real cost. The package acknowledges this rather than hiding it.

Every supported harness reads the skill from the skills/ directory. The per-harness manifests differ only in where they point, which is a clean arrangement: one skill, many thin wrappers. The generated artifacts are produced by everyharness from a single file, everyharness.yaml.

Installing from the per-harness docs

There is no single install command in the README. The install table routes each harness to its own document, and those documents are the authoritative steps. For Claude Code the README points at docs/install/claude-code.md; Cursor at docs/install/cursor.md; Codex at docs/install/codex.md; Devin CLI at docs/install/devin.md; Kimi Code at docs/install/kimi.md; Gemini CLI at docs/install/gemini.md; OpenCode at docs/install/opencode.md; Pi at docs/install/pi.md; Hermes Agent at docs/install/hermes.md. Agent Plugins 1.0 clients use docs/install/agent-plugins-1.0.md, and the marketplace descriptor for Factory Droid, Grok and Copilot is documented in docs/install/agents-marketplace.md.

Start by opening the file for your harness in the repository. The layout confirms the wrappers exist: there are .claude-plugin/, .codex-plugin/, .cursor-plugin/, .devin-plugin/, .hermes-plugin/, .kimi-plugin/, .opencode/ and .pi/ directories at the top level, plus plugin.json, gemini-extension.json and GEMINI.md. For Pi, package.json declares the extension and skill paths directly:

{
  "pi": {
    "extensions": ["./.pi/extensions/elements-of-style.ts"],
    "skills": ["./skills"]
  }
}

Those two entries are what a Pi installation consumes: an extension file and the skills directory. If your client resolves skills from a different location, the manifest is the thing to compare against.

If you are working on the package rather than installing it, the README is explicit that every harness manifest, bootstrap hook and install doc is generated from everyharness.yaml. Editing that file and the skill, then regenerating, is the supported path:

npx everyharness generate

It also states that generated files carry a GENERATED by everyharness header, that .everyharness/manifest.json lists them all, and that everyharness validate fails on drift. Hand-editing a generated file is overwritten by the next generate run.

Where this is the wrong tool

The package is instructions for an agent, not a writing tool for a person. If you want to read Strunk, check a usage question, or hand a style guide to a human writer, installing a coding agent plugin is a detour. The underlying text is public domain and available elsewhere; this repository's contribution is the packaging.

The edition is also a boundary. The reference is the 1918 text. The Strunk and White revision that most readers mean when they say The Elements of Style is a different book, and nothing in the repository claims to include it. If your team's house style follows a later edition, this reference will not match it.

The licence field in package.json reads Public Domain, which fits the 1918 source, but the repository does not carry a LICENSE file at the top level and the project's own licence is listed as unknown. Treat the text and the packaging as separate questions and check the packaging terms before redistributing the manifests.

Finally, the value depends entirely on the harness loading the skill at the right time. If your client does not support skills from skills/, or does not invoke writing-clearly-and-concisely when it writes prose, you have installed files that sit unused.

How it differs from a prose linter such as Vale

Vale is the natural comparison for anyone who wants style rules enforced on written output. The difference in approach is fundamental. Vale parses your files, matches them against a rule set, and reports violations; it runs in CI or in an editor and produces pass or fail results you can act on mechanically.

This repository does none of that. It supplies guidance to a model at generation time. There is no rule file to configure, no exit code, no report. The upside is reach: a linter can only check text that already exists, while an agent plugin can influence the text before it is written, including commit messages and error strings that never pass through a review step. The downside is verifiability. You cannot diff a model's adherence to Strunk's rules the way you can diff a Vale report, and a rule the skill lists at a glance is a suggestion, not a constraint.

A practical arrangement is both: let the plugin shape the draft, then let a deterministic checker catch what slipped through. Nothing in this repository provides the second half.

Maintenance, regeneration and the cost of staying current

The last push to the repository was on 2026-08-12, and the repository is not archived. The maintenance model is unusual and worth understanding before you fork it. The skill text and everyharness.yaml are the sources; the per-harness manifests, bootstrap hooks and install docs are generated. Upgrading therefore means regenerating, not merging hand edits.

The README states that everyharness validate fails on drift and that generate overwrites manual changes. In practice that means a local patch to a generated manifest will not survive. If you need a harness that is not in the table, or a different skill path, the change belongs in everyharness.yaml and the skill, followed by npx everyharness generate. The .everyharness/manifest.json file lists every generated artifact, which is the list to check after a regeneration to see what moved.

The reference text itself is stable: the 1918 edition does not change. The upgrade cost sits in the packaging and in the number of harnesses the project supports, both of which grow. Each new harness adds a manifest, a bootstrap hook and an install document to regenerate and verify. On licensing, the source text is public domain per the README and package.json declares Public Domain, but there is no top-level LICENSE file, so confirm the terms that apply to the generated manifests and the skill before you redistribute them.

Editorial conclusion

Adopt it if your coding agent writes prose a human will read and you want Strunk's rules loaded on demand rather than pasted into every prompt. Do not adopt it as a general writing app for people, and do not expect the Strunk and White edition: the reference is the 1918 text from Project Gutenberg. Before installing, open the doc for your harness under docs/install/ and confirm the skill path it points at, then check whether your client can load a skill from skills/ at all.

Frequently asked questions

Official sources

1. Issues
2. obra/the-elements-of-style on GitHub
3. README