Docs System — meta-guide & router

This skill is now the meta-guide. The two branches live in focused skills: load them directly. Use this skill for the big picture: which docs to write, in which order, and how complete the set must be.

Two branches of documentation

Rule: product docs answer «why» and «what»; engineering docs answer «how». If a doc has no reader and no question it answers — it does not belong.

When to use this skill (router)

• The task is about the documentation SYSTEM as a whole: what to write, in what order, how complete.
• The phases / levels / completeness gates need to be applied.
• The task is clearly product OR engineering → load the branch directly instead.

Order and levels

• Phase order (when to write each doc): references/order.md.
• Levels L1/L2/L3 (how deep a doc set must be for the system size): references/levels.md.
• Completeness checklist (what a complete doc set looks like): references/completeness.md.

Golden rules

• Nothing is written "from the end": VISION → PRD → ROADMAP → FEATURES, then engineering docs.
• Contracts (OpenAPI/AsyncAPI) are written BEFORE code.
• The map (REFERENCE.md) is written last — it describes everything above it.
• Example monorepo that follows all rules: examples/example-monorepo/.
• Skill roadmap: ROADMAP.md.

Removal plan

Keep as the meta-guide (not deprecated — it still carries order/levels/ completeness). The two branches are the focused entry points.

Boundaries

• Do not use to author one document branch directly; route to docs-product or docs-project.

Evidence and completion gate

Ground recommendations in the supplied repository or brief. State assumptions, missing inputs, and unresolved risks. Return a concrete artifact or checklist with an owner/action for each open item, then verify that the result answers the requested goal rather than merely repeating the framework.