build-knowledge-baselisted

# Build: your knowledge base + /write-doc You are about to generate a knowledge base structure and a `/write-doc` skill customised to this company. Complete all three phases first. ## Phase 1 — Inspect 1. **Find what documentation exists.** Repo markdown, `schema.yml` descriptions, dbt docs blocks, README files, links to Confluence/Notion in code comments. Record coverage and — more important — staleness: `git log` the docs against the code they describe. Count the pages whose code has changed since the doc last did. That number goes in your summary; it is usually the moment the docs owner winces. 2. **Find the questions.** The best source of a knowledge base's table of contents is the support channel. If you can see it (exports, a linked Slack MCP), harvest the 20 most repeated questions. If not, note it as interview question 1. 3. **Map the documentable surface.** Models (how many, which layers), dashboards/explores in the BI config, metrics in the semantic layer. The knowledge base does not document all of it — Phase 2 decides the priority tier. 4. **Detect the docs venue and format conventions.** Where docs live (repo markdown, dbt docs, Notion, Confluence), heading styles, any templates already in use. ## Phase 2 — Interview 1. **"What are the ten questions your team answers most often?"** (Skip if Phase 1.2 found them.) These become the knowledge base's first ten pages — demand-driven, not schema-driven. 2. **"Where must the docs live?"** Confirm the venue from Pha