ChatGPT web Chat mode stop gate (read first)

When positive system or developer signals identify both surface = chatgpt_web and mode = chat, stop before applying any other guidance in this skill. On the first turn of the analytics request, respond only with a concise recommendation to switch to Work Mode because Data Analytics performs best there. Do not load focused analytics skills, inspect data or sources, call tools, ask intake questions, perform analysis, or create an artifact on that turn. Tell the user they can explicitly ask to continue in Chat mode if they prefer.

Proceed in Chat mode only after the recommendation has been shown and the user explicitly says to continue, proceed, or stay in Chat mode. Repeating the original request, adding data, or answering an earlier question does not count as an override. Once the user explicitly overrides the recommendation, resume the original analytics request without making them restate it and follow the ChatGPT web Work Mode runtime branch below for intake, persistence, and outputs. Keep that override for the current analytics request; a new analytics request in Chat mode starts at this stop gate again.

Eligibility gate (read before routing)

Use this plugin only when resolving the request requires structured records, numeric measures, quantitative evidence, a dashboard/metric definition, or a business/product decision grounded in such evidence. Analytics-looking words (report, presentation, dashboard, market, validation, export) are not sufficient by themselves: if the task can be completed as ordinary drafting, formatting, layout, conversion, or qualitative description without data/evidence, do not route here. Explicitly tagged sharing flows can handle their own handoff; this index should not infer a sharing surface from a generic share/export request.

Treat underspecified requests as eligible when they clearly depend on interpreting data, metrics, dashboards, or quantitative business evidence, even if the exact metric or deliverable is not named yet. Load the index, inspect current-session context, or ask for the smallest missing context, then choose the narrowest focused skill. Do not require a named metric upfront; do reject purely mechanical transformations, formatting, code fixes, syntax snippets, or generic explanations that do not require interpreting evidence.

When eligible, choose the most specific analytical skill; when uncertain, ask one clarification rather than opening a generic report/export skill.

Launch/segment decision cue

Eligible product-analytics requests can ask for a product launch, rollout, prioritization, segmentation, experiment readout, A/B test interpretation, or ship/hold/iterate tradeoff recommendation under stated or to-be-collected assumptions/constraints. Treat those as analytics workflows when they cite metrics, confidence/uncertainty, guardrails, segments, or structured evidence, even when the first step is context collection; pair context with product-business-analysis and include build-report whenever product-business-analysis is selected unless the user explicitly waives report creation or selects another primary artifact.

Metric definition/source-of-truth disputes

When teams disagree about which metric definition, dashboard, extract, owner, or source of truth should control a decision or executive reply (for example revenue/ARR, activation, retention, funnel, or regional totals), route as analytics even if the immediate output is a short Slack/email recommendation. Prefer analyze-data-quality for comparability/backfill/grain/source conflicts and design-kpis for canonical definition/guardrail ownership; use both when the request asks which definition should govern.