knowledge-doc-writing
Solid把自學或研究一個技術主題的成果，整理成一份包含四個清楚分離 Diátaxis 區塊的知識文件——tutorial（帶著上手）、 how-to（照著完成任務）、reference（查參數與結構）、explanation（What/Why 論述與取捨決策）；用 compass 兩問把每段素材路由到對應區塊，素材撐得起才寫，撐不起的型（研究過但未實作常缺 tutorial/how-to）明列為缺口， 不捏造、不搭空殼（繁體中文為主、術語保留英文）。觸發：使用者要把對話紀錄、官方文件或原始資料、或從零研究的主題 （強制查一手來源並標 as-of 時效）消化成可長期參考的技術文件；或改寫一份既有技術文件——依意圖分流： 更新時效／��入新素材→定點修補保留原形，重整／重構→依 compass 重建四型區塊。可接在 learn-loop 之後： learn 管互動學習迴圈與親手 distillation（鐵律：distillation 是學習本身，不代寫）， 本 skill 只接手 distill 完成後重新組織、補讀者上下文、套完稿檢查。不要用於：公司內部簽呈／會議紀錄／ 評估報告等行政文件（用 formal-doc-structure，即使輸入是既有文件也不因此轉入本 skill）、RFP／招標規格 （用 rfp-writing）、部落格文章（用 blog-writing-zh）、只做語言層去 AI 味不動結構（用 avoid-ai-writing-zh）、 只要口頭白話解釋不產文件（用 plain-speak）、learn 的互動學習迴圈本身（用 learn-loop）。
Install
Quality Score: 78/100
Skill Content
Details
- Author
- leoluyi
- Repository
- leoluyi/skills
- Created
- 3 months ago
- Last Updated
- today
- Language
- Python
- License
- MIT
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
writing-docs
Use when writing, restructuring, or reviewing any prose documentation — a tutorial, how-to guide, reference page, or explanation/conceptual doc — for a public docs site (e.g. Mintlify MDX, docs/, README material), a getting-started guide, an API/CLI reference page, or a "why we built it this way" conceptual page. Applies the Diátaxis framework (see https://diataxis.fr/) — every document belongs to exactly one of the four quadrants (tutorial / how-to guide / reference / explanation), and mixing quadrants inside one document is the single most common documentation failure. Covers the four-quadrant compass for picking the right form, per-quadrant structure templates, an anti-pattern list for quadrant drift, and generic voice/craft rules — repo-specific voice and target output format (e.g. Mintlify MDX) are resolved from the repo's docs-manifest (falling back to project-context), never hardcoded here.
doc-standards
Documentation writing-quality standards — controlled language (ASD-STE100), Google/Microsoft style guide rules, ISO 24495 plain language, AI/agent readability (llms.txt, self-contained sections), and a machine-checkable lint gate. Use whenever writing or reviewing ANY documentation prose — README, API reference, tutorial, how-to, changelog, error message, code comment blocks, llms.txt — even if the user only says "write docs", "document this", "improve the README", "docs smell like AI", or "make the docs clearer". Structure/coverage questions (which doc types exist) belong to a Diátaxis-structure skill if one is installed; THIS skill governs how each sentence and section is written, and provides the lint gate to verify it.
hive-technical-writing
Writing developer-facing prose that can be skimmed first and trusted enough to finish — READMEs, guides, tutorials, reference docs, proposals, PR descriptions, release notes. Use when creating or editing any technical document, when a doc reads as a wall of text, when claims need receipts, or when docs must serve AI agents as well as humans. Covers reader-first structure, falsifiable claims, docs-as-behavior verification, and agent-readable reference shape. For diagram choice and syntax see diagrams; for API reference semantics see api-design; for CLI help text see cli-design.