This takes the advice from my post Make better documents and turns it into a skill your AI tools can follow. It's nothing too fancy, and it's free and open source.

Install it in your own tools

The skill is a single Markdown file. Once it's installed, it fires on its own when you ask for the relevant thing — no extra prompting needed.

Claude

The quickest way, from anywhere you use Claude Code:

npx skills add github:anildash/better-documents

If you'd rather do it by hand, drop the file where Claude looks for skills. Use the first path to have it available everywhere, or the second to keep it to a single project:

git clone https://github.com/anildash/better-documents

# available in every project
mkdir -p ~/.claude/skills/better-documents
cp better-documents/SKILL.md ~/.claude/skills/better-documents/

# or just this project
mkdir -p .claude/skills/better-documents
cp better-documents/SKILL.md .claude/skills/better-documents/

Then just ask for what you want, and it'll pick up the skill on its own:

Write a proposal for migrating our analytics stack to BigQuery.

Review this deck before I send it to the board.

Quick look — does this memo make sense?

A model running on your own machine

If you'd rather not send your documents to anybody at all, you can run this against an open source model on your own computer. Ollama is the most popular way to do that, and it takes about a minute. It doesn't have a skills system the way Claude does, so instead you bake the skill in as the model's standing instructions:

git clone https://github.com/anildash/better-documents
cd better-documents

printf 'FROM llama3.1\nSYSTEM """\n%s\n"""\n' "$(cat SKILL.md)" > Modelfile
ollama create better-documents -f Modelfile

Then run it whenever you want a document looked over:

ollama run better-documents

Swap llama3.1 for whatever model you prefer — mistral, qwen2.5, gemma3, any of them will work. Fair warning: a small model running on a laptop won't reason about your document as well as a big one will, so treat its judgment calls with more skepticism. But it never leaves your machine, which for some documents is exactly the tradeoff you want.

Why you'd want this

Even very smart, capable communicators routinely send important documents that distract from, or even undermine, their goals. This isn't too surprising; we almost never actually teach people how to use the ordinary tools of business communication in more effective ways. Here's what the skill watches for on your behalf:

• It makes you say what you're actually asking for. The most common, and most serious, problem people have in creating documents is that they don't consider who they're speaking to and what they're trying to accomplish. If you're asking for something, it should be crystal clear that you're asking for something — and if there's a deadline, it should say why that timeline matters to them, not just to you.
• It stops you formatting everything to death. Bold means something is important. Italics means something is emphasized. Color means something is distinct. Something that is bold, italicized, underlined, and brightly colored means you don't know what's important or what message you're trying to get across — it only communicates distraction. And it's hard to read.
• It puts the point first. People assume the first thing in a list is the most important. And they're being rational when they do so! You almost never want to build dramatic tension in a professional context; this isn't a thriller where you're trying to surprise them with twists and turns.
• It keeps your audience oriented. People want to know where they're at in the story. And it'll nudge you to summarize any data you present, so people start off in the right place to absorb the dense stuff.
• It makes your questions answerable. A giant headline asking "How can we do better?" is a philosophical debate, not a prompt for an organization to make a choice.
• It names the file so you can find it again. One of the most important types of information you can share in a document is the title of the document itself. And needless to say, appending _final_final to a document is… not going to produce the results you'd hope for.

Plenty of people use this who would never let an LLM generate a document on their behalf, but do think software tools are useful for things like spell check or grammar check. I see this as being a tool in that kind of category.

The same brief, with and without the skill

Same prompt, same facts, same model: “Write a Q3 board pre-brief. Revenue missed target by 12%. Two decisions needed: approve the new enterprise pricing tier, and decide the VP Sales search — external or internal promotion.” The only difference is whether the skill was installed.

Without the skill

Q3 Board Update

“As we reflect on the past quarter, our team has worked tirelessly to navigate an increasingly complex market environment…” Then background, then market context, then what the team accomplished. The revenue miss shows up in a section called “Challenges We’re Navigating,” more than halfway down, where it’s softened to “below our internal expectations.” The document closes with: “We would welcome the board’s approval and guidance on these matters as we continue to execute on our strategy.”

The ask is a courtesy in the last paragraph, with no deadline and no stakes. The bad news is a mood in the second half. The file has no date, and six months from now nobody will know which quarter it covers.

With the skill

Meridian — Q3 results and two decisions — 2025-10-15

“What we need from you. Two decisions, both by November 1: approve the enterprise pricing tier — the renewal window opens November 15, and if the tier isn’t live before then, we lose an estimated $2.1M in ARR — and choose the VP Sales path, external search or internal promotion. Q3 results: revenue was $4.1M against a $4.65M target (−12%). The miss is concentration: two of the top ten accounts downgraded, and one left.”

The ask is first, with a deadline and a reason the deadline matters to the board. The bad news is a number in the first third. The file says what it is and when it is.

What changed

• The ask. A courtesy in the last paragraph becomes two decisions with dates and a dollar figure. (Pass 1)
• The order. Background-first becomes decisions-first; the miss moves from the second half to the first third. (Pass 2)
• The formatting. Stacked emphasis, a decorative underline, and three accent colors become one emphasis type and nothing else. (Pass 3)
• The questions. “How can we improve our growth trajectory?” — a discussion — becomes approve or don’t, external or internal. (Pass 4)
• The name. “Q3 Board Update” becomes topic, content, and date. (Pass 5)

The skill also carries references for high-stakes audiences — including how a board actually reads a pre-brief, how power works in the room, and what the realistic goal of a board document is.

Both documents are in the checker below — run the first one through it and watch what it catches, then run the second and see what clean looks like.

Or try a bit of it right here

Installing the skill is the real thing. But if you just want to see what kind of stuff it catches, some of it can run right in this page.

Nothing you paste here is uploaded, stored, or sent anywhere. There's no server involved, no account, and no key to enter — it's all happening in your own browser, and it stops the moment you close the tab. Paste straight out of Google Docs or Word and the formatting comes along with it, which is how it can count your colors and underlines exactly rather than guessing.

The limits of the browser version

What you just used is a spell-checker, not an editor. It can count things: how many colors you've used, which underlines aren't links, whether your file is called _final_v2, how long your paragraphs run. Those are facts, so it states them as facts.

What it can't do is the part that actually matters. It can tell you that ask-shaped language shows up 78% of the way through your document. It can't tell you whether that's the right ask, or whether your audience has the context you're assuming they have, or whether your argument holds up, or whether the chart on slide 9 earns its place. It can't read your slides at all. It can't check whether anything you've cited is real.

That's the judgment part, and it needs a model that can actually read what you wrote. That's the skill — and it's the version that will also just write the document properly in the first place, instead of catching problems after you've already made them.