technical-writing

Applies Diátaxis, Google style, STE, and Global English rules to technical documentation.

136|8|Updated May 9, 2026
One-click install
npx skills add https://github.com/Sma1lboy/rove --skill technical-writing-sma1lboy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: technical-writing
Source: https://github.com/Sma1lboy/rove/tree/main/.agents/skills/pstack/skills/technical-writing
Command: npx skills add https://github.com/Sma1lboy/rove --skill technical-writing-sma1lboy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Technical docs often fail readers because they mix document types, bury instructions in passive voice, and leave sentences open to multiple readings. This Skill gives you a four-layer standard so any tired engineer understands your docs on the first read. ## Core Features & Use Cases - Diátaxis mode selection: Classify each document as tutorial, how-to, reference, or explanation, and keep modes from mixing. - Sentence-level rules: Apply Google developer style, Simplified Technical English, and Global English guidelines to instructions, warnings, and pronoun references. - Review checklist: Run an 8-point checklist over docs, RFCs, READMEs, PR descriptions, and commit messages before merging. - Use Case: You are rewriting a confusing README section. The Skill rewrites passive constructions into commands, breaks up noun strings, moves conditions before steps, and replaces jargon with real symbol names. ## Quick Start Ask the assistant to review and rewrite the attached documentation file using the technical-writing standard.

Frequently Asked Questions about technical-writing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure technical documentation with Diátaxis?▼

Diátaxis splits docs into four modes by two questions: does the content inform action or understanding, and does it serve learning or work. Action plus learning is a tutorial, action plus work is a how-to, understanding plus work is reference, and understanding plus learning is explanation. Keep one mode per document and link between them.

How to write clear instructions in technical docs?▼

Write each instruction as a direct command in present tense addressed to the reader as "you". Put the condition before the step, keep one instruction per sentence, and split instructions longer than about 20 words. Never use passive constructions like "the component must be installed".

What is the difference between a tutorial and a how-to guide?▼

A tutorial teaches a beginner by doing, where every step produces a visible result and the teacher owns the learner's success. A how-to solves a specific problem for a competent reader with action only, no teaching, and allows forks like "if you want x, do y".

Does this writing standard apply to PR descriptions and commit messages?▼

Yes. Every layer except Diátaxis applies to PR descriptions and commit messages, since they are writing too. Product UI strings are excluded because they follow product copy guidelines instead.

Why should technical docs avoid words like "simply" and "easily"?▼

Words like "simply", "easy", and "quickly" in procedures insult readers who are stuck, since if the task were simple they would not be reading the doc. Google developer style prohibits them in instructions along with buzzwords and figurative language.