tw

Plugin tw from marketplace technical-writing-skills in Timonwa/technical-writing-skills. Commands read from the repo's manifest — 14 days ago.

Skills (20)

• ai-check

  Manually invoked. Checks whether a draft reads as machine-written and reports the specific tells rather than a verdict — em-dash frequency and pattern, blacklisted vocabulary and phrases, the structural tells (uniform section lengths, lists of exactly three, summaries that restate, closers that cong

• api-reference

  Writing and maintaining the documentation for an API a developer has to integrate against — the reference itself (endpoints, parameters, status codes, error tables, response examples), plus the pages around it that make it usable: authentication, a quickstart, pagination, rate limits, webhooks, vers

• code-samples

  Writing and maintaining the code examples inside documentation — making a sample complete and runnable, eliding correctly, showing expected output and the likely error, testing samples so they don't rot, placeholder and example-value conventions, keeping multiple languages at parity, not modelling i

• codebase-research

  Finding documentation facts in a codebase you didn't write — where defaults, limits, error strings, UI labels, env vars and the public surface actually live, reading for names and values rather than logic, searching backwards from the string a user sees, using tests as a behaviour spec, and the trap

• content-audit

  Manually invoked. Inventories an existing documentation set and judges its shape rather than its defects — every page with its type, audience, owner, last-verified date and usage, a keep/merge/split/rewrite/retire verdict for each, duplicate clusters, orphans and ghosts, navigation depth, and a gap

• developer-docs

  Writing and restructuring developer-facing documentation-site pages in any framework or platform — verify against source when the code is available, one clear focus per page, link integrity when moving pages, prose before every code block, runnable examples, canonical-page linking instead of duplica

• doc-review

  Manually invoked. Editorial review of one document, a folder or a diff, working down the five levels of edit — substantive, technical accuracy, line, copy and proof — returning numbered findings with a proposed replacement for each, a batched list of questions only the author or an expert can settle

• docs-audit

  Manually invoked. Audits a body of documentation for defects a reader would hit — claims that no longer match the product, broken links and anchors, navigation integrity, duplicated and contradictory content, missing coverage, stale images, and content nobody has verified in months. Works on a docs

• docs-planning

  Deciding what a documentation set should contain before anything is written — audience and task inventory, auditing what already exists, gap analysis, information architecture and navigation grouping, prioritizing by reader impact, the minimum doc set a release ships with, defining done, and retirin

• editing-standards

  Editing documentation that already exists — a docs page, a user guide, an internal doc, a README, a reference entry, or a draft handed over by an engineer or a colleague — in focused single-dimension passes: the five levels of edit (substantive, technical accuracy, line, copy, proof), word and sente

• images-and-diagrams

  Visuals in documentation — deciding whether an image earns its maintenance cost, screenshot capture and annotation conventions, scrubbing personal and customer data, alt text and captions, hand-authored diagrams and flowcharts as clean theme-able SVG, file naming and compression, light and dark vari

• internal-docs

  Documentation written for colleagues rather than customers — runbooks and operational procedures, SOPs and process docs, onboarding, internal reference and policy pages, and decision records. Covers why internal docs fail (no owner, no review date, undiscoverable, quietly wrong), the skeleton for ea

• localization

  Writing source content so it survives translation, and running a documentation set across locales — short explicit sentences, consistent terminology, no idiom or culture-bound examples, never building a sentence from fragments, keeping text out of images, locale-varying dates, numbers, currency and

• readmes

  Creating or updating a README for a project, package or app — detects the repo type (library, app, monorepo root, package, CLI, demo) and applies its fixed skeleton plus the universal one: a what-it-does one-liner, a tested quickstart, a config and env table, scripts, and a license. Leads with what

• release-notes

  Writing release notes and changelogs that tell readers what changed from their side — choosing the audience, the entry shape (what changed, who it affects, what to do, where to learn more), a consistent category set, breaking changes and migration steps, deprecation notices, describing fixes by symp

• sme-interviews

  Getting accurate information out of engineers and subject-matter experts and turning it into a verified draft — preparing from the artifacts first, the question sets that surface what an expert has stopped noticing, interview mechanics, getting a technical-accuracy review that actually gets answered

• style-check

  Manually invoked. Sweeps a body of content for the drift that makes a docs set read like several people wrote it — one concept named several ways, capitalization and heading-case inconsistency, product and feature name variants, forbidden and hedging words, weak link text, code-formatting and fence-

• style-guide

  Creating, maintaining and applying a writing style guide, terminology list and glossary — adopting a base guide and documenting only the deviations, the decisions a guide has to make (person, tense, capitalization, product naming, UI and code formatting, numbers, dates, lists, links, abbreviations,

• user-guides

  Writing and reviewing help-centre and user-guide content for a product's end users — FAQ answers, how-tos, concept explainers, reference lists, policy pages and troubleshooting — with answer-first openings, write-for-the-least-experienced, the teach-or-cut vocabulary test, one canonical framing per

• writing-standards

  The discipline behind developer documentation — the Diátaxis quadrants (tutorial, how-to, reference, explanation) and picking the right one, audience-first structure, prose before code, concrete over vague, plain language, and the shared house-voice checklist. Applies the same standard every run rat