docs-system

# 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 | Branch | Answers | Skill | |---|---|---| | **Product docs** — «why» and «what» | VISION → PRD → ROADMAP → FEATURES | `docs-product` | | **Project docs** — «how» | README/ENTRY/ARCHITECTURE/ADR/contracts/tests + REFERENCE map | `docs-project` | 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. - ...