writing-docs

Write persistent project documentation using Diátaxis modes and state-oriented language.

1|Updated Mar 24, 2026
One-click install
npx skills add https://github.com/SgtPooki/skills --skill writing-docs-sgtpooki
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: writing-docs
Source: https://github.com/SgtPooki/skills/tree/main/skills/writing-docs
Command: npx skills add https://github.com/SgtPooki/skills --skill writing-docs-sgtpooki

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Documentation often fails because it mixes tutorials with reference material, describes changes instead of current state, or justifies decisions to reviewers instead of serving future readers. This Skill enforces proven documentation principles so every page serves a reader who has no history of the project. ## Core Features & Use Cases - Diátaxis Mode Selection: Classifies every page as exactly one of tutorial, how-to, reference, or explanation, and prevents mode mixing. - State-Oriented Voice: Rewrites change-oriented language ("we changed X to Y") into state-oriented descriptions ("X provides Y"), with migration sections as the only exception. - Structural Rules: Applies minimalism, "every page is page one" self-containment, and runnable examples in reference entries. - Lint Gate: Runs a writingcheck.py gate (via writing-core) with Google developer-docs style notes before any doc is considered done. - Use Case: You just shipped a new API and need a how-to guide and reference page. The Skill helps you pick the right mode, write in present-tense second person, cut change-justification, and pass the lint gate. ## Quick Start Ask the agent to write a how-to guide for your library's authentication flow using the writing-docs skill.

Frequently Asked Questions about writing-docs

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

FAQPage Schema
How do I structure software documentation with the Diátaxis framework?▼

Assign each page exactly one of four modes: tutorial (guided lesson), how-to (task steps), reference (dry facts), or explanation (context and reasoning). Never mix modes on one page, since mixing is the root cause of most bad docs.

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

A tutorial serves a learner who needs a guaranteed win, so you own the path and outcome. A how-to serves a competent user with a goal, giving numbered steps for one real task without teaching theory.

Should documentation describe what changed in a release?▼

No. Documentation describes the system as it is now, using state-oriented language like "X provides Y". Change history belongs in PR descriptions, changelogs, or a clearly scoped migration section.

When should I not use the writing-docs skill?▼

Do not use it for PR descriptions or issues (use github-writing), decision records like ADRs or RFCs (use writing-spec, even under docs/), or release notes and announcements (use writing-community).

How do I lint Markdown docs against Google developer documentation style?▼

Run the writingcheck.py script from writing-core with the writing-docs argument on your page. Fix reported errors within three passes and treat advisory notes like Google.Passive and Google.Headings as judgment calls.