Live Dashboard

Live Dashboard

Turn one sentence — "make a dashboard for our visa applications, update it daily from the email threads and the case-status site" — into a persistent, self-refreshing status page. The user describes what they want to see; you define the data contract, build a self-contained HTML dashboard, verify one live refresh, then schedule the recurring tick.

Setup runs once in the foreground; the recurring refresh runs as a cronjob tick. Installing this skill offers a daily all-dashboards sweep via /suggestions (the frontmatter blueprint).

When to Use

• "Make a dashboard for <project/process> and keep it updated."
• "I want one place to see the status of <deals / applications / bugs / shipments>."
• "Track <thing> across my email and <website> and show me where it stands."
• "Show me the <slug> dashboard." (re-render/preview an existing one)
• A cron tick fires for an existing dashboard (steps 5-7).

Don't use for: one-off status questions (answer directly), price/availability thresholds on a single item (use product-price-monitor), or company news tracking (use competitor-news-monitor).

Prerequisites

• At least one source connector the dashboard will read from: email/calendar via himalaya or google-workspace, websites via web_extract or browser_navigate, local files via read_file. If none is configured, renegotiate the sources in step 1 before writing any artifact.
• cronjob for the recurring tick.
• Optional: the desktop_preview tool (Hermes desktop app sessions). When it is in the toolset, dashboards render in the in-app preview pane; otherwise the user is given the file path.

Procedure — Setup (foreground, once)

1. Define the dashboard contract

From the user's sentence, pin down: the dashboard's purpose in one line, the entities being tracked (rows), the fields per entity (columns/indicators), what "needs attention" means, the sources each field is read from, and the refresh cadence. Ask about anything ambiguous — a dashboard that tracks the wrong grain is worthless. Done when every field on the dashboard names the source it will be read from.

2. Verify each source with one live read

For each source, do one bounded foreground read now: email/calendar via the connector skills (himalaya, google-workspace), websites via web_extract or browser_navigate, local files via read_file. Record what was actually retrievable — auth walls, missing permissions, or empty results surface here, not on the first scheduled run. Drop or replace sources that fail. Done when every field's source returned real data or was explicitly renegotiated with the user.

3. Build the dashboard artifact

Write two files under the Hermes home directory's dashboards/<slug>/ (the same directory that holds config.yaml; never assume a fixed location):

• dashboard.json — the contract plus current state: purpose, entities, per-field values, per-field source + retrieval timestamp, a needs_attention list, and a change log (append-only, most recent first).
• index.html — a single self-contained HTML page (inline CSS, no external requests) rendering the state: a header with purpose and last-updated time, a "Needs attention" section on top, the entity table, and the recent-changes list. Regenerate it from dashboard.json on every refresh; never hand-edit HTML state.

Populate both from the step-2 reads, then show the result (step 8). Done when the page renders the live data and every value on it carries a retrieval timestamp in dashboard.json.

4. Schedule the refresh

Only after step 3 succeeded, schedule the tick. If the daily all-dashboards sweep from /suggestions is already scheduled and its cadence suits, it will pick this dashboard up — say so and stop. Otherwise create a per-dashboard job whose prompt names the state file:

cronjob(action="create",
        schedule=<cadence from the contract, e.g. "0 8 * * *">,
        prompt="Load the live-dashboard skill and run the refresh tick for the dashboard at <absolute path to dashboards/<slug>/dashboard.json>.",
        deliver=<user's destination>)

Pick a cadence that respects source rate limits. Done when a job covering this dashboard exists and its prompt names the state-file path (or the sweep).

Procedure — Tick (each scheduled run)

5. Re-read sources and diff

Load dashboard.json (for the sweep: every dashboards/*/dashboard.json, one at a time), re-read each field from its named source, and compute a field-level diff against the stored state. A failed source read means unknown state: keep the last good value, mark the field stale with the failure time, and never overwrite good data with an error. Done when every field is either updated, unchanged, or explicitly marked stale.