Enforce the fixed 23-file, 8-directory documentation package under the resolved output root — routing each document to its required-content contract in `references/package-contract-*.md`, stamping the internal or public header, and refusing to add, drop, rename, or merge a canonical file. Use when scaffolding a package, drafting or revising any canonical document, or checking structural completeness. This skill MUST be consulted because a package whose shape changes per project cannot be diffed, audited, or compared across engagements — the structure is the contract and only the content adapts.

Merge the independent A/B/C findings tables into one adjudicated ledger in `07-verification/documentation-verification-report.md` — normalizing to the finding schema, deduplicating by location and claim, recording per-finding corroboration without downgrading single-pass findings, promoting cross-pass disagreement to its own Critical finding, and splitting repairs into agent-repairable and owner-decision. Use when all three verification passes have returned their findings at Phase 9, or when ingesting an externally-produced audit. This skill MUST be consulted because publishing the findings table before repair is what makes the audit trail real, and because treating a lone dissenting pass as noise is exactly the correlated-error failure the three-pass design exists to prevent.

Maintain `00-control/assumptions-questions-and-contradictions.md` — the assumptions and open-questions register (`AQ-####`) and the contradiction register (`CT-####`) — classifying each entry as blocking, material but non-blocking, or minor, and routing blocking gaps to owner resolution before drafting proceeds. Use when a source is silent on a required topic, when two sources disagree, or when a verification pass reports conflicting evidence for the same claim. This skill MUST be consulted because a documented unknown is a deliverable and a silently-filled gap is a defect — a package that papers over a contradiction transfers risk to the reader without telling them it exists.

Build one canonical project model — entities, boundaries, owners, lifecycle state, and end-to-end traces — and record its authoritative names in `00-control/terminology-and-ownership.md` (`TM-####`), then project that single model into every audience view without ever forking it. Use when starting Phase 2, when the project type is ambiguous, or when two documents describe the same component differently. This skill MUST be consulted because multiple independent mental models produce documents that contradict each other under diligence, and audience-specific rewriting is the single most common source of drift in a documentation package.