core-technical-writinglisted

# Technical Writing Ambiguous prose breaks software just like ambiguous code. A README that says "configure the server" without specifying which file, which field, or what value is equivalent to a function that accepts `any` — it compiles, it silences the linter, and it fails in production when a reader's mental model diverges from the author's. Technical writing is engineering applied to language. Every sentence carries a load. Imprecise sentences shift that load onto the reader, who may not have the context to recover. ## What This Skill Is (and isn't) **Is:** Universal doctrine for authoring technical artifacts — docs that ship alongside code, govern architecture decisions, describe operational procedures, or define APIs. The rules here apply regardless of project domain. **Is not:** A style guide for marketing, sales copy, blog posts, or user-facing product text. Those artifacts have different success criteria (engagement, persuasion, brand) that are outside this skill's scope. **Is not:** A writing style enforcer that overrides the project's established conventions. When a project's CLAUDE.md or PROTOCOL.md specifies a doc format, that format wins. This skill fills the gaps. ## Hard Rules These rules are non-negotiable for any technical doc artifact. Violations are findings, not suggestions. 1. **Imperative mood for instructions.** Instructions tell the reader what to do. Use the imperative: "Run the migration." Not "You should run the migration." Not "The