Writing Skills

writing skills · assembly order

Getting started.

Six steps. Step 1 is a decision rather than an action, because it changes what the later steps are worth to you.

The installation sentence is quoted from the project README, and the install commands from the Loop & Gate Grow Kit, which documents them. The scripts are quoted from scripts/README.md. The linter run in step 6 was executed for this page. Nothing else was: no plugin was installed and no draft was passed through the skills.

Decide whose voice you are editing toward

Three of the skills treat a voice profile as authoritative and defer to it wherever their own defaults disagree. That profile, Profiles/voice.md, is not in the repository and is not published here. It is Shane’s private note.

So pick one of two paths now, before installing anything:

the decision in step 1
PathWhat you getWhich skills
Supply your own profile Point the voice-bound skills at a profile of your own and they edit toward you. The procedure is the reusable part; the profile is the material. humanize, ms-style-pass, writing-review
Skip the profile Use only the skills that apply a published standard, and leave the voice-bound ones alone until you have a profile. Running them blind yields Shane’s voice, not yours. plain-language, ste100

Either way, writing-interview stays out. It interviews Shane and depends on his own material, so it does not travel. The choosing a pass page has the per-skill detail.

Install from the marketplace

This is the installation instruction the README gives, in full:

Install via the slogsdon-claude-code-config marketplace.

The README stops there. The commands are documented in a sibling project, in the Loop & Gate Grow Kit’s reference/tools.md. In Claude Code:

/plugin marketplace add slogsdon/claude-code-config
/plugin install skills-writing@slogsdon-claude-code-config

On pi, the same file gives:

pi install git:github.com/slogsdon/skills-writing

There is nothing else to install. The skills are Markdown, the two linters are Python, and neither the plugin nor this site needs a build step of its own.

Confirm the six skills are there

The plugin ships one skill directory per skill, and the plugin manifest describes all six. After installation you should be able to see these names in your skill listing:

humanize
ms-style-pass
plain-language
ste100
writing-review
writing-interview

If a name is missing, the plugin did not install completely. Two skills carry a references/ file (humanize and ms-style-pass). Four carry evals/ cases. Neither is required for the skill to run.

Put your own voice profile where the skills look

Skip this step if you took the second path in step 1. If you took the first, write the profile before you run a voice pass, because the pass has nothing else to aim at.

The skills refer to it as Profiles/voice.md and read it when it is available. What belongs in that file is your material, not this site’s: rules you refuse, substitutions you have made, phrases you never use, and the shapes your prose already takes. Expect the profile to win arguments with the skill, since that precedence is stated in humanize and writing-review alike.

Two cautions from the skill files, both worth carrying into your own profile. humanize insists that existing texture is voice and invented texture is performance, so do not ask the profile for hedges, asides, or jokes the author never wrote. And writing-review treats a fragment sequence that lands a build-up as a deliberate choice, so a profile that bans fragments outright will produce reviews that argue with you.

Run one pass on a real draft

Each skill loads from its description, so the ask is what matters. These are the trigger phrases from the six skill files, quoted:

humanize            "humanize this", "edit in my voice", "make this sound like me"
ms-style-pass       "ms style pass", "apply the style guide"
plain-language      "make this plain language", "plain language pass"
ste100              "apply STE100 to this", "simplified technical english"
writing-review      "review this", "critique this draft"
writing-interview   "interview me first", "help me write about X"

Order matters where two passes touch the same draft. The source README states that workflow-stage-draft runs them as interview → draft → humanize → ms-style-pass, with writing-review sitting alongside as the read-only diagnostic. Run the style pass first and the voice pass after, and you will have edited the same sentences twice in the wrong order.

The two most useful expectations to hold onto: writing-review never writes a replacement draft, and writing-interview writes no prose until you answer. A run that breaks either one has drifted out of the skill’s stated boundary.

Measure the edit, if you want a cross-check

Two diagnostic linters sit in scripts/, byte-identical to addyosmani/clarity and deliberately unmodified. From a checkout of the repository:

python3 scripts/strip_markdown.py draft.md > /tmp/draft.txt
python3 scripts/prose_stats.py /tmp/draft.txt

Or in one pass:

python3 scripts/strip_markdown.py draft.md | python3 scripts/prose_stats.py -

They report sentence-length variation, short-line share, anchor density, hedge and booster density, and stock-lexis hits. There is no composite score, and scripts/README.md is explicit that this is not a quality gate and never an authorship or detector verdict. Measure the same piece before and after a pass and compare the two readings.

One run you can repeat measures the project’s own README.md at commit d4e7ce7, on Python 3.15:

python3 scripts/strip_markdown.py README.md | python3 scripts/prose_stats.py -

The first part of the output:

220 words, 17 sentences, 7 paragraphs
  note: under 400 words. Cadence and density figures are unstable at this length, and so is any judgement made from a short excerpt.

MEASUREMENTS (descriptive, not targets)
  body_sentence_cv           0.994
  short_line_share           0.294
  hedge_per_100              0.0
  booster_per_100            0.0
  anchors_per_100            10.91
  signpost_opener_share      0.0

Further down, under LOOK HERE, it lists four triads, one of them “on agentic workflows / web standards / payments engineering”. It also notes that a third of the lines are under eight words. In a README those are list items, so the script’s own advice applies: read body_sentence_cv and ignore the short-line share. A README isn’t written in anyone’s voice, so the run shows the shape of the output. It says nothing about whether the prose is good.

To confirm the vendored files are the upstream ones, scripts/README.md gives the check:

shasum -a 256 scripts/*.py

what setup does not get you

two limits

The skills edit, apply a standard, diagnose, or ask. None of them verify a fact, and humanize is explicit that when a better sentence needs a fact, number, or experience only the author has, it leaves a [TK: your question] marker rather than writing plausible filler. Treat every [TK] as work you still owe the draft.

The scoring gate in humanize is a pattern checklist with a threshold of 90, not a claim about how text is received. A deduction on protected text (an accurate hedge, a landing fragment, a required technical term, the actual ask in a message) is kept and reported as kept (−N): reason. If the final score is under 90 because items were kept, the skill reports the real number.

where to go

after setup