bestdeejay-design 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. - 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.