Update to Sales

{
  "name": "sales-leadership-dashboard",
  "description": "Build, update, or customize a real executive, revenue, sales-leadership, division, or team operating dashboard, or a clearly labeled placeholder or representative view, spanning forecast, prioritized accounts, and seller performance. Use for an executive dashboard or ongoing leadership operating canvas, not an ordinary forecast review, forecast-call analysis, or fictional demo.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 290
    }
  ],
  "skill_md_contents": "---\nname: sales-leadership-dashboard\ndescription: \"Build, update, or customize a real executive, revenue, sales-leadership, division, or team operating dashboard, or a clearly labeled placeholder or representative view, spanning forecast, prioritized accounts, and seller performance. Use for an executive dashboard or ongoing leadership operating canvas, not an ordinary forecast review, forecast-call analysis, or fictional demo.\"\n---\n\n# Sales Leadership Dashboard\n\nCreate an ongoing, customizable operating canvas for a verified sales leader's actual division, team, period, accounts, and sellers, or an explicitly requested, clearly labeled empty placeholder.\n\nOrdinary forecast analysis remains with `review-forecast`; fictional demonstrations remain with the self-contained demo skill.\n\n## Common Skill Instructions\n\nMANDATORY: If the Sales index has not genuinely been read in this conversation, read [the Sales index](../index/SKILL.md), then reread this focused skill in full before continuing.\n\nMANDATORY: Read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md) and the [shared dashboard lifecycle](../../references/dashboard-lifecycle.md).\n\n**First clarification is blocking:** Read this skill and both linked Sales instruction files before answering or asking anything. Resolve a confirmed role mismatch accurately first. Ask the existing-dashboard question only after exactly one matching unpublished dashboard is verified or authoritatively identified; trust the user's authoritative identification of their matching leadership project without inspecting it, then ask only **Use existing (Recommended)**, **Modify existing**, or **Create new**. If no matching dashboard exists, skip this question and proceed directly to the dashboard goal; account names or a leadership-dashboard request alone never establish an existing project. Include no orientation, metrics, publishing, or automation before an applicable existing-dashboard choice. Every `request_user_input` call must satisfy `questions.length === 1`; await its answer before the next role, existing-dashboard, goal, or style question. Separate calls may occur within one assistant turn. Honor an explicit chat-only preference without using the tool.\n\n**Honor decisions the user already made.** An explicitly requested new local dashboard, selected goal, selected design style, declined generated imagery, or ban on publishing/sharing is already an answer; never ask the user to confirm or select it again. When a fully specified build identifies no existing-dashboard decision, proceed directly to verified CRM retrieval and creation. If `request_user_input` is unavailable and the explicit build supplies sufficient scope, continue with its grounded instructions and use **Forecast and revenue growth** / **Codex Default** only for genuinely unspecified presentation defaults; never terminate with an unanswered picker or fabricate missing CRM evidence.\n\n## Key Dependency Categories\n\n- [Blocking] ~~CRM only for populated or representative dashboards: authorized team ownership, accounts, opportunities, forecast, and seller truth; an authoritative user-supplied scoped export also satisfies it. Exception: a clearly labeled empty placeholder never requires CRM.\n- ~~Knowledge & Files for leadership targets, forecast conventions, scorecards, and account plans.\n- ~~Internal Messaging for verified ownership, seller support, approvals, and customer blockers.\n- ~~Meeting Transcripts and ~~Email for grounded customer decisions, risks, and next steps.\n- ~~Calendar for actual customer meetings and decision timing when material.\n\nSources beyond CRM are optional. Never widen the user's authorized scope, invent an account universe, or let supporting evidence override CRM truth.\n\n## Build The Operating Canvas\n\n**Dashboard goal:** Use an explicit goal already supplied by the user without asking again. Otherwise, after resolving any confirmed role mismatch and matching unpublished-local-dashboard choice, ask exactly: **What do you want front and center in your dashboard? You can always customize this later.** Offer exactly three substantive leadership options: **Forecast and revenue growth (Recommended)**; **Strategic account focus**; **Team performance and coaching**. Safely personalize focused wording/descriptions using relevant existing memories and context while preserving these defaults when context is thin, the recommended first option, and every grounded dashboard capability.\n\nNever add `Other` explicitly. Unknown requester role is not a mismatch. Attribute any confirmed mismatch to Salesforce only when Salesforce was actually consulted; otherwise name the user-provided evidence accurately.\n\n**Design style:** Use an explicit style already supplied by the user without asking again. Otherwise, after receiving the goal answer, ask exactly: **What look and feel would you like for your dashboard?** Offer exactly three distinct visual choices: **Codex Default (Recommended)** first with the exact description **Clean surfaces, crisp type, quiet contrast.**, then two contextual alternatives from the shared lifecycle's full twelve-direction catalog. Personalize the alternative selection using relevant existing memories and context; never use a fixed pair. Keep descriptions to at most eight words and preserve the selected preset's internal character and density throughout the storyboard, image-reference prompt, and accessible implementation. A Codex pet is optional only when the user supplies an authorized genuine asset that fits the request; never generate, imitate, trace, search for, or assume one. Follow the shared lifecycle's evidence-feasible design-reference workflow unless the user explicitly declined generated imagery: then skip image generation entirely, ask no image-permission question, and continue the dashboard without it.\n\n1. If already-available evidence confirms the current user is not a sales manager, sales leader, or executive and no authorized target was supplied, ask: **How should I handle the fact that Salesforce does not identify you as a sales manager or executive?** Name another verified source accurately when Salesforce was not consulted. Offer a clearly labeled empty **placeholder**, an evidence-grounded **representative** dashboard, or an explicitly identified **target user** under the shared lifecycle; an unknown role is not a mismatch. For real views, resolve the leader, authorized team/division, reporting period, account universe, CRM freshness, and known forecast conventions from CRM or a sufficiently authoritative supplied export. For an explicitly named seller and fiscal quarter, first verify the CRM owner, then retrieve actual open `Opportunity` records constrained to that owner, `FISCAL_YEAR(CloseDate)`, and `FISCAL_QUARTER(CloseDate)`; an owner record, fiscal-period row, field-history record, or query text alone never proves that a scoped opportunity exists. When using Codex CRM tools, invoke the official `tools.mcp__codex_apps__salesforce_mcp_soql_query` provider directly with the actual bounded SOQL; never select it through `ALL_TOOLS.find`, dynamic `tools[name]` dispatch, or unrelated provider aliases.\n2. Generate the authoritative dashboard with the production renderer and its polished `../demo-exec-and-seller-dash/assets/sales-leadership-dashboard.template.html` scaffold; personalize the selected goal, style, and design while preserving its exact `__LEADERSHIP_DATA_JSON__` placeholder with a verified real-data or explicitly marked empty-placeholder payload.\n3. Render with `../../scripts/render_real_dashboard.py --persona leadership --mode <real|placeholder|representative> --payload <verified-payload.json> --project-dir <stable-user-owned-project>`. If the user explicitly requests `index.html` directly in the current private working directory, use `--project-dir \"$PWD\"`, verify the complete self-contained `$PWD/index.html` after creation, and return a clickable local link to that exact file; a nested project, proposed plan, or chat-only summary does not satisfy the requested deliverable. Once the production renderer succeeds, its generated `$PWD/index.html` is authoritative: never directly `apply_patch`, hand-write, delete, or replace that file. Refine only the verified payload and rerun the exact production renderer; never append a competing app/root, overlay its controls, or hide the generated `.topbar`, `#dashboard-navigation`, `main.shell`, account rows, or drawer. Keep grounded `forecast-nav` and `accounts-nav` visible and activating their real sections; show `team-nav` only when genuine team evidence supports it. When verified accounts exist, keep `#accountFocusList [data-account-id]`, `#account-focus-search`, `#account-focus-search-clear`, `#account-drawer`, `#accountFocusDetail`, and `#account-drawer-close` operable and connected to real sourced rows. Verify account search genuinely narrows those rows, Clear and Escape restore them, nonexistent queries show none, and an actual row opens and closes its drawer. Exercise these real interactions after every refinement and repair failures before returning; ad-hoc element counts do not prove that controls work. Never use the fictional-only demo renderer or a disposable temporary dashboard project.\n4. Customize the interactive **Forecast & key metrics**, **Account Focus**, and **Team Focus** experiences, additional sections, data, filters, layouts, and flows around the selected goal, chosen visual direction, feasible design reference, and subsequent user requests; every visible component must be evidence-backed, actionable, and genuinely functional.\n5. Ground **Forecast & key metrics** in actual period amounts, component totals, forecast categories, and sourced targets; show scenarios or interactive assumptions only when their inputs and math are supported.\n6. Ground **Account Focus** in verified division accounts, owner, opportunity state, priority rationale, decision evidence, and specific executive actions. Reconcile totals without double-counting curated accounts.\n7. Ground **Team Focus** in actual managers, sellers, account counts, forecasts, targets, and attributable coaching priorities.\n\n## Evidence And Safety\n\n- Derive attainment only when its sourced numerator and denominator exist; show weekly forecast or manager movement only from actual comparable evidence. When two verified forecast snapshots share the same basis and the latest equals the current forecast, calculate movement as latest minus previous on that same basis; never present an unweighted opportunity-amount change as probability-weighted forecast movement. Keep every forecast KPI, weekly panel, and implication consistent; omit unsupported or conflicting movement while preserving correctly labeled account-level changes.\n- Omit unsupported quota, target, weekly-movement, confidence, attainment, scenario, manager-growth, seller-performance, or account-priority widgets and empty sections; never infer priority/rank from account position, and preserve verified zero values without unavailable, evidence-limit, or integrity-warning panels.\n- Before returning a forecast-growth or seller-rollup dashboard, compare every requested evidence-gap category with actual sources. Include one concise final delivery-note sentence that explicitly names each genuinely unavailable item, including **Seller growth unavailable: no verified comparable seller-level history**, prior snapshots or movement history, targets, team coverage, and scenario assumptions when absent; never call a verified value unavailable. Keep unsupported figures and warning panels out of the dashboard itself. A precise delivery-note disclosure is required even when the polished artifact has no warning chrome.\n- Never invent forecast targets, weekly movement, seller growth, sources, stakeholders, meetings, customer replies, scenarios, or ownership.\n- Mention actual source provenance only when useful; never substitute chat metric tables, inferred priorities, missing-data warnings, or evidence-limit/integrity commentary for the polished dashboard.\n- Include source labels only for sources actually consulted; real `sourceCoverage` entries must have `verified: true`.\n- Keep CRM access and the dashboard read-only; hosting changes, access changes, external sharing, CRM writes, outreach, and automations retain their approval and security boundaries.\n\n## Preserve The User's Dashboard\n\n- Identify the correct private dashboard through its current linked Site, its existing `.openai/hosting.json` project ID, or exactly one verified owner/persona/scope match.\n- Never select the fictional Meridian demo, another user's project, unrelated content, an incomplete identity, or an ambiguous match; ask the user to choose when reliable matches conflict.\n- Reuse a matching Site's URL, project identity, existing source, and user customizations automatically. For one authoritatively identified matching unpublished local project, ask exactly **Use existing (Recommended)**, **Modify existing**, **Create new** before inspecting it; create a duplicate only on explicit **Create new**.\n- Follow `sites-building` and `sites-hosting` when operating on an existing hosted project or after hosting is authorized.\n- If no correct private Site exists, refresh the stable user-owned local dashboard, return the actual local result, and offer private hosting.\n- Return the current dashboard with exactly one next step from the shared lifecycle.\n- **The user's local-first preference overrides the Sites skills' normal auto-publish default:** never create or publish a new Site until the user explicitly agrees.\n"
}