The DeepSeek Harness documentation standard: make every page searchable, newcomer-readable, and exact enough for agents and maintainers, and keep the documentation website a tested projection of repository Markdown. Apply repository files and executed gates first, then this workflow for kind-mapped metadata, progressive detail, line-aligned bilingual pages, corpus audits, and website publication. Preserve one owner per fact: source, tests, generated catalogs, package READMEs, guides, Agent Notes, and scratch each keep their own kind of truth. The README pair is the reference example of the format.

Follow this sequence for each requested scope. Keep the common reader path brief, but do not delete failures, ownership, limitations, or other required contracts merely to reduce words.

Documentation states how the product behaves today, and the only admissible evidence for an operation claim is having run it. This procedure is mandatory for every new document and every new paragraph that claims an operation, command, default, error, or platform difference.

The frontmatter field selects exactly one README template. Every kind in the metadata reference maps to one template file in

templates/

, and every template backs exactly one kind; the documentation check derives the expected kind from the same mechanical facts.

Open the template before writing and follow its skeleton and rules; it states what the kind is, how the page is structured, and the fact checks each section owes. Add a new kind only together with a distinct template file, a documented repository position or declared owner, and a focused check that maps documents to it.

These rules decide what a section may say. They apply to every authored human-facing page, and to package READMEs with particular force.

Use these definitions in review. Each section opens with a short orienting paragraph before subsections or exhaustive detail.

Do not apply a universal word limit to exhaustive references. Measure entry-path length, unrelated material scanned for one lookup, largest section, heading count, and page size; split by an existing domain owner when retrieval cost is high.

Read, do not re-summarize, the owning contracts: docs/AGENTS.md for hierarchy, tutorial/reference forms, taxonomy, budgets, and the slop checklist; .agents/notes/README.md for Agent Note lifecycle; docs/i18n/README.md for the bilingual pairing rules; and root AGENTS.md for standing orders. Exclude from audits and edits — archived notes are frozen history.

Apply the standard's authoring order to every human-facing document in scope (not to Agent Notes): locate the document and state its own subject; set the permitted detail level and move deeper explanations to owning descendants with links; classify tutorial or reference from intended use, not path; for a tutorial, order concepts by prerequisite and difficulty; split substantial mixed forms. Then check placement constraints: paired docs cost a counterpart update and a re-record on every edit; generated catalogs are never hand-edited; a move is atomic with every inbound link repaired in the same change.

After the structural pass, hunt the slop checklist with the cheapest probes first. Use dsh-trim-cot-leakage for reasoning-transcript leakage, grep distinctive phrases to find duplicated rules, replace hand-written catalogs and status inventories with their authoritative owners, and remove migration plans and future-tense spec language from implemented Agent Notes. Measure outliers with and a word-count scan; if removing prose changes a promised behavior rather than its explanation, propose the behavior change first (follow dsh-find-simplifications). Keep every load-bearing rule, preferably as one to three lines plus a link to its rationale; do not create a new explanation merely to relocate disposable reasoning.

compares standing documents against ceilings in scripts/doc-budgets.manifest.json; a red gate follows the ordered relocate-condense-raise policy in docs/AGENTS.md. Ceilings are guardrails, not reduction targets: at or below target, retain at least 5% headroom; raise a ceiling only when the words need the space, and justify the manifest diff in the PR.

The website is a tested projection, never a second copy: website/docs.ts is the explicit public allowlist mapping canonical sources into route trees, scripts/project-doc-site.ts rewrites them into the disposable tree, and VitePress builds that tree. Repository Markdown stays the only editable content source; translations stay sibling pairs (, , ), never locale directories. Edit an already published page in its canonical source only; add one manifest entry for a new page; update source, manifest entry, and inbound links atomically for a move or removal; never edit , , or . Set every field deliberately and honor the projector's link rules; see references/website-sync.md for the fields, sidebar collections, and preview commands. Synchronizing content into the build does not publish it: deployment stays a separate, explicitly requested step.

Load only the reference needed for the task. Each reference links directly from this file so the skill has no deep reference chain.

The four README templates in

templates/

are the working skeletons for the four labels; open the one your document's kind names before writing.

Use dsh-prose-standard for sentence-level contract coverage and editorial judgment. The README pair (English, Chinese) is the reference example: searchable YAML, Summary and Table of Contents, user-to-developer progression with a folded developer section, Further Exploration, canonical Model Experience and Known Limitations sections, and a final Dev Note.

Validate the affected format, not merely Markdown syntax. A strong promise needs a focused valid fixture and an invalid fixture that proves the top-level gate can fail.

Run for the quick comprehensive documentation checks (pairing, wrap, links, README gates, budgets, skill metadata, Agent Note gates) before the full .

None.