agentsclimarketplace

Technical writing

Skill Amey-Thakur/AI-SKILLS/skills/documentation/technical-writing

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill technical-writing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Write documentation, READMEs, and guides that respect the reader's time and answer their actual question. Use when drafting or editing any technical document.

SKILL.md

2.4 KB, as published. Nobody here has run it

Technical writing

Documentation has one job: the reader arrives with a question and leaves with an answer, in as little of their time as possible.

Method

  1. Name the reader and their question before writing. "A developer who just cloned the repo and wants it running" reads a different document than "an operator debugging a production incident". One document per reader when they diverge; a document for everyone answers no one.
  2. Lead with the answer. The first paragraph carries the single most important thing: what this is, what just happened, what to do. Context and reasoning follow for readers who want them. Never build suspense.
  3. Structure for the scanning reader. People read headings, code blocks, and lists first, prose only when trapped. Make the skeleton carry the story: headings that are claims ("Tokens are counted per provider"), not labels ("Overview").
  4. Show, then explain. A working example beats three paragraphs of abstraction. Every command must be copy-pasteable and correct; every example output must be real, not imagined. Test what you paste.
  5. Write plainly. Short sentences. Active voice. "Use" not "utilize", "so" not "in order to". Jargon only when the reader owns it already, and defined once when unavoidable. Adjectives like "simple", "just", and "easy" are broken promises: the reader for whom it is not easy is the one reading.
  6. State the edges honestly. What it does not do, where it breaks, what is a known limitation. A document that oversells produces support burden and distrust in equal measure.
  7. Cut, then cut again. After drafting, delete every sentence whose removal loses nothing. Most first drafts survive a 30% cut with meaning intact and clarity improved.

Litmus tests

  • Can the target reader succeed using only this document, offline?
  • Does every code block run as pasted?
  • Does the first screen answer the most common question?
  • Would you tolerate reading this twice? The maintainer will read it fifty times.

Boundaries

Match the project's existing voice and formatting conventions. Never invent facts to fill a section: a short honest document outranks a long padded one, and "this is not documented yet" outranks a guess.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.