/marketing-os-dashboard

name: marketing-os-dashboard
description: "Build, rebuild, and deploy the Marketing OS control center: a self-contained single-page dashboard rendered from the OS files, eleven pages in six nav groups (Core, Calendar, Content, Campaigns, Funnel, Performance, Learnings, Audience, Intelligence, Team, System). Interviews the user on first build to decide which pages earn a place, then reads the OS, assembles one inline JSON data block, swaps it into the fixed page shell, verifies the page opens with no external requests, deploys to a live URL and records it in config. Renders gaps as 'not pulled' rather than zero, flags any routine that should have run and did not, and renders correctly in both light and dark palettes. Bundled shell ships with the skill. Run from the Marketing OS root. Use when the user says 'build my marketing dashboard', 'rebuild the control center', 'update the marketing OS dashboard', 'deploy my marketing dashboard', 'my dashboard is stale', 'marketing os dashboard', or runs /marketing-os-dashboard."
disable-model-invocation: true

Marketing OS Dashboard

Render the control center from the OS and deploy it.

**This skill owns the dashboard end to end**, and it ships the only copy of the shell. `marketing-os-setup` writes `Analytics/dashboard/spec.md` and then invokes this skill; it never builds the page itself. Works either way: invoked from setup, or run on its own against an OS that already exists.

Run from the OS root, then branch on what is there:

| State | Do | | --- | --- | | No `Context/config.md` | The OS is not set up. Point the user at `marketing-os-setup` and stop | | `config.md` but no `Analytics/dashboard/spec.md` | **First build.** Run the interview below and write `spec.md` yourself | | `config.md` and `spec.md`, no `control-center.html` | **First build.** Read `spec.md` for the answers, only ask what it does not cover | | All three exist | **Rebuild.** Skip the interview entirely |

Never refuse to run because `spec.md` is missing. It is an output of the first build, not a precondition for it.

**Stay inside that root.** Read and write only within it. Do not list, glob or read elsewhere on the machine, and do not go looking for other vaults or example OS folders. If something outside the root would help, name the one path and ask. **Start from zero on identity.** Every name, org and handle comes from `Context/config.md` or from the user in this conversation. Never from your context, the system username, the cwd folder name, a git config, or a connected account, and never echoed back as "confirm this?". If `config.md` does not name it, you do not know it: say the key is empty rather than filling it.

The one rule

**The shell is fixed. Only the data changes.**

Read the OS, assemble the JSON, swap it into the inline block, deploy. Do not restructure the page, rename an element id, or change the CSS.

The exception is a first build, when `Analytics/dashboard/control-center.html` does not exist. Copy the bundled shell from `assets/control-center.html` and fill it.

A genuine layout change is deliberate and ordered, never a side effect of a rebuild:

1. Edit `Analytics/dashboard/spec.md` first, so the contract stays the source of truth 2. Then edit the shell to match 3. Then confirm the rebuild still produces the same data shape, and update `references/data-contract.md` if it does not

A drifting shell means nobody can tell whether a rendering oddity is a data problem or a layout problem. This is the only place that procedure is written down.

First build: read the OS, propose the pages, then render

**Only on a first build.** A rebuild skips all of this. If `spec.md` already exists because setup wrote it, read it first and ask only what it leaves open, then write your answers back into it.

Read before you ask

**Never open with a questionnaire against an OS you have not looked at.** Half the answers are already on disk, and asking for them tells the user you did not check.

Walk the tree and inventory it: which of the seven folders exist, which channels are in `Channels/`, which one is `role: primary-original`, how many offers and whether any price has a future effective date, whether `Campaigns/` holds anything live, whether `Team/` exists and how many people, whether any snapshot exists in `Analytics/snapshots/`, whether `Intelligence/competitors/` and the quote bank hold anything real.

Then propose the pages

Eleven ship in the shell. **Not every OS earns all eleven**, and a page that renders an empty state forever teaches the operator to ignore the whole dashboard.

Put all eleven on the table with a verdict each, drawn from what you just read, and let the user correct you:

| Verdict | When | | --- | --- | | **Build it** | The files it reads exist and hold something real | | **Build thin** | The files exist but are nearly empty. Say what fills it and roughly when | | **Empty state** | Nothing for it yet, but the folder exists and a routine will write it | | **Skip** | The OS has no such folder. Name what is missing |

Then say plainly which will be thin and why. A user who knows the Learnings page fills up over a month will not read its empty state as a broken dashboard. A user who was not told will.

**If the OS has something the eleven do not cover**, name it and offer a page for it. A podcast channel, a second community, a partner funnel. Judge it the way the OS judges a folder: it earns a page if a named routine writes the files it would read. If nothing does, say so and leave it out.

The questions worth asking anyway

These are the ones the tree cannot answer. Ask them, then record every answer in `spec.md` so no rebuild has to ask again.

**Three real questions.** Everything else on the old checklist is already on disk, so confirm it from the inventory rather than asking for it.

| Ask | Why it changes the build | | --- | --- | | **1. What is the one question you open this to answer?** | That page becomes the defa