authoring-technical-docs

Write concise, high-altitude technical documentation for design docs, RFCs, and PR descriptions.

Updated Sep 1, 2026
One-click install
npx skills add https://github.com/kevinhwang/.agents --skill authoring-technical-docs-kevinhwang
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: authoring-technical-docs
Source: https://github.com/kevinhwang/.agents/tree/main/skills/authoring-technical-docs
Command: npx skills add https://github.com/kevinhwang/.agents --skill authoring-technical-docs-kevinhwang

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Technical documents often become bloated with implementation details, stale line references, and narrative filler, making them slow to read and quick to rot. This Skill enforces a disciplined writing style so design docs, investigation writeups, and PR descriptions stay precise, scannable, and durable as systems evolve. ## Core Features & Use Cases - Altitude control: Keeps prose at the concept level — behavior and intent over control flow — with rules for when code symbols, links, and pseudocode are appropriate. - Structure and visual aids: Summary-first doc structure (TL;DR, context, detail, open questions) plus guidance on tables, Mermaid diagrams, and hand-authored SVGs, including rendering via mmdc. - Prose mechanics: Newspaper-headline brevity, symbol conventions (, , ~), list formatting, and living-doc discipline that forbids changelogs and retrospective framing. - Use Case: Draft a design doc for a service migration: lead with a terse TL;DR table, describe behavior at the system level, attach code links to prose anchors, then publish to Google Docs via the companion md-to-gdoc and gdoc-upsert skills. ## Quick Start Use the authoring-technical-docs skill to write a design doc for the proposed caching layer migration, following its structure and style rules.

Frequently Asked Questions about authoring-technical-docs

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

FAQPage Schema
How do I write a good technical design doc?

Lead with a terse TL;DR stating the outcome and key decisions, then add high-level context, detailed sections broken by concept, and open questions. Describe behavior and intent rather than control flow, and avoid code excerpts and literal line references.

How detailed should technical documentation be?

Write at the concept level: domain concepts, systems, and behaviors, not implementation mechanics. Reference durable symbols like service names or interfaces only when naming them genuinely aids reader understanding.

When should I use Mermaid vs SVG for diagrams?

Use native Mermaid for simple linear flows where automatic layout suffices. Use hand-authored SVG for complex topology, multiple trust boundaries, exact spatial composition, or presentation-quality typography that Mermaid cannot control.

How do I keep a living document up to date?

Rewrite the affected section so it reads as current truth rather than appending corrections or changelogs. Avoid retrospective framing and worklog narrative; the doc should read as if authored fresh against today's reality.

Can I publish Markdown docs to Google Docs?

Yes. Write the doc as local Markdown first, then use the companion md-to-gdoc skill to convert it into a Google Docs batchUpdate plan and gdoc-upsert to create or update the document while preserving layout.