build-publish-checklisted

# Build: /publish-check You are about to generate a `/publish-check` skill customised to this company's governance rules. Complete all three phases first. ## Phase 1 — Inspect 1. **Extract the implicit conventions.** Sample 15–20 existing dashboards (via BI metadata, API, or exports). Record: naming patterns, folder/space structure, description field usage (usually empty — count the empties, it goes in your summary), owner metadata, any certification/badge system. 2. **Find the governed core, if one exists.** Certified spaces, "official" folders, a metric dictionary. The generated skill will defend that core; if there is none, the skill's first job is to define the boundary. 3. **Check the semantic layer for governed metrics.** dbt metrics, Lightdash `meta` blocks, LookML measures marked as canonical. A dashboard that recomputes a governed metric with hand-written SQL is the top thing the gate must catch. ## Phase 2 — Interview 1. **"What does 'published' mean here today?"** Usually: nothing — anyone shares anything. The generated skill introduces the distinction: personal/draft space is free; the shared estate has a gate. Freedom to explore, governance at the boundary. 2. **"What are the non-negotiables for a shared dashboard?"** Propose the four I have never regretted: a named owner (a person, not a team), a one-sentence purpose in the description, every metric traceable to a governed definition, a lifecycle stage (draft / active / deprecated). Let them add, but push b