Menu
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/exiao/writing-skills --skill technical-writingLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Run a diagnose-prescribe-rewrite loop on a finished first draft: articles, posts, newsletters, essays. Checks in with the author after every rewrite before continuing. Use when a draft is written and needs editing to publishable, not when you still need a topic, title, or outline. For a single evaluation pass with no rewrite use evaluate-content.
Use when judging content quality OR editing/improving existing copy: shareability, readability, voice, cuttability, angle, copy sweeps.
Reorganize a document into new sections while preserving the author's exact words: SOUL.md, constitutions, READMEs, specs, plans, style guides. Use when the user says 'put my words into new sections', 'use the exact same words', 'reorganize this', 'what if the headers were X', 'try a different structure', or rejects your rewrite because the LANGUAGE is bad rather than the idea. Restructure is not editing and not rewriting: not one sentence may change. For improving the prose itself use writer or evaluate-content; for scoring a SOUL.md use soul-md-audit.
Basé sur la classification professionnelle SOC
Affichage de SKILL.md
| name | technical-writing |
| description | Use for docs, runbooks, error messages, plans, PRs. |
For text that has to be understood on one read, by a tired person, possibly not a native English speaker, possibly at 3am during an incident. Nobody is being persuaded. Flat is the goal.
Covers: docs, READMEs, runbooks, error messages, API and UI labels, plans, PR bodies, AGENTS.md, agent prompts, commit messages, issue bodies.
Rules adapted from ASD-STE100 Simplified Technical English, the controlled language aerospace has used for maintenance manuals since 1983.
If the text has an "I" in it, or its job is to make a reader care, stop and use the
writer skill. These rules produce near-identical sentence lengths, which is exactly the
pattern writer flags as machine-made. Applied to a blog post or landing page they delete
the persuasion on purpose.
| Surface | Skill |
|---|---|
| Runbooks, docs, READMEs | this one |
| Error messages, API and UI labels | this one |
| Plans, PR bodies, AGENTS.md, agent prompts | this one |
| Articles, tweets, landing pages, marketing | writer |
| Anything with a first person or an argument | writer |
Mixed document? Route per passage. A tagline inside a README is voice writing.
Everything else depends on this.
A procedure tells someone to do something. Imperative mood, one instruction per sentence, 20 words max.
A description explains how something works. Simple tenses, 25 words max, one topic per paragraph.
A note or warning sitting inside a procedure is a description. Treat it as one.
Counting words: a backticked command, an identifier, or a number with its unit counts as
one word. git rebase --onto main is one word, not four.
Say must, not should. Both people and models read "should" as optional. If it's required, write "must". If it isn't required, delete the line. Same for "may", "might", and "could": pick "can" or cut it.
Condition first, then the command. The reader needs to know whether to keep reading before they act.
One thing, one name. Pick one word per concept and never rotate. Synonym variety is a virtue in prose and a bug here, because the reader has to work out whether "settings" and "config" are the same thing.
Common rotations to kill: check/verify/confirm/validate, run/execute/invoke/launch, error/issue/problem/failure, delete/remove/destroy, config/settings/options.
Decide the vocabulary before you draft, not during editing.
One instruction per sentence. If a step has an "and" joining two actions, it's two steps.
Sequenced actions are the exception. When the second action only makes sense right after
the first, "then" keeps them in one sentence: "Generate a new token, then set it in
BLOOM_API_TOKEN." Splitting that into two numbered steps loses the ordering.
Active voice. Say who does it. Passive is acceptable in a description only when the actor genuinely isn't known.
No semicolons. Two sentences.
Three parts, in order: what failed, the cause if you know it, then the fix as a direct instruction.
app was wrong. Set
DB_PASSWORD to the correct value, then connect again."Never "Oops", never "Please ensure", never an apology in place of a cause. If you don't know the cause, say what you observed and where to look.
Lead with the numbers. Time window, blast radius, cause, current state.
This is the one rule shared with writer: real numbers, or say you don't have them. Never
invent one to fill the slot.
Cutting words is not the goal. Clarity is. Restore the articles and the "that" when they prevent a misreading.
Note this cuts against the eraser rule in writer. Here the tired reader wins.
Never rewrite: code, commands, config keys, identifiers, quoted error strings, log lines, file paths, or anything inside backticks. Copy them exactly. A "cleaned up" command is a broken command.
Search the draft for these and fix each hit:
should, may, might, could (make it must/can, or delete); (split into two sentences)Please ensure, Oops, Simply, JustThis is the useful subset of ASD-STE100, not the standard. Real STE compliance needs the official dictionary and approved-word list. Don't claim a document is STE-compliant.