Use This SkillFor writing and documentation work, the skills that changed Claude's output in side-by-side tests are internal-comms (anthropics/skills) for status updates, changelog-generator (ComposioHQ/awesome-claude-skills) for release notes, and writing-plans (obra/superpowers) for implementation plans. Each was run three times without and three times with the skill. writing-guidelines (vercel-labs/agent-skills) made no visible difference without web access.
Which writing skills have been run side by side?
The Use This Skill directory lists 70 skills in its Docs & Writing category (crawl of October 26, 2026). Four writing skills have published proofs: Claude Opus 5.5 did one fixed brief three times without the skill and three times with it, and all six pages of each proof are on the skill's page. Two of them sit in other categories in the directory (writing-guidelines under Testing, internal-comms under Other), because the crawl sorts skills by keywords in their name and description.
| Skill | Source | Brief | Proof date | Scan (Oct 26) |
|---|---|---|---|---|
| internal-comms | anthropics/skills | A one-minute status update for leadership from five facts | Oct 19, 2026 | Clear |
| changelog-generator | ComposioHQ/awesome-claude-skills | A user-facing changelog from nine commits | Oct 19, 2026 | Clear |
| writing-plans | obra/superpowers | An implementation plan for team accounts in an invoicing app | Oct 19, 2026 | Clear |
| writing-guidelines | vercel-labs/agent-skills | Rewrite a weak getting-started page and list the changes | Oct 21, 2026 | Clear |
None of these proofs was commissioned by a skill author, and none of the four skills is sold by this site.
What did each skill change?
| What was measured (3 runs each) | Without | With |
|---|---|---|
| internal-comms: Progress, Plans and Problems as the section headings | 0 of 3 | 3 of 3 |
| internal-comms: a status label such as "On track" or "Amber" | 3 of 3 | 0 of 3 |
| internal-comms: median words on the page (range) | 190 (180 to 195) | 123 (91 to 144) |
| changelog-generator: the Node upgrade or the tax refactor mentioned | 3 of 3 | 0 of 3 |
| changelog-generator: the docs commit kept, for developers | 3 of 3 | 3 of 3 |
| writing-plans: distinct file paths named (.ts, .tsx, .sql) | 0, 1 and 4 | 31, 37 and 40 |
| writing-plans: commit steps named in the plan | 0 in each | 16 in each |
| writing-plans: an "out of scope" list | 3 of 3 | 0 of 3 |
| writing-plans: median words on the page | 2,221 | 3,710 |
| writing-guidelines: the five faults named in the brief all fixed | 3 of 3 | 3 of 3 |
| writing-guidelines: median words on the page | 889 | 720 |
Counts from a script run on the 24 published pages on October 31, 2026: visible text with styles, scripts and drawings removed, then headings, phrases and file names counted. These proofs ran before October 23, so data/proofs.json has no token or time figures for them. The script counts what is on the page; it does not judge whether the writing is good.
internal-comms: shorter updates in a fixed format
The skill's 3P guide asks for Progress, Plans and Problems, one to three sentences each, readable "in 30-60sec or less". With it, every update used those three headings and ran from 91 to 144 words. Without it, the updates were longer, added an overall status label, and closed with lines the brief did not supply, such as a promise to confirm the date next week. If your team already writes 3P updates, this is the skill to install. If it does not, the format comes with it.
changelog-generator: internal work left out
Two of the nine commits were internal: chore: bump node to 22 and refactor: move tax calculation into shared module. The skill says to filter out internal commits. With it, all three changelogs left both out. Without it, all three described them in an "under the hood" note. Both sides turned every feature and fix into customer language and kept the API docs change in a section for developers, so the difference is what reaches your customers, not how well it reads.
writing-plans: a plan an engineer can follow step by step
The skill tells Claude to write for "an engineer who has not seen this codebase": exact files, exact tests, small tasks, frequent commits. With it, each plan named 31 to 40 files, wrote failing tests before the code, and marked 16 commit points. Without it, the plans were architecture documents: shorter, with no commit steps and few file names, but each one listed what was out of scope and added Postgres row-level security as a second safeguard, which none of the plans with the skill did.
writing-guidelines: needs web access to work
At the recorded commit, this skill's SKILL.md contains no writing rules. It tells the agent to fetch the latest rules from a URL with WebFetch and then report findings in a terse file:line format. The proof runs had no tools, so the rules never arrived. Both sides fixed every fault the brief listed: the company history was cut, the install command moved to the top, "the user" became "you", passive sentences became active, and a next step was added. With the skill, two of the three pages said the live rules file could not be fetched. In Claude Code, WebFetch is a built-in tool that asks for permission, so there the skill can read its rules; this proof does not show what it does with them.
Which writing skill should I pick?
- You write weekly status updates for leadership: internal-comms. It also has guides for newsletters, FAQ answers and general announcements in its
examples/folder. - You publish release notes from git history: changelog-generator. It keeps refactors and dependency bumps out of customer-facing notes.
- You hand plans to another engineer or to an agent: writing-plans. Expect longer plans with files, tests and commits spelled out; add your own scope list if you need one.
- You want docs checked against Vercel's published writing rules: writing-guidelines, in an agent that can fetch web pages. Without that, Claude Opus 5.5 made the same fixes on its own.
The other 66 skills in Docs & Writing have no proof yet. The Docs & Writing list has all 70, proven ones first. For other kinds of work, the same kind of comparison is in best skills for writing tests and best frontend design skills.
How were the proofs run?
Each run sent the brief to Claude Opus 5.5 once, with the skill's SKILL.md and its other text files loaded for the "with" side and nothing for the "without" side, and asked for a single HTML page. The runs had no tools, so nothing was fetched, saved or run. Every proof records the skill's exact commit. The rules are on how a proof works, and every proof on the site is on proven skills.
Are these writing skills safe to install?
All four were Clear in the October 26, 2026 scan, which reads every file in a skill's folder for patterns such as downloading and running code in one step, sending data out, reading credential files, or text that tries to override your instructions. Across Docs & Writing, 68 of 70 skills were clear, 1 needs a manual look and 1 was flagged. The scan is a static check, not a guarantee; are agent skills safe? explains what it can and cannot catch. Before installing any skill, paste its GitHub link into the live skill check for a report on its current commit.
How do I install one in Claude Code?
Each skill page has a one-line install. For internal-comms:
npx degit anthropics/skills/skills/internal-comms .claude/skills/internal-comms
That puts the skill at .claude/skills/internal-comms/SKILL.md, which Claude Code loads for that repository; ~/.claude/skills/ makes it available in all your projects. Claude Code keeps each skill's description in context and loads the full text only when the skill is used, and it reads files such as examples/3p-updates.md only when the skill points to them. How to install a skill from GitHub covers other tools and agents.