Knowledge Doc Writing (Diátaxis)Diátaxis 知識文件寫作

Engineering-grade knowledge docs on the Diátaxis model — tutorial, how-to, reference, explanation — writing only what the material supports and flagging the gaps honestly. A discipline that travels across domains以 Diátaxis 模型寫工程等級的知識文件(tutorial、how-to、reference、explanation),素材撐得起才寫,缺口據實標出。這套紀律跨領域通用

繁中Model-invoked模型叫用
Read SKILL.md on GitHub在 GitHub 看 SKILL.md

This skill turns a technical topic you've studied or researched — a conversation transcript, raw source material, or a from-scratch investigation — into a single lasting reference document split into four cleanly separated Diátaxis sections: tutorial, how-to, reference, and explanation. It writes only what the material can actually support, and names the gaps instead of padding them with invented content.

Install

npx skills add https://github.com/leoluyi/skills -g -a knowledge-doc-writing -y

To update later:

npx skills update knowledge-doc-writing

Source

What it does

Every piece of input material gets routed through a compass — two yes/no questions applied to each chunk:

  1. Action or cognition? Does this material have the reader do something, or does it build understanding?
  2. Acquisition or application? Does it serve the reader while they're still acquiring the skill (studying), or while they're applying a skill they already have (working)?

The two answers point to exactly one of four quadrants:

Acquisition (at study) Application (at work)
Action tutorial how-to
Cognition explanation reference

Each piece of material lands in exactly one section. A passage that answers both quadrants at once is a signal to split it, not to write it twice. The result is an auditable material-to-section assignment table, checked before any prose gets written.

The four sections stay pure and never mix:

  • tutorial — a single safe straight line for a first-time reader, first-person-plural imperative voice, no branching, no digressions.
  • how-to — assumes competence, goal-oriented, if-then branching allowed, no teaching.
  • reference — describe-only, neutral, mirrors the underlying product's own structure, no argument.
  • explanation — the only section allowed to carry judgment: a What/Why argument, trade-off decisions, mental models, common misconceptions.

If a quadrant has no material behind it — commonly tutorial or how-to, when a topic was researched but never actually run hands-on — that section is marked as an explicit gap with the condition needed to fill it, rather than being faked or left as an empty shell.

Inside explanation, a comparative recipe runs as an internal device rather than a section of its own: definition, behavioral boundary, comparative analysis, a boundary-judgment table for the grey areas, and a decision framework that states both when to adopt and when not to — the "when not to" half carries as much weight as the "when to," since a comparison that skips it reads as advertising rather than analysis.

When to use

Use this when you want to distill a technical topic you studied or researched into one lasting reference document, cleanly split into tutorial, how-to, reference, and explanation sections. That covers digesting a conversation transcript, reorganizing raw source material (official docs, specs, meeting notes) by reader need rather than by the source's own table of contents, and researching an unfamiliar topic from scratch (with mandatory primary-source checks and as-of dating).

It also handles rewriting an existing technical document, branching on intent rather than on the verb used:

  • Refresh currency or fold in new material → a point-patch: keep the document's original shape and change only the parts affected by staleness or new content. This path never runs the compass and never reorders the whole document.
  • Reorganize or restructure → hand the material to the compass and rebuild the four sections from scratch.

When not to

  • Internal administrative documents — 簽呈, meeting minutes, evaluation reports — even when the input is an existing document that looks like it belongs here; hand those to formal-doc-structure instead.
  • RFPs or procurement specs — use rfp-writing.
  • Blog posts — use blog-writing-zh.
  • Language-only cleanup that doesn't touch structure — use humanizer-zh.
  • A spoken plain-language explanation with no document to produce — use plain-speak.
  • The interactive learning loop itself, where the user does their own hands-on distillation — that's learn-loop's job, not this skill's.

How it works

The compass is the load-bearing mechanism: nothing gets written until every piece of material has been run through both questions and logged in the assignment table. A section only gets written if it has material behind it, and it's held to its boundary's purity — reference never carries an opinion, explanation never turns into an empty scaffold, tutorial never grows real-world branching, how-to never turns into a teaching aside.

After drafting, two adjacent-pair checks catch the most common blurs, because adjacent quadrants share one dimension and are the easiest to confuse for each other:

  • tutorial ↔ how-to (both action-oriented, differing only on study-vs-work) — the most damaging blur, since it blocks a beginner with real-world branching they aren't ready for. Any conditional step that assumes prior judgment gets pulled out of tutorial and placed in how-to.
  • reference ↔ explanation (both propositional, differing only on describe-vs-discuss) — any argument or opinion that leaked into reference gets pulled out and placed in explanation.

Anything that crosses a boundary becomes a cross-link, never inline-mixed prose. A gap section gets a single line noting the gap and the condition that would fill it — never a placeholder paragraph pretending to be content.

This skill sits downstream of learn-loop. learn owns the interactive learning loop and the hands-on distillation itself — digesting material into your own words, judging whether you actually understand it — and that step is never delegated or redone here. What this skill receives is understanding that's already settled: its only job is reorganizing that understanding for an external reader, filling in the context a third party would need, converting or dropping vault-specific markup like wikilinks, and carrying forward already-verified sources with the as-of date updated to publication time.

Before delivery, two quality gates run in order — functional quality (every claim traced to a primary source, as-of dates and version ranges marked, no fabricated sources, a de-AI pass to zero) always clears before any polish for flow or beauty. A document can be complete and shippable with only one or two of the four sections written, as long as every section is either covered or explicitly marked as a gap — no silent omissions, no shell sections waiting to be filled in later.

Related skills

  • formal-doc-structure — owns 簽呈, meeting minutes, and evaluation reports; administrative documents route there even when they arrive in a format that looks like this skill's territory.
  • rfp-writing — owns RFPs and procurement specs, which follow structural rules that conflict with this skill's Diátaxis routing.
  • blog-writing-zh — owns blog posts and reader-voice composition, a different genre from a reference document.
  • humanizer-zh — owns pure language-layer de-AI cleanup when no structural reorganization is needed; this skill calls it as the de-AI pass before delivery when available.
  • plain-speak — owns spoken, on-the-spot plain-language explanation with no document as the deliverable.
  • learn-loop — owns the interactive learning loop and the hands-on distillation itself; this skill only picks up after that distillation is done, to reorganize and add reader context.

這個 skill 把你自學或研究過的技術主題——對話紀錄、原始資料,或從零開始的研究——整理成一份長期可參考的文件,內含四個清楚分離的 Diátaxis 區塊:tutorial、how-to、reference、explanation。它只寫素材真正撐得起的部分,撐不起的型明列為缺口,而不是硬填內容湊數。

安裝

npx skills add https://github.com/leoluyi/skills -g -a knowledge-doc-writing -y

之後更新:

npx skills update knowledge-doc-writing

Source

它做什麼

每段輸入素材都會經過一個 compass——對每段素材問兩個問題:

  1. 行動還是認知? 這段素材要讀者「做」什麼,還是要讀者「理解」什麼?
  2. 習得還是應用? 這段素材服務的是讀者還在習得這個技能的階段(在學),還是已經具備技能、正在應用的階段(在做)?

兩個答案機械式地指向四個象限中的唯一一個:

習得(在學) 應用(在做)
行動 tutorial how-to
認知 explanation reference

每段素材只落在一個區塊裡。如果一段內容同時回答了兩個象限,那是拆分的訊號,而不是重複寫兩次的理由。結果是一張可稽核的「素材 → 區塊」對應表,在動筆寫任何一段之前先確立。

四個區塊彼此不混:

  • tutorial(帶著上手)——給第一次接觸的讀者走一條安全的直線,第一人稱複數祈使語氣,不分支、不離題。
  • how-to(照著完成任務)——假設讀者已有能力,目標導向,允許 if-then 分支,不教學。
  • reference(查參數與結構)——只描述、中立,鏡射產品本身的結構,不帶論述。
  • explanation(What/Why 論述與取捨決策)——唯一允許帶判斷的區塊:What/Why 論證、取捨決策、心智模型、常見誤解。

如果某個象限完全沒有素材支撐——常見於 tutorial 或 how-to,也就是主題只做過研究、從未親手實作過的情況——這個區塊就明列為缺口,並標出補齊所需的條件,而不是捏造內容或留一個空殼。

在 explanation 內部,還有一套辯證比較的內部裝置(不自成一個獨立區塊):定義、行為職責邊界、比較分析、收灰色地帶的邊界判斷表,以及一個同時交代「該採用」與「不該採用」的決策框架——「不該」那半邊跟「該」同等重要,省略它的比較讀起來就只是廣告,不是分析。

何時使用

當你想把自學或研究過的技術主題,整理成可長期參考、tutorial/how-to/reference/explanation 四型分離的知識文件時,用這個 skill。這涵蓋消化一份對話紀錄、依讀者需求(而非原始資料自己的目錄順序)重新組織官方文件/規格/會議紀錄等原始資料,以及從零研究一個陌生主題(強制查一手來源並標 as-of 時效)。

它也處理改寫既有技術文件,依「意圖」而非動詞本身分流:

  • 更新時效/併入新素材 → 定點修補:保留文件原本的形狀,只改動因時效或新素材而受影響的部分。這條路徑不會進入 compass,也不會重新排列整份文件。
  • 重整/重構 → 交給 compass 重建四型區塊,從頭依素材重新分派。

何時不要

  • 公司內部行政文件——簽呈、會議紀錄、評估報告——即使輸入本身是一份既有文件、外觀像是這個 skill 的範圍,也一律交給 formal-doc-structure
  • RFP/招標規格——用 rfp-writing
  • 部落格文章——用 blog-writing-zh
  • 只做語言層去 AI 味、不動結構——用 humanizer-zh
  • 只要口頭白話解釋、不產出文件——用 plain-speak
  • learn-loop 的互動學習迴圈本身,也就是讀者親手做的 distillation——那是 learn-loop 的工作,不是這個 skill 的。

運作方式

Compass 是這個 skill 的核心機制:在任何一段散文動筆之前,每段素材都必須先經過兩個問題的檢驗,並記錄在對應表裡。一個區塊只有在素材撐得起的情況下才會被寫出來,而且會被要求守住自己的邊界——reference 不帶意見,explanation 不淪為空殼架構,tutorial 不長出真實世界的分支,how-to 不變成教學式的旁白。

草稿完成後,會做兩組相鄰型別的自查——相鄰象限只差一個維度,也最容易彼此混淆:

  • tutorial ↔ how-to(同屬行動導向,只差在在學或在做)——最傷讀者的一種混淆,因為真實世界的分支會擋住一個初學者。任何預設讀者已有判斷力的條件分支,都要從 tutorial 抽出來放進 how-to。
  • reference ↔ explanation(同屬命題性知識,只差在描述或論述)——任何滲進 reference 的論述或意見,都要抽出來放進 explanation。

任何跨型別的內容一律改成連結,不會內嵌混寫。缺口型區塊只留一行說明缺口與補齊條件,不寫成假裝有內容的段落。

這個 skill 接在 learn-loop 之後。learn 負責互動學習迴圈與親手 distillation 本身——把素材消化成自己的話、判斷自己是否真的理解——這一步永遠不會被本 skill 代勞或重做。本 skill 接手的是已經確定下來的理解:它唯一的工作是把這份理解重新組織給外部讀者看,補上第三方讀者需要的上下文,改寫或拿掉 vault 專用的標記(如 [[wikilinks]]),並沿用已經查證過的來源、把 as-of 時效更新到發布當下。

出稿前有兩道品質關卡,且順序固定:功能性品質(每個論點都能追溯到一手來源、標出 as-of 時效與版本範圍、沒有捏造的來源、去 AI 味通過到零)永遠先於深度品質(行文流暢與美感)過關。一份文件即使只寫出四型中的一到兩型也可以算完整可交付,只要每一型都被明確標為「已涵蓋」或「明列為缺口」——不能有默默省略,也不能有留待日後填補的空殼區塊。

相關技能

  • formal-doc-structure——負責簽呈、會議紀錄、評估報告;行政文件即使以看似本 skill 範圍的格式出現,也一律轉給它。
  • rfp-writing——負責 RFP 與招標規格,其結構規則與本 skill 的 Diátaxis 路由邏輯相衝突。
  • blog-writing-zh——負責部落格文章與讀者語氣的營造,與參考文件是不同的體裁。
  • humanizer-zh——負責純語言層的去 AI 味清理,不涉及結構重整;本 skill 在出稿前的去 AI 味環節會呼叫它(若可用)。
  • plain-speak——負責即時口頭的白話解釋,不以產出文件為目標。
  • learn-loop——負責互動學習迴圈與親手 distillation 本身;本 skill 只在 distillation 完成之後接手,重新組織並補上讀者上下文。