project-intelligence-dashboard

name	project-intelligence-dashboard
description	This skill should be used when the user wants to "open the Revizto dashboard", "set up project intelligence", "show my Revizto projects", "open the Project Intelligence Blueprint", or just installed the Revizto Project Intelligence plugin and needs the dashboard created. It deploys the pre-built, read-only Project Intelligence Blueprint (a fixed, self-contained HTML file bundled with this plugin) as a Cowork artifact, pointed at the installing user's own Revizto licences.
metadata	{"version":"1.0.4"}

Project Intelligence Blueprint — install action

Deploy the pre-built Revizto Project Intelligence Blueprint as a live Cowork artifact.

🚫 CRITICAL — deploy the bundled file verbatim. Do NOT build a dashboard.

The Blueprint is a finished, approved artifact: a single self-contained HTML file (assets/dashboard.html) that ships inside this plugin. Your entire job is to copy that exact file and insert the user's connector prefix into one line, then register it as an artifact.

Its size, line count, checksum, build stamp and tool list all live in assets/manifest.json, generated from the file itself. Never type any of those numbers into this document. Earlier versions did, the numbers went stale at every release, and the guard ended up failing on a correct file — which taught installers to ignore it. Read the manifest instead.

You must NOT, under any circumstances:

• author, write, generate, re-create, "rebuild", redesign, or improve a dashboard;
• summarise the file and reproduce it from memory;
• change the layout, styles, scripts, views, or any HTML/JS other than the single CONFIG.connectors line described below.

If you find yourself writing HTML/CSS/JS for a dashboard, stop — you are doing the wrong thing. The correct action is a byte-for-byte file copy plus one tiny edit. A regenerated dashboard is an automatic failure.

⚠️ Prerequisite — this install MUST run in a LOCAL (on-your-computer) session, not a cloud session

The read tools are authorised for the dashboard artifact only when create_artifact runs locally on the user's computer. In a cloud Cowork session the artifact is registered through the cloud→desktop bridge, which cannot bind the mcp_tools allowlist — so the dashboard opens with an empty allowlist and shows "The Blueprint's tools aren't authorised for this artifact yet" / "Licence not accessible via MCP" / "No projects", no matter how correctly everything else is done.

Before you start: confirm the session is running on this computer (local), not in the cloud. In the Claude app the header shows a cloud icon for cloud sessions and a computer/laptop icon for local ones. To switch: use the run-location control at the top-right of the window and choose "On your computer" (or set the default under Settings → Cowork → turn OFF "Run new tasks in the cloud"). If this is a cloud session, tell the user to switch to on-your-computer and re-run — proceeding in the cloud produces a dashboard that cannot read data ("tools aren't authorised for this artifact"). Confirmed: a local session binds the allowlist and the Blueprint loads live data.

Steps

1 — Confirm a Revizto MCP connector is connected. If no mcp__<id>__list_licenses tool is available in this session, tell the user to add the Revizto MCP connector for their region under Customize → Connectors and stop. The connector is a custom/remote MCP server: transport Streamable HTTP, URL https://api.<region>.revizto.com/mcp, OAuth Client ID revizto-mcp, client secret blank. (The Blueprint still opens without a connector — it shows a calm "Connect the Revizto MCP Server" first-run panel — but has nothing live to read.)

Two Revizto-side conditions are easy to miss, and both surface later as "unreadable licence" rather than as a connection error, so mention them if licences come back blocked:

• The Revizto MCP Server app must be activated on the organisation account (owner/admin: Manage account info → Developer portal).
• Each organisation account must be authorised for that connector. One sign-in only covers accounts on the authentication method used at the time; the rest are authorised from Revizto Workspace → profile → Active sessions → API.

If the user had a connector before 30 July 2026, it was created with the previous OAuth client ID and no longer authorises — it must be removed and re-added with revizto-mcp. Re-adding mints a new connector id, so a previously-deployed Blueprint's allowlist is bound to an id that no longer exists. That is precisely why this skill is being re-run; do not assume the old artifact can be repaired in place.

2 — Copy the bundled dashboard verbatim into your scratch workspace. Do not open it to reproduce it — just copy it:

A="$CLAUDE_PLUGIN_ROOT/skills/project-intelligence-dashboard/assets"
cp "$A/dashboard.html" ./pi-blueprint.html
cat "$A/manifest.json"                        # the expected bytes / lines / sha256 / tools
wc -c < ./pi-blueprint.html                   # must equal .asset.bytes
shasum -a 256 ./pi-blueprint.html | cut -d" " -f1   # must equal .asset.sha256

Compare both against manifest.json. If either differs you have the wrong file, a truncated copy, or a file you generated yourself — do not proceed. If the copy is only a few KB you have definitely got the wrong file.

(If $CLAUDE_PLUGIN_ROOT isn't set in this environment, locate the plugin's skills/project-intelligence-dashboard/assets/dashboard.html on disk and copy that. Never substitute a hand-written file.)

3 — Make EXACTLY ONE edit: insert the connector prefix(es) into CONFIG.connectors. Each Revizto MCP server you add becomes one selectable row in the Blueprint's MCP Server panel; the Blueprint reads from exactly one at a time and the user picks which. Near the top of the copied file the connector array ships empty:

const CONFIG={connectors:[
 /* Add ONE entry per Revizto MCP connection ... */
],readOnly:false,tcsVersion:"…",buildStamp:"…"};

(The tcsVersion and buildStamp values are whatever the shipped file says. Leave them exactly as found — they are not yours to set, and manifest.json records what they should be.)

Read the installer's actual Revizto MCP tool prefix from the connected tool names in this session — the leading mcp__<connector-id>__ segment (e.g. mcp__1a2b3c4d-…__list_licenses → prefix mcp__1a2b3c4d-…__). For each connected Revizto region, add one entry, so the array becomes:

const CONFIG={connectors:[
  {prefix:"mcp__<connector-id>__",wsHost:"ws.revizto.com",missing:[]},
],readOnly:false,tcsVersion:"…",buildStamp:"…"};   // ← both left exactly as they were

Use a single targeted find-and-replace on that one region. Do not touch anything else in the file — no reformatting, no other edits. Read the real prefix; never guess it. (If you genuinely cannot obtain a prefix, you may leave connectors:[] and deploy anyway — the Blueprint will show the connect CTA — but it won't load live data, so prefer inserting the prefix.)

4 — Call every read tool in manifest.json once in this session (mandatory — this is what makes the allowlist bind).

manifest.json → .tools.read is the authoritative list, generated from the build's own argument contract. Use it rather than any list written out in prose, here or anywhere else. A previous release shipped a skill that named nine tools against a build that needed ten, and the missing one was list_accounts — the entry point for licence discovery — so every install produced "no licences at all" and every server looked unauthorised. create_artifact will only put a tool on the artifact's mcp_tools allowlist if you actually called that tool in this session — declaring a tool you never called does nothing, and the dashboard then shows "The Blueprint's tools aren't authorised for this artifact yet." So, for each connected connector prefix, call each of the ten read tools at least once before creating the artifact:

list_accounts is new in 1.0.3 and it is not optional. list_licenses now requires an accountUuid on every Revizto region, so the Blueprint discovers licences by calling list_accounts first and then one scoped list_licenses per available account. If list_accounts is missing from the allowlist the Blueprint finds no licences at all and every server reports as unauthorised. A 1.0.2 install skill will produce exactly that failure against a 1.0.3 build.

1. mcp__<prefix>__list_accounts → the entry point. Take the uuid of an account whose mcpStatus is "available".
2. mcp__<prefix>__list_licenses with that accountUuid → confirm a licence is returned. Take a licenseUuid from the result.
3. mcp__<prefix>__list_license_members and mcp__<prefix>__list_projects (both with that licenseUuid) → take a projectUuid from the result.
4. With that projectUuid, call list_project_members, list_workflows, list_issues, list_sheets, list_clash_tests, list_stamp_templates.

If any call returns empty or errors for lack of data, that's fine — it still counts as "called this session," which is all the allowlist binding needs. The goal is simply that every one of the ten tools has been invoked once so it can be declared. (Repeat per connector prefix if the user has more than one region.)

5 — Register the artifact from the copied file. Call create_artifact with:

• id: revizto-project-intelligence-blueprint (reuse this exact id; never invent a new one).

• html_path: the path to your copied ./pi-blueprint.html (the file from steps 2–3 — not any newly authored file).

• mcp_tools: REQUIRED — this is the whole point of the install. List all ten read tools below, each fully-qualified with the connector's mcp__<connector-id>__ prefix (and repeat the set for every connected prefix). If you omit mcp_tools or pass an empty list, the artifact's allowlist stays empty and the dashboard can never read live data — it will show "tools aren't authorised for this artifact." Also include update_issues (per connector prefix) — this build ships readOnly:false, so the Read-only pill is a live per-session toggle and, when a user switches it off, the count-first + name/reason approval pipeline can execute real writes; update_issues must be on the allowlist for those approved writes to go through. So declare eleven tools per prefix: the ten reads + update_issues. Do not include whoami ("me/my" in 06 resolves to an explicitly chosen user).

  Never call update_issues during install. It is a write. In step 4 you call only the ten read tools; you declare update_issues here without ever invoking it. A real write only ever happens later, when a user toggles read-only off and approves it through the 06 gate.

6 — Verify you deployed the real thing AND the tools bound (mandatory).

• Content: the deployed HTML must match manifest.json on bytes and sha256 (recheck as in step 2 — the only permitted difference from the shipped file is the CONFIG.connectors line you edited, so recompute the hash on the pristine copy, not the edited one). It must also contain the six-view chrome (panel ids incl. panel-issues, panel-health, panel-compare, panel-ask). A dashboard you "built" yourself will be far smaller and will match nothing. If it does not match, you regenerated it — discard and redo from step 2 by copying the file.
• Tools: after the artifact opens, it must reach the Terms gate → licence picker, not the "tools aren't authorised for this artifact yet" panel. If it shows that panel, the mcp_tools did not bind — confirm you (a) called every tool in manifest.json → .tools.read in step 4 and (b) declared all of those plus .tools.write in step 5, then re-create. If it still fails after both, the artifact-creation path on this build is not binding the allowlist — report that to Revizto (capture the desktop version).

7 — Hand off to the user. Tell them the Blueprint is open; on first live load it shows the Terms gate (accept to proceed), then a licence picker; it lands on their most-recently-active project. Point them at the in-product About · Terms · Tour.

Tools to declare (per connected connector prefix)

Read assets/manifest.json and use .tools.read and .tools.write. They are generated from the build's own ARG_CONTRACT, so they cannot drift from what the dashboard actually calls. This section deliberately does not repeat the list: a transcribed list is exactly how the nine-vs-ten failure happened, and tests/run.mjs fails the build if the manifest and the contract ever disagree.

list_accounts is the entry point — licence discovery starts there. See the note in step 4.

Plus update_issues (the 06 Action write tool) — declared so approved writes can execute when the user toggles read-only off. This build ships readOnly:false (the pill is a live per-session toggle; the Blueprint still opens read-only every session). Declare update_issues but never call it during install — it is a write; only user-approved writes through the 06 gate ever invoke it. whoami is intentionally excluded ("me/my" in 06 resolves to an explicitly chosen user).