Use when the work produces a document that must be understood by someone who was not there when the system, procedure or decision was made, and that stays in the repository after the work merges: a README, an architecture or system document, an ADR, a runbook, an onboarding guide, an API guide, a migration note. Not for the working documents of a piece of work (boards, specs, plans and reports belong to the skills that produce them) and not for persuasive prose.
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
# Technical writing
**The reader arrives with a question; the document reduces the uncertainty around it** until the reader can understand the system, make the decision, or perform the action. The structure, the constraints, the decisions, the evidence and the consequences are made visible, without making the engineering look simpler than it is.
## Mindset
- **One reader, one question.** "How do I run this?", "why does this service depend on this database?" and "what do I do when the deployment fails?" are three documents. Name the reader and the question first, answer first, let background follow.
- **Draw the structure before writing**, through the `write-diagrams` skill, picking from its catalog by the reader's question. A concept with components, ordering, states, ownership or dependencies is drawn, never narrated.
- **State where a responsibility ends.** For each significant component: what it owns, consumes, produces, depends on, deliberately does not do, and what can change without affecting it. Never "handles" or "manages".
…
The line at the top of this page pins the label git:20261007.75cb045, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
A 17 of 17 checks passed. Fixed automatic checks with no AI involved, so the same checks give the same answer every run.
pass: Frontmatter block present
pass: Frontmatter declares a name
pass: Frontmatter declares a description
pass: Size between 200 bytes and 200 KB (4869 bytes)
pass: No zero-width or bidi control characters
pass: No instruction hidden inside an HTML comment
pass: No link to an exfiltration or paste host
pass: No credential-shaped string
pass: No instruction to send local credentials anywhere
pass: No text hidden with inline styles
pass: No prompt-injection phrasing
pass: No curl or wget piped into a shell
pass: No recursive delete of root, home or parent
pass: No instruction to read or print local credentials
pass: No base64 blob over 200 characters
pass: No link to a raw IP address
pass: No script tag
Source
GitHub
ovich/swarmstorm · 13 stars · license MIT · pushed 2026-10-31 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_ju6rvcbvc7jxchee
GET https://markdownregistry.com/api/v1/resolve?ref=ovich/swarmstorm/technical-writing
GET https://markdownregistry.com/api/v1/blob/ea289f35eef1e11461ad98fd7508cc22b339db0e8a84a526d76bf165482ed1b5
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
ovich/swarmstorm · skills/alignment/brainstorm/SKILL.md · Use when a person wants to think an idea through and keep the discussion: a feature, a tool choice, an architecture…
ovich/swarmstorm · skills/alignment/brainswarm/SKILL.md · Use when a person wants a swarm of role seats to work a topic on the swarm board under a chosen protocol: a brainstorm…
ovich/swarmstorm · skills/alignment/interview/SKILL.md · Use when a person says "interview me" or asks to be interviewed about an idea or an existing design document (a board…
ovich/swarmstorm · skills/alignment/whiteboard-defense/SKILL.md · Use when a person wants to be questioned about a system they shipped, says "defend <feature>" or "whiteboard me on…
ovich/swarmstorm · skills/architecture/complexity-rework/SKILL.md · Use when code is hard to follow and is to be audited or reworked: long if/else or switch chains, cascades of type…
ovich/swarmstorm · skills/architecture/deepen-module/SKILL.md · Use when a person asks to design a new module's interface or to rework an existing module so that it hides much behind…
ovich/swarmstorm · skills/architecture/dependency-graph/SKILL.md · Use when a JavaScript or TypeScript project's dependencies must be seen as they are in the code: the whole graph, what…
ovich/swarmstorm · skills/architecture/write-diagrams/SKILL.md · Use when a document produced in this collection (board, plan, report, analysis, durable doc) could carry a diagram, or…
ovich/swarmstorm · skills/companions/aiview/SKILL.md · Use whenever a document is produced for the user to read and react to while it evolves: a brainstorm board, a plan, a…
ovich/swarmstorm · skills/companions/swarm-board/SKILL.md · Use when agents run together on the project's swarm board: a plan, a task swarm or a brainswarm, as its orchestrator or…
ovich/swarmstorm · skills/execute/execute-plan/SKILL.md · Use when carrying out an implementation plan the person has already approved, whether starting it or resuming it in a…
rsmdt/the-startup · plugins/team/skills/development/technical-writing/SKILL.md · Create architectural decision records (ADRs), system documentation, API documentation, and operational runbooks. Use…
openhands/extensions · skills/technical-writing/SKILL.md · Guides technical explanations toward flowing, direct, conversational prose. This skill should be used for engineering…
nahid-sparktales/agent-dispatcher · skills/knowledge/technical-writing/SKILL.md · Write or repair documentation that stays true to the system it describes — README, setup guide, how-to, API reference…
