plain-writing-skill: a markdown rules file that tells an agent to cut its own output

What plain-writing-skill actually ships

The repository contains one substantive artifact: skills/plain-writing/SKILL.md, described in the README as a plain markdown file holding the rules and the steps. Everything else is packaging. The skills/ directory placement exists so that gh skill install can locate the skill, and the evals/ directory is marked optional, needed only if you want to measure the skill. There is no Python package to import despite the repository being listed with Python as its primary language, and the README never asks you to run a module or a CLI. The audience is anyone who has an agent reading instruction files and wants its prose to come out flatter. If you are looking for a formatter, a linter, or a CI check, this is not that.

The mechanism is instruction loading, not code execution

There are two moving parts. The first is the rules file itself, which the README says any agent that can read a file can follow. The second is the deslopify command. When you issue /plain-writing deslopify, the skill rewrites the agent's previous response into a structure aimed at a sharp CEO or technical reader who has no project context and needs all relevant details. You can also append text after the command to rewrite something other than the last response. The README also states that the skill checks its own writing and removes anything that does not add something. That self-check is not described as a separate program, so treat it as a step inside the skill's instructions rather than a process you can invoke on its own. The data flow is therefore short: rules enter the context window, the agent drafts, the agent re-reads against the same rules.

Installing it into Claude Code or any other agent

For Claude Code, the README gives a two-command path that deliberately excludes the evals:

mkdir -p ~/.claude/skills/plain-writing curl -fsSL https://raw.githubusercontent.com/docwriter-org/plain-writing-skill/main/skills/plain-writing/SKILL.md -o ~/.claude/skills/plain-writing/SKILL.md

For agents that support the gh skill mechanism, the README gives:

gh skill install docwriter-org/plain-writing-skill plain-writing

For Codex, pi, or anything else, the README's instruction is to paste the rules from skills/plain-writing/SKILL.md into whatever instructions that agent reads. That third path is the honest one. It tells you the project has no universal installer and that on most stacks you are copying text into a system prompt. The curl approach pins nothing: it fetches from the main branch, so re-running it later pulls whatever the file says at that moment. If you care about reproducibility, save the file into your own repository and copy from there.

The evals are optional and the README keeps them vague

The README says evals/ is only needed if you want to measure the skill, and that a skill install does not need them. To run them you clone the repository and read evals/README.md. That is the entire instruction. No command, no expected output, no pass threshold appears in the material available here. This is the weakest part of the repository's documentation. If you want to know whether the rules actually change model output, or whether one wording of the rules beats another, the README does not tell you how to find out. It points at a file inside a directory you have not cloned yet. Treat the evals as an unexplored area and budget time for reading that second README before you promise anyone a measurement.

Where a rules file stops working

The limitation is structural. A markdown file of rules is advisory. It changes what the model tends to produce, not what it is permitted to produce, and nothing in the README claims a validator rejects output that breaks the rules. Long sessions are the obvious failure mode: rules loaded at the start of a context window carry less weight as the window fills, and the README offers no mechanism for re-injecting them. The deslopify command is a manual correction, which means you have to notice the bad prose before you can fix it. Teams that need a hard guarantee, for example a documentation pipeline that fails a build on passive voice or on a banned word list, will not get it here. The self-check described in the README is the agent grading its own homework, and that is a weaker signal than an external check.

Compared with writing your own style guide

The realistic alternative is not another skill repository. It is a style guide you write yourself and paste into your agent's instructions, which is functionally the same delivery mechanism this project uses. The difference is content and maintenance. A house style guide encodes your product's vocabulary, your preferred spellings, and the terms your support team actually uses. plain-writing-skill encodes general plain-language rules and a deslopify behaviour aimed at readers without project context. The second difference is cost of upkeep. A file you own changes when your product changes. A file you curl from main changes when a stranger commits. If your writing problems are domain-specific, a short in-house guide will beat a general one, and you will not need the evals directory to know it.

Licence, updates, and what to check before adopting

The repository is MIT licensed, which permits commercial use, modification, and redistribution provided the licence text travels with copies. That is a permissive arrangement and it removes most distribution questions, but it is not legal advice and your organisation's own review process decides what it accepts. Updates are the real ongoing cost. Because the Claude Code install path uses curl against the main branch, there is no version pin and no changelog in the material provided, and no releases were retrieved. Re-running the install silently replaces your local copy. Copying SKILL.md into your own repository and reviewing changes through normal pull requests is the cheaper long-term arrangement, and it also makes the file visible to whoever edits your prompts. The maintenance burden is small in absolute terms: one markdown file, no dependencies, nothing to compile.

Editorial conclusion

Adopt it if your agent already reads instruction files from a known directory and you want plain output without building a style guide yourself. Skip it if you need enforced formatting, since the README describes no validator or linter, only rules an agent is asked to follow. Before installing, open skills/plain-writing/SKILL.md and check that its rules match the register your readers expect, because the whole product is that one file.

Official sources

1. docwriter-org/plain-writing-skill on GitHub
2. Issues
3. License: MIT
4. README