---
name: dashboards
description: Build, publish, open, refresh, inspect, stop, or troubleshoot EzWebex dashboards. Use for dashboard requests, dashboard status, dashboard URLs, visual/display requests, My Day dashboards, local services status dashboards, action queues, important spaces, helper process status, ports, logs, listeners, or daemon health. When the user asks for a dashboard without specifying which one, default to the My Day dashboard.
---

# EzWebex Dashboards

Use this skill for EzWebex dashboard work. The default dashboard is the My Day dashboard when the user asks for "the dashboard", "show my dashboard", "open dashboard", or any other dashboard request without naming a specific dashboard.

## Shortcuts

- `/ezdashboard`: open or refresh the default My Day dashboard.
- `/ezstatus`: open the Local Services dashboard.

These shortcuts are exposed as MCP prompts named `ezdashboard` and `ezstatus` when the Codex app surfaces MCP prompts in the slash-command menu. If the current app build does not show plugin MCP prompts as slash commands, use `$dashboards` with "my day" or "local services status" wording for the same behavior.

## Dashboard Routing

- My Day dashboard: default. Use for day planning, tasks, priorities, action queues, outstanding asks, important spaces, meeting prep, "what should I do today", or any visual/display request about the user's Webex day.
- Local Services dashboard: use when the user asks about EzWebex local helper status, MCP/service health, running processes, listeners, daemons, ports, URLs, logs, local status, or the local services dashboard by name.
- Text briefing: if the user asks to prep or brief the day without show/display/view/open/visual/dashboard language, use the text daily briefing flow instead of a dashboard.

Do not open dashboard URLs with Browser, Computer Use, or the system browser unless the user explicitly asks Codex to open a browser. When returning a dashboard URL, return only a standalone Markdown link with the dashboard-specific link name.

## My Day Dashboard

The My Day dashboard is a rich localhost view of Codex-generated Webex analysis: a calendar-like timeline, contextual action items, and a focused list of important spaces.

The dashboard does not re-analyze Webex activity by itself. Refreshes happen in the Codex conversation: gather fresh evidence, publish a new snapshot, then return the dashboard link.

### My Day Triggers

Use My Day when the prompt is an explicit dashboard request or uses visual/display language for day planning:

- "Show me tasks I need to complete today."
- "Show my Webex priorities for today."
- "Display my day prep."
- "View outstanding asks."
- "Open my action queue."
- "What should I do today?" when paired with show/view/dashboard/visual language.

### My Day Main Flow

When the user asks to build, open, or refresh the My Day dashboard from chat:

1. Gather Webex evidence for the user's day.
2. Produce a structured dashboard snapshot.
3. Publish it with `webex-set-my-day-dashboard-snapshot`.
4. Return only a standalone Markdown link named `Open My Day Dashboard`.

Example response:

`[Open My Day Dashboard](http://127.0.0.1:51238/)`

### My Day Evidence Collection

Use Webex meeting and messaging tools to build the snapshot:

- Timeline: list today's meetings in the user's timezone and render them as calendar-like entries.
- Meeting context: inspect meeting status, summaries, recaps, transcripts, recordings, and meeting rooms when they help explain action items.
- Message context: inspect recent direct spaces, recent group spaces, mentions, important threads, and source-linked messages.
- Evidence: keep source URLs or citation markdown from Webex tool results so each task or space can link back to supporting messages or meeting artifacts.

These read-heavy calls, plus `webex-set-my-day-dashboard-snapshot`, may opportunistically update deterministic person-profile hints from returned evidence. After publishing or refreshing a My Day snapshot, run the two-tier profile update model from `$webex-messaging` for up to 5 people who are central to the dashboard: meeting hosts, direct ask authors, blockers, decision owners, and repeatedly relevant collaborators. Keep this invisible to the dashboard flow; skip bots/service accounts; save only compact sourced profile memory. Disable enrichment with `autoUpdatePersonProfiles: false`, `profileSeedMaxPeople: 0`, or when latency matters more than profile warmth.

### My Day Snapshot Requirements

Call `webex-set-my-day-dashboard-snapshot` with:

- `summary`, `generatedAt`, `timezone`, optional `window`, and `timeline`.
- `tasks`: action items with stable `id`, `title`, `details`, `recommendedAction`, `whyItMatters`, `importance`, `confidence`, and `sources`.
- `context` or `spaces`: important spaces with stable `id`, `title`, `status`, `needsMyAttention`, `attentionReason`, `summary`, `latestDecision`, `openQuestions`, `importance`, `activityLabel`, `confidence`, and `sources`.

Use stable IDs based on message ids, meeting ids, room ids, or deterministic combinations of those values. Stable IDs let the dashboard preserve checked and archived task state.

Set `needsMyAttention: true` only when the user was asked something, mentioned recently, assigned work, is blocking progress, or is plausibly expected to respond. Active discussion alone is not enough.

### My Day Lifecycle

- For dashboard status, call `webex-get-my-day-dashboard-status`.
- For stop/close/kill requests, call `webex-stop-my-day-dashboard`.
- For restart requests, stop the dashboard, rebuild the snapshot, publish it, and return the dashboard link.

The dashboard state is local to the MCP process. Do not create persistent files for checkbox or archive state.

## Local Services Dashboard

The Local Services dashboard is a localhost-only status view for EzWebex helper processes and logical workloads. It is read-mostly: it reports state and lets the user inspect health, but it does not start or stop other helpers.

### Local Services Triggers

Use Local Services when the user asks about:

- EzWebex local service status or health.
- MCP helper processes, daemons, listeners, response handlers, or ports.
- OAuth callback helper, Webex deeplink opener, My Day dashboard status, attachment-action listener, attachment response handlers, or the status dashboard itself.
- Opening, refreshing, testing, or stopping the Local Services dashboard.

### Local Services Tools

- `webex-get-local-services-status`: read normalized local status.
- `webex-open-local-services-dashboard`: start or return the localhost status dashboard URL.
- `webex-stop-local-services-dashboard`: stop only the Local Services dashboard.

When opening the dashboard, return only a standalone Markdown link named `Open EzWebex Local Services`.

Example response:

`[Open EzWebex Local Services](http://127.0.0.1:51240/)`

### Local Services Scope

The dashboard tracks:

- OAuth callback helper.
- Webex deeplink opener.
- My Day dashboard.
- Attachment-action listener.
- Attachment response handlers.
- Local Services dashboard itself.

It reports state, pid, ports/URLs, heartbeat freshness, last activity, errors, and response-handler counts using local MCP process state plus local files under `CODEX_HOME/webex-messaging/`.

### Local Services Lifecycle

- For a quick status answer, call `webex-get-local-services-status`.
- For a live visual surface, call `webex-open-local-services-dashboard`.
- For stop/close/kill requests that name the Local Services dashboard, call `webex-stop-local-services-dashboard`.
- Do not stop My Day, the attachment-action listener, or other helpers from this dashboard flow unless the user separately asks for that specific service and a dedicated tool exists.

The Local Services dashboard binds only to `127.0.0.1`. If localhost binding is blocked in a sandboxed test, mention the sandbox limitation and verify through the real plugin runtime when possible.
