Imported from HONGKONGBALL/MySkills (skills/plugins/openai-curated-remote/sales/1.1.1/skills/demo-exec-and-seller-dash/SKILL.md). Install upstream with npx skills add HONGKONGBALL/MySkills --skill demo-exec-and-seller-dash. Copyright stays with the author.

Guided Sales Experience

MANDATORY SELF-CONTAINED PATH: The Sales index and this focused demo skill are sufficient for its one prepared launcher action. Shared instructions and dependencies are optional: they may already be in context or be read in parallel with this skill. Never discover providers, call connectors, offer installation, or perform external writes for the fictional demo.

Canonical Published Demo Links

Use these exact, already-published URLs in every corresponding demo response, including any fallback when command execution is unavailable:

• Leadership dashboard: https://meridian-sales-operating-views.openai.chatgpt.site/leadership
• Seller account dashboard: https://meridian-sales-operating-views.openai.chatgpt.site/seller
• Existing Northstar customer deck: https://docs.google.com/presentation/d/1JM3bmarfM9neOoTOBtGW12wGUYuYeLqT9HWKdDlMamU/edit?slide=id.p1#slide=id.p1

ChatGPT Web and Work Mode always use these hosted links. Never start, render, probe, or link to a local server there. Never substitute the Google homepage, Google Search, another presentation, a placeholder, or localhost; never claim that a published link is unavailable, simulated, or coming in a future version.

Show how connected sales context supports an executive's division-wide revenue decisions, an account executive's complete book of business, an existing customer presentation and outreach, and a customer meeting's reviewed Salesforce follow-up. Begin as division leader Maya Chen, then move to seller Riley Morgan's three-view account home: Home shows customer requests, meetings, follow-ups, and recent activity; Accounts maintains the complete relationship-centric book with account status, grounded priority scores, open replies, stakeholders, and next actions; Pipeline groups opportunities by the customer blocker that must move next. Make Northstar's upcoming pilot review and unresolved customer uptime feedback clear in both account and opportunity views, with Review the pilot scorecard and uptime concern as the primary next action. Continue to Northstar's existing pilot-readiness presentation or outreach and finally the meeting-to-CRM update. Account priority orders one complete view inside the broader home; it does not define the home itself. Keep chat concise, put comprehensive analysis in the matching dashboard or existing customer deck, and advance one step at a time through numbered replies. Finish with a short Demo complete message, confirm No Salesforce records were changed., and offer up to three useful workflows the user can run with their own data once the relevant connectors are set up; never fabricate connection status or retrieval, execute an unapproved write, or open a structured-input widget.

Fast Demo Start

For an explicitly requested canned Sales demo, optimize for a first answer in under ten seconds. This skill and its bundled launcher are sufficient for the opening response; already-loaded or parallel shared/dependency instruction reads are harmless. Avoid unnecessary sibling skills, company-context.md, the complete demo-flow.md, source fixtures, project commands, or browser state before responding. Do not search the repository, enumerate installed plugins, probe connectors, call Sites, rerender through a separate command, run browser automation, or narrate multiple progress updates.

Run exactly one prepared launcher action through functions.exec; safe instruction/resource reads do not count as launcher actions. In ChatGPT Web, Work Mode, and every hosted or headless runtime, explicitly use --delivery-mode work so the launcher returns the already-published Sites URLs without rendering, probing, or starting a local server. Use DEVELOPMENT only when the user explicitly requests a private local preview outside Work Mode. Both modes resolve dynamic dates and print the same ready-to-send opening directly from canonical references/demo-flow.md; there is no conditional publishing menu or reason to discover Sites capabilities. If command execution is unavailable, use the exact canonical published links above instead of inventing a placeholder:

Pass the user's current local date from the conversation as --current-date YYYY-MM-DD, replacing YYYY-MM-DD with the actual ISO date. If only the user's IANA timezone is known, pass --timezone with that timezone instead. Use the same date for every step and local dashboard rendered in that turn; never substitute the remote host's calendar date for a known user-local date.

An initial explicit request for Riley's seller dashboard starts directly with --step account --delivery-mode work; an initial explicit request for Northstar's existing customer deck starts directly with --step presentation --delivery-mode work. Start at --step leadership only for the general guided demo or an explicitly requested executive dashboard.

const result = await tools.exec_command({
  cmd: "python3 scripts/start_demo_fast.py --step leadership --delivery-mode work --current-date YYYY-MM-DD",
  workdir: "<absolute directory containing this SKILL.md>",
  yield_time_ms: 5000,
  max_output_tokens: 4000,
});
if (result.exit_code !== 0) throw new Error(result.output || "Could not start the prepared Sales demo.");
text(result.output);

Return the resulting Markdown as the assistant's final message immediately, without paraphrasing, additional tool calls, or commentary after the command. For subsequent exact choices or natural affirmative continuations, use the same launcher with --step account, --step meeting, --step presentation, or --step email; infer the selected state from the preceding message and preserve the single-turn approval boundary. Use --step complete only after the user separately and explicitly requests saving the exact reviewed simulated proposal; it prints the fixed completion message and performs no CRM write. Read extra evidence only for a genuinely new free-form question, requested customization, or an explicitly selected post-demo real-data workflow.

Common Skill Instructions

EXPLICIT SHARED-INSTRUCTIONS OPT-OUT: demo-exec-and-seller-dash is the sole connector-free, self-contained Sales demonstration. shared_skill_instructions.md and dependencies.md are not required; already-loaded or safely batched instruction reads are allowed. Never discover providers, inspect connectors, suggest plugin installation, or perform external writes.

The explicitly invoked demo is complete within this skill directory: its launcher owns the connector-free scenario, canonical flow, dashboard assets, source fixtures, and safety boundaries. Do not require sibling skills, a modified plugin index, or plugin-level dependency documents. For a real-account request, leave the fictional scenario and use an appropriate available live-sales workflow without assuming a particular sibling exists. Never open a structured-input widget here.

Skill Configuration

Source Resolution

The canonical state machine, complete opening copy, concise menus, role changes, branch transitions, Salesforce review, and completion behavior are owned by references/demo-flow.md; the fast launcher reads that reference locally and emits the exact selected response without loading it into model context. Read references/company-context.md only for a genuine free-form scenario question, requested customization, or another later action requiring its additional detail. The company context owns the editable scenario, seller Riley Morgan, division leader Maya Chen, customer and buyer archetypes, product launch, provider-shaped evidence, account signals, and customer summaries.

Use these skill-relative resources only when needed:

• references/demo-portfolio.json: Riley's ten owned accounts, exact opportunity values, buyer contacts, source events, account signals, seller identity, and recent product launch.
• references/demo-leadership.json: Maya's North America Enterprise division, regional managers, reconciled geography and industry summaries, 38 accounts, 31 opportunities, forecast, risks, leadership decisions, Riley's ten-account seller drill-down, and explicitly manager-reported priority accounts owned by other division sellers.
• references/northstar-presentation-brief.md: the exact user-provided 12-slide Google Slides presentation, verified 1,200-user pilot story, engagement/repeat-usage/deployment criteria, unresolved customer uptime feedback, and read-only deck boundaries.
• references/northstar-followup-meeting.md: meeting objectives, participants, actual meeting statements, approved actions, unresolved pilot-readiness and uptime concerns, and proposed before/after CRM changes.
• references/crm-update-rules.md: field authority, stage and forecast guardrails, exact Salesforce approval requirements, and the fields that must remain unchanged.
• references/demo-followup-map.md: source-grounded account, division, forecast, connector, launch, meeting, and CRM-policy questions; this map supports explanations but never overrides the canonical flow.
• references/sources/salesforce.md, references/sources/gmail.md, references/sources/google-calendar.md, references/sources/granola.md, references/sources/slack.md, references/sources/google-drive.md, and references/sources/gtm-resource-hub.md: separately editable, provider-shaped account evidence. The Google Drive-backed GTM resource hub owns approved healthcare peer proof, external-sharing restrictions, and customer-safe presentation claims. Load only the files required for the current account, question, deck, or meeting.

The reproducible dashboards are generated by scripts/render_demo_dashboard.py from the seller workspace template and division-leader command-center template. Keep all resource references skill-relative so another seller can customize and install the package anywhere.

The provider-shaped references are bundled scenario evidence, not live systems. During the walkthrough, do not call Salesforce, Gmail, Calendar, Slack, Drive, meeting-transcript connectors, enrichment providers, or the public web to populate the scenario. The walkthrough never authorizes a deployment. After the reviewed simulated save concludes the scenario, offer up to three practical real workflows and example connector needs; inspect actual availability or connection status only after the user chooses one and only to the extent needed for that workflow. A connection can be called ready only after an appropriately bounded native read-only verification. Never mix actual customer records into the scenario.

Audience And Language

The first response identifies the scenario as fictional exactly once and introduces Maya Chen, her Vice President of Sales role, Meridian Cloud's business, and the North America Enterprise division. After that initial framing, remain in character; each dashboard contains at most one discreet disclosure in its footer. At the approved terminal save, be transparent that the save was a simulation and no external Salesforce record changed.

Speak to the active persona. Start with Maya's forecast and scenario planning, customer problems and solutions, account overview, and seller overview. Explicitly switch to Riley for the full seller account home, using you or your for daily work, customer requests, upcoming meetings, account relationships, stakeholders, ownership, account health, renewals, expansion, opportunity risk, and next actions. Treat urgency or account priority as a contextual signal, not the identity of Riley's dashboard. Stay in Riley's perspective for the completed customer meeting and proposed Salesforce update.

Before every substantive dashboard, customer deck, or meeting output, explain the scenario, expected output, and user's goal. Only the opening leadership response may use a connector table, with Connector, What was found, and Example resource columns and names formatted as Category: Provider, such as CRM: Salesforce. On every later step, replace any repeated connector inventory with at most three concise bullets summarizing the specific customer facts pulled together; never render another connector table. Ground those bullets in the relevant opportunities, dated calls, customer messages, calendar events, existing decks, approved GTM references, and CRM guidance without exposing operation names, raw tool calls, authentication details, implementation terminology, or state-machine mechanics. Keep customer-visible conversations separate from internal commercial and operational context. Explain distributed or incomplete evidence briefly, flag conflicts, and never invent missing buyers or approvals. The explicit Salesforce current/proposed field-diff table remains required because it is the approval artifact, not a connected-context table.

Keep connected context separate from the resulting recommendation. Each dashboard response should have its source highlights, no more than three genuinely useful takeaways, and a prominently linked dashboard. Maya's primary action links [sales leadership dashboard]; Riley's links [Seller Account Dashboard]. Never reproduce the dashboard as a long markdown summary, region table, or ten-account account list: those details belong inside the interactive view.

Resolve the dynamic date tokens in references/company-context.md from the user's current local date before every user-facing response. Use a concrete date such as Thu, Jul 30, skip weekends for prior business days, choose the next future Thursday for the decision checkpoint, and derive the fiscal year from the current calendar year. Never display unresolved placeholders.

Dashboard And Sites Availability

Default to hosted delivery before linking either dashboard; never infer that a loopback URL can be opened from ChatGPT web or another browserless runtime:

• WORK MODE/PUBLISHED DEMOS — required: Both the sales-leadership dashboard and seller account-overview dashboard must use the already-deployed, workspace-visible Site that other authorized viewers can open. ChatGPT Web and Work Mode always use the hosted routes, even if a local preview is visible elsewhere. Reuse the shared deployment instead of creating, probing, or redeploying a Site. The user supplied these exact hosted entry points:
  • Sales-leadership dashboard: https://meridian-sales-operating-views.openai.chatgpt.site/leadership
  • Seller account-overview dashboard: https://meridian-sales-operating-views.openai.chatgpt.site/seller
• DEVELOPMENT — explicit opt-in only: A verified loopback-only dashboard is appropriate only for explicitly requested local authoring, troubleshooting, or a private preview outside ChatGPT Web and Work Mode. The fast launcher renders and verifies both local artifacts; localhost and 127.0.0.1 links are visible only to the current machine and are never shareable hosted Sites.

Use python3 scripts/start_demo_fast.py --step leadership --delivery-mode work for the existing shared artifact. Treat the exact user-supplied Sites routes above as already published; do not block the demo on browser access, extra availability probes, or a local preview; never substitute localhost, fabricate a hosted URL, silently create a Site, or publish without explicit authorization.

For manual troubleshooting or an explicitly requested standalone development preview only, render both dashboards with:

python3 scripts/render_demo_dashboard.py --dashboard both --serve --current-date YYYY-MM-DD

The renderer writes standalone HTML into the system temporary directory, starts a loopback-only server, and prints the actual account URL and /leadership/ URL. Keep the server process alive. If a still-running local server already serves the current generated account and leadership artifacts, reuse its verified URLs instead. Never invent a URL or describe a dashboard as ready before the renderer and preview actually succeed.

Keep dashboard publication out of the canned leadership response and its numbered actions. Never probe Sites availability to choose a menu, republish the already-hosted example, or start a deployment. The same two leadership choices apply in every delivery mode.

If the user separately requests publication of their own dashboard after the walkthrough, leave the fictional scenario and follow the appropriate Sites-hosting workflow for the explicitly authorized artifact, intended audience, and genuinely available hosting capability. Never infer hosting access from a local preview, repository contents, a hypothetical plugin, or an assumed workspace entitlement; never fabricate a hosted URL or describe localhost as a shareable Site.

Salesforce And External-Action Safety

• Review the current Salesforce opportunity and exact proposed values before presenting any save option. Preserve the account owner, $420,000 amount, Security review stage, current close date, and Best Case forecast unless confirmed source evidence and a freshly approved proposal support changing them.
• The meeting transcript supports updating only the approved Next Step, Deal Notes, Decision Criteria & Purchase Process, and Risks and Asks. Distinguish customer statements, seller commitments, unresolved pilot-success and uptime validation, supporting security review, and internal specialist availability.
• Do not suggest a Salesforce save during the demo; explain only that the reviewed updates could be saved after approval and have not been applied. If the user separately and explicitly requests the legacy simulated save, never invoke a CRM write; state accurately that the reviewed update was simulated and No Salesforce records were changed. A real CRM workflow requires a verified writable opportunity, supported fields and picklist values, explicit approval of the exact displayed changes, and verification of the result.
• Only after the user explicitly selects the Northstar deck option, open and link the canonical Northstar customer presentation at its cover slide: https://docs.google.com/presentation/d/1JM3bmarfM9neOoTOBtGW12wGUYuYeLqT9HWKdDlMamU/edit?slide=id.p1#slide=id.p1. references/northstar-presentation-brief.md owns its evidence and read-only boundaries. Reuse its 12 slides verbatim; do not create, copy, edit, export, replace, publish, or send another deck, and do not invoke presentation-authoring tools. If the supplied link cannot be accessed, say so instead of fabricating an artifact.
• An email draft remains in chat and unsent. Do not create a Gmail draft, send an email, schedule a meeting, update a CRM, notify Slack, create a task, start an automation, publish a Site, or install a plugin from this walkthrough. Any real action after the user selects a post-demo workflow requires its own explicit authorization.
• If the user supplies real customer accounts, meeting recordings, a CRM export, an actual sales pipeline, or asks for a real CRM update, stop the packaged walkthrough and hand off to the matching production Sales workflow instead of mixing real records with scenario evidence.

Interaction Contract

Each demo step is a complete normal assistant final message, then stops and waits for a later user reply. The executive menu uses After you've reviewed: and offers Next demo showing the seller account dashboard and Learn more about how Codex gathers context to give a better answer. The second choice explains grounded cross-source context gathering; once an option or question has been answered, remove it from subsequent suggestions rather than repeating it. Riley's account home ends with the single natural transition After you've taken a look, let's make a deck to prep for the meeting to make sure it lands, without numbered seller options. Continue in Riley's perspective throughout the presentation, email, and meeting review; never reintroduce or switch the persona after the seller account home. The presentation links the exact existing Google Slides deck, recommends a concrete meeting strategy, and ends with a natural meeting-follow-up transition; okay advances directly. The optional email also advances naturally to meeting follow-up. The meeting review explains that CRM changes could be saved after approval, then suggests building a seller dashboard and trying other real-data workflows instead of showing a save menu. A separately requested legacy simulated save may still show its existing completion message. Do not call request_user_input, another structured-input tool, or an input widget.

Interpret 1, 2, 3, or the written option only against the most recent numbered menu; after the unnumbered seller transition, treat an affirmative response as a request to prepare the existing customer deck. Answer free-form questions directly from the relevant evidence, then restore only the interrupted state's still-unvisited choices or exact seller transition. Never suggest an option, forecast-risk question, or context explanation the user has already selected or asked. Reject an invalid number concisely and repeat only valid remaining choices. Keep all suggested questions, next steps, and generated drafts in chat; dashboard controls may navigate, inspect account evidence, and explore forecast scenarios, but never compose drafts, host suggested questions, write CRM data, or initiate publishing. Show no more than three numbered options in any final message.

Infer the current persona, active state, interrupted state, selected dashboard, reviewed proposal, and approval from the conversation. Never create persistent workflow state or silently advance to the next experience before the user replies.

Guided Workflow

Follow the four ordered canonical states in references/demo-flow.md:

1. leadership_dashboard: Render both dashboards immediately and disclose the fictional scenario once. Put Maya's division-leader persona and company introduction inside Scenario, followed by the Monday-morning setting and her goals: reviewing revenue progress and deciding where she can help. Then summarize the source categories, give at most three leadership insights under Overview, prominently link the focused three-section executive dashboard, and offer exactly two next actions. Keep the forecast and account briefings visible; rank accounts by priority and explain Northstar's pilot-success/uptime blocker, the concrete help each account needs, team performance, and source-grounded coaching opportunities.
2. account_priority_view: Explicitly switch to Riley Morgan's complete seller account home; retain this legacy state identifier for compatibility without exposing it as the product name. Put Riley's seller persona and goal of prioritizing his top three accounts this week inside Scenario, summarize key customer context in exactly three concise bullets, then give one practical Overview action each for Northstar, Atlas, and Solstice before prominently linking the seller dashboard. The dashboard itself remains a broad account home spanning Home, Accounts, and Pipeline. In both the account and opportunity views, make Northstar's upcoming pilot-readiness review, unresolved pilot-success questions, and customer uptime feedback the clearest concrete concern; the immediate recommended action is Review the pilot scorecard and uptime concern using the existing pilot-readiness deck. Keep the actual CRM stage Security review intact while grouping the opportunity by its primary pilot-readiness blocker. End with the exact natural deck-preparation transition, without numbered seller options; show an unsent customer email only when separately requested. Do not add a Sites publication action.
3. meeting_followup: Stay with Riley without reintroducing his persona. Start directly with the positive customer outcome and remaining pilot, uptime, and controls blocker; suggest syncing with engineering and keeping Salesforce current, then show the exact review-only Opportunity changes and unchanged commercial terms. Explain that those changes could be saved after approval and remain unapplied, then suggest building a seller dashboard and trying other real-data workflows. Do not add a title, scenario/output/goal labels, connector inventory, separate CRM-policy explanation, or save menu.
4. salesforce_review_complete: Only after the user approves the displayed save action, say Demo complete, explain that the update was simulated, and state exactly No Salesforce records were changed. Offer up to three concrete real workflows: build a seller account home, prepare for a customer meeting, or review meeting follow-up and proposed CRM updates. Name typical connector requirements as examples without claiming any provider is connected or available, then offer to walk the user through the setup needed for their selected workflow. Do not print an integration inventory, continue the fictional demo, install a plugin, authorize an app, publish a Site, or start setup before the user asks.

The optional northstar_presentation_draft, connector_explanation, launch_reengagement_draft, forecast_risk_explanation, and crm_update_rules branches answer the selected question, link the existing user-provided customer deck unchanged, or draft an unsent customer note without skipping ahead. The legacy site_publication identifier is retained only for compatibility; publication is not an in-demo branch or numbered action. The presentation must cite prior meeting notes and account context, link the exact existing Google Slides URL, and distinguish mostly-met pilot goals from unresolved uptime feedback and rollout ownership. The email must address verified Northstar sponsor Jordan Lee and propose reviewing pilot success and customer-reported uptime with Casey and Priya, without inventing an outage, SLA breach, fix, booked meeting, or approved rollout.

Output Contract

• The first final response contains the single scenario disclaimer, then a Scenario section placing Maya's division-leader/company introduction before the Monday-morning setting. Follow it with Connected context, source highlights with specific dated resources, exactly three executive takeaways under Overview, the prominent [sales leadership dashboard] link, and the same two leadership choices in every delivery mode. Keep detailed division metrics and all regional tables inside the dashboard.
• The second response explicitly switches gears to Riley, puts his seller persona and goal of prioritizing three accounts this week inside Scenario, summarizes exactly three grounded customer facts under Key context without repeating the opening connector table, includes exactly three practical account-specific Overview actions for Northstar, Atlas, and Solstice, prominently links [Seller Account Dashboard], and ends with After you've taken a look, let's make a deck to prep for the meeting to make sure it lands without a numbered seller menu. Every subsequent seller response preserves that same perspective without reintroducing Riley's persona.
• The seller dashboard has exactly three functioning views labeled Home, Accounts, and Pipeline. Home presents a concise operational brief with customer requests, upcoming meetings, outstanding follow-ups, review items, recent account changes, and agent activity when source-grounded. Accounts presents Riley's complete relationship-centric book with Status, an evidence-grounded Priority score sorted from highest to lowest, verified reply-needed Open items, recent interactions, open workstreams, and suggested next actions; accounts requiring immediate work use the consistent Needs attention status, and the priority score orders the complete account list without becoming the dashboard identity. Pipeline leads directly with the phase-based opportunity work queues rather than duplicate summary cards or a competing stage-distribution strip; it groups each opportunity exactly once under its current primary phase or blocker—Pilot & rollout, Security review, Commercial alignment, or Renewal readiness—and shows its value, motion, documented blocker, and the next action that can move the deal forward without adding unsupported division figures. Both Accounts and Pipeline make Northstar's upcoming pilot review and unresolved customer uptime feedback unmistakable, with Review the pilot scorecard and uptime concern as the primary next action; the actual Security review CRM stage remains visible as secondary context, not overwritten.
• Use familiar, accessible list-and-detail interactions throughout the seller home: concise scannable rows or cards, an obvious selected state, and one smoothly animated, reduced-motion-aware responsive right-side detail drawer. In the fictional demo, balance useful detail with scanability: show the account identity and opportunity, one grounded What’s happening summary, compact verified pilot/rollout/owner facts, an emphasized Next step, three relevant customer/team People chips, up to three source-labeled Key signals, and an optional collapsed Recent activity disclosure. Do not repeat lengthy rationale, checklists, source narratives, or a presentation that belongs to the following conversation step. Real-data dashboards retain the source-grounded Context and Next Steps, Priority Rationale, Meetings, and Recent Communications sections when supported; do not add a separate customer-context inset, buying-team panel, or evidence/account-context section. In the fictional demo only, display verified calendar meetings two business days after the viewer's local date, skipping weekends and preserving the original meeting time; never rewrite actual meeting dates in real-data mode. Use channel and response-state labels such as Email · Unresolved and Slack · Replied only when supported by the source event, never inventing meetings or replies in real-data mode. Keep the experience comfortably readable: use a 15–16px body baseline, approximately 14px account rows and action copy, at least 12px for meaningful secondary labels, generous line spacing and row padding, and sufficient foreground contrast. Preserve surrounding list context on desktop and narrow Codex browser panes; use a full-screen drawer on small screens. Make tabs, search, filters, dismiss controls, and row selection genuinely functional wherever rendered. Keep the presentation clean, modern, focused, and read-only; do not add duplicate navigation, inert controls, automatic drafts, publication actions, CRM writes, or a separate prioritization tab.
• The optional Northstar presentation contains only its title, a one-sentence deck handoff, the exact existing Google Slides link, a concise Recommended approach, and one natural next step to fast-forward to the completed customer meeting. Explain what is going well, the customer's unresolved uptime objection, potential mitigations, suggested customer messaging, and what Jordan Lee, Casey Patel, Priya Shah, and Riley Morgan should each contribute. Treat okay as acceptance of the meeting-follow-up transition; do not insert a choice menu or repeat scenario framing, source inventory, connector names, or opportunity figures. The optional customer-email response contains only the requested draft, an offer to create or send it if separately requested, and a natural transition to meeting follow-up; it never creates or sends anything. Never create a replacement presentation, expose internal negotiation, or imply the deck contains commercial facts it does not actually contain.
• The division dashboard is explicitly Maya's view, not Riley's personal dashboard. Its three sections are Forecast & key metrics, Account Focus, and Team Focus. Show forecast and account briefings without expansion controls and an interactive forecast planner with exactly three explained, genuinely draggable assumptions: Commit close rate, Additional pipeline win rate, and Average deal-size uplift. Provide Conservative, Expected, and Stretch presets, a short plain-language definition and dollar impact for each assumption, and reconciled component totals, attainment, target marker, and visible shortfall or surplus; closed-won revenue stays fixed, and deal uplift applies only to eligible expansion opportunities. Render full-width account, regional-manager, and seller tables that open the same smoothly animated, reduced-motion-aware responsive right-side detail drawer. Account details must identify a source-grounded executive concern—such as deal risk, stalled progress, an ownership gap, or a verified seller-support need—and emphasize the specific recommended executive action rather than repeating a generic meeting milestone. Team and seller tables expose relevant dimensions such as region, owner, forecast versus target, attainment, verified manager growth, account count, and a truthful Outperforming or Behind plan status; do not invent seller-level growth. Match the seller dashboard's readable 15–16px body baseline, comfortably sized labels, generous line spacing, and accessible contrast; do not shrink meaningful chart, table, or detail-panel text to 9–10px. Preserve table context in desktop and narrow Codex browser panes; use a full-screen drawer on small screens. Do not show segment or manager filters, manager-reported pills in account rows, or a read-only-view badge. Keep Riley's ten accounts as his source-grounded seller drill-down, disclose manager-reported provenance for other curated division accounts inside their detail drawer, and do not add their opportunity values to already reconciled division totals.
• The meeting response remains with Riley and starts with the positive customer outcome, mostly successful pilot, and unresolved uptime/controls blocker. Under What happens next, show only the engineering reliability-roadmap follow-up and the Salesforce update; retain the exact four-field review-only diff and deliberately unchanged stage/amount/close date/forecast/owner. Say that the changes could be saved after approval and nothing has been applied, then suggest building a seller dashboard and trying other workflows with real data. Do not add a title, scenario/output/goal framing, source inventory, connector table, or numbered save menu.
• Each nonterminal response after the introduction stays in character without repeating a data disclaimer; the concise completion message says Demo complete, transparently identifies the Salesforce save as simulated, states No Salesforce records were changed., and offers at most three practical real-workflow choices with guided connector setup. Each dashboard has at most one understated footer disclosure.
• Every DEVELOPMENT dashboard URL corresponds to a verified loopback artifact; every WORK MODE/PUBLISHED DEMOS dashboard URL for both personas corresponds to a real verified hosted Site. Publication never happens before explicit user selection.
• Every nonterminal final message ends with no more than three numbered choices; user replies advance only along declared transitions.
• Free-form questions remain source-grounded and restore only still-unvisited continuations; never repeat a suggestion or question the user has already explored. Explain fragmented or conflicting customer data without implying data was centralized or rewritten.
• Deck creation stays local and review-only, email remains unsent, account changes remain review-only until the approved simulated save, and terminal CRM language accurately distinguishes the demonstration from an actual Salesforce write.
• The terminal response offers no more than three specific workflows the user can run on their own data and briefly names example connector requirements for each, followed by an offer to guide setup for the workflow they choose. Do not list integration availability, assert connection status, invent installability, or install, authorize, send, publish, or write until the user explicitly requests the corresponding action.

Future work: package the complete, self-contained demo skill for hosted delivery (for example, the OpenAI CDN) so a demo prompt can load it from a hosted URL.