docs-cockpit-rebuildlisted

# docs-cockpit-rebuild **The 5-phase workflow for diagnosing and refreshing an existing module ↔ subtask ↔ spec/plan/RFC association system — and for answering "how is the project doing" along the way.** ## Why this skill exists `docs-cockpit-build` creates the association system; this skill keeps it true. Anchors are line ranges and section headings into living files — every refactor moves code, every spec revision moves sections, and an anchor that pointed at the right lines last sprint can silently point at garbage today. The same principle that governs build governs rebuild, only more urgently: **a wrong anchor is worse than a missing anchor.** A drifted anchor sends the user to irrelevant content while *looking* authoritative, which destroys trust in the entire dashboard. So rebuild's job is precision maintenance: re-verify everything, re-infer only what broke, and touch nothing that is still accurate. ## Rebuild vs build Both skills share the same four atomic methods in `references/association-method.md` — they differ in direction and scope: - **build** = 0→1. Whole-project association planning, every linkage decided WITH the user in dialogue, gap docs drafted. - **rebuild** = incremental. An association already exists; diagnose which anchors drifted, refresh ONLY those, keep accurate ones byte-for-byte intact (minimal diff). If no association exists at all (no `docs:` / `subtasks` anchors anywhere), stop and hand off to `docs-cockpit-build` — diagnosing an empty