Sales

View saved version →

---
name: analyze-account-signals
description: Use when the user wants to inspect one named account's current status or authoritative CRM company record, understand what changed with one account, or explicitly requests a bounded signal-monitoring digest for an owner portfolio or watchlist. Produce an evidence-backed account brief or bounded watchlist summary; owned-account prioritization, ranked worklists, and durable seller dashboards belong to the seller-account-dashboard skill.
---

# Analyze Account Signals


## Context-Gathering Intake

Whenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance.

Turn fresh account evidence into a concise view of what changed, why it matters, and what to do next. This skill owns a read-only account brief or bounded watchlist summary; it does not create tasks, post digests, store monitoring state, or write CRM updates.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

These categories are particularly important for this workflow; use other sources only when they materially improve the signal story.

- [Blocking] ~~CRM for authoritative account identity, owner, opportunity, stage, amount, activity, customer-health, and account-status truth. It blocks the default account-signal readout unless sufficiently complete account truth is already grounded in context.
- ~~Meeting Transcripts for recent customer language, decisions, commitments, objections, follow-ups, and stakeholder movement
- ~~Email for customer-facing progression, unanswered asks, tone shifts, attachments, and promised next steps
- ~~Internal Messaging for internal coordination, blockers, stakeholder alignment, and escalation signals
- ~~Knowledge & Files for account plans, notes, briefs, implementation docs, and prior account context
- ~~Calendar for recent or upcoming customer sessions, commitments, and scope reduction for large portfolios

Use ~~CRM as the default account anchor. Use sufficient user-provided/exported account truth only as a fallback when CRM cannot be used. When the user requests the smallest possible company-record export, ask only for account identity and the specific status or change fields needed for their question; do not add contacts, emails, domains, opportunity details, or full account history unless requested. Communications, files, and calendar evidence explain recency and movement; they do not override CRM-owned account or opportunity fields.

## Reference Loading

`SKILL.md` owns the normal mode split, bounded retrieval, and output shape. Load references only when their extra detail changes the decision:

- Use [references/request-schema.yaml](references/request-schema.yaml) when structured input, legacy aliases, selector precedence, or machine-readable output shape matters.
- Use [references/signal-taxonomy.md](references/signal-taxonomy.md) when signal classification, confidence, recency, ranking, delta status, or display labels are ambiguous.

## Workflow Guidance

### 1. Choose the mode and scope

- If the mode isn't clear, ask the user via [User Input](../../shared_skill_instructions.md#user-input). For a bare invocation such as “Analyze account signals for me,” do not assume an Adhoc Account Brief or Monitor Summary; offer:
  - `Adhoc Account Brief for one account`
  - `Monitor Summary for accounts I own in CRM`
  - `Monitor Summary for a watchlist, owner, or territory`
- Use `Adhoc Account Brief` for one named account or “what changed with [account]?” requests. If the user selected Adhoc but did not supply an account, domain, or CRM id, search, rank, and offer up to three concrete account candidates via [User Input](../../shared_skill_instructions.md#user-input). Do not retrieve deeper evidence or draft the brief until the user selects one.
- Use `Monitor Summary` f

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: build-business-case
description: Own customer-led business cases, ROI or value analyses and models, pricing or investment rationales, customer-ready value stories, and buyer-ready commercial decision decks, including requests to turn customer ROI analysis into a decision deck. Review commercial proposals and build 8-12 slide proposal or value-case decks tied to a customer, workflow, initiative, or buying decision before handing visual authoring to the presentation partner.
---

# Build Business Case

Turn uneven account evidence into a customer-led, decision-useful value case. This skill owns the business-case logic and drafts, including the content of requested value-case presentations; delegate visual design and artifact creation to the appropriate authoring skill.

Start with the customer, not the product. Follow this chain on every run:

`customer context -> account-native anchor -> workflow -> use case -> value drivers -> metrics -> quantified impact -> narrative -> public research when useful`

If the evidence cannot support credible math, produce a clearly labeled structural case and the smallest validation plan needed to make it finance-ready.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

Use only lanes that materially improve the case.

- [Blocking] ~~CRM for authoritative account, opportunity, owner, stage, amount, close timing, contacts, and commercial context. It blocks customer/account-specific cases unless authoritative account and commercial context is already grounded; generic scenario cases can proceed without it.
- ~~Meeting Transcripts for discovery evidence, stakeholder language, workflow pain, objections, quantified claims, decisions, and validation gaps
- ~~Knowledge & Files for account plans, source packs, discovery notes, prior value cases, proof points, and account-native metrics
- ~~Sales Intelligence only when company, fit, stakeholder, or market context closes a specific evidence gap

Use public research only when it sharpens strategic priorities, executive wording, operating pressure, or “why now.” Prefer company-controlled, investor, regulatory, and other primary sources. Never let public or enrichment context substitute for customer-confirmed pain, workflow metrics, decision process, or CRM-owned truth.

## Reference Loading

`SKILL.md` owns the normal customer-led flow, evidence order, guardrails, and default package. Load references only when their extra detail matters:

- Use [references/input-and-output.md](references/input-and-output.md) when inputs are uneven, the user names an output mode, or the full required-content contract matters.
- Use [references/workflow.md](references/workflow.md) when a complex case needs the expanded customer-to-value sequence and examples.
- Use [references/value-model-and-evidence.md](references/value-model-and-evidence.md) when quantification, confidence labeling, evidence conflict, or value-bucket logic needs more detail.
- Use [references/output-and-presentation.md](references/output-and-presentation.md) only for a formatted artifact, exact presentation/output requirements, or behavior tests.

## Workflow Guidance

### 1. Resolve the customer and decision anchor

- Require a customer/account/scenario and a workflow, initiative, pain, metric goal, or decision context. Proceed from pasted notes, links, exports, or a clearly anchored thread when sufficient.
- A clearly identified team and workflow are sufficient for a generic scenario: deliver a structural case with value hypotheses, symbolic formulas, missing inputs, and a short measurement plan before asking for baselines or buyer details.
- If an inferred required anchor is ambiguous, make a bounded pass using at most three source reads, offer up to three concrete candidates, and ask the user to choose before broad enrichment.
- Treat company-lik

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: build-competitive-brief
description: "Use when the user wants a competitor or vendor comparison, market-landscape analysis, battlecard, objection package, positioning brief, or account-specific competitive view. Produce an evidence-backed comparison, guidance, and brief, using supplied materials, connected research, and public evidence when appropriate."
---

# Build Competitive Brief

Create a seller-ready competitive brief that separates verified facts from field signal and inference. Default to a self-contained HTML artifact plus a concise chat readout; use chat or Markdown only when the user explicitly asks for it. This skill owns research, synthesis, and the brief artifact, not external posting or CRM writes.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

Use the categories that materially apply to the request; do not broaden a search merely because a source is available.

- ~~CRM for account, opportunity, contact, ownership, known competitor, and active-deal truth
- ~~Knowledge & Files for battlecards, competitive docs, account plans, product positioning, proof points, and prior briefs
- ~~Internal Messaging for recent field signals, account-team observations, objection examples, and source-of-truth routing when internal context matters
- ~~Meeting Transcripts for prior objections, competitor mentions, buyer language, decisions, and commitments
- ~~Sales Intelligence only when it sharpens competitor discovery, company context, or a concrete evidence gap

Use public research for current public competitor facts. Prefer official product, pricing, launch, customer-story, investor, and regulatory sources; use secondary coverage only when primary sources are insufficient.

## Reference Loading

`SKILL.md` owns the normal research flow, HTML-by-default behavior, and evidence guardrails. Load references only when their extra detail matters:

- Use [references/request-schema.yaml](references/request-schema.yaml) for structured input, mode normalization, or matrix bounds.
- Use [references/source-priority.md](references/source-priority.md) when source conflict, authority order, or public-proof downgrade behavior is ambiguous.
- Use [references/output-contract.md](references/output-contract.md) for exact section order, compressed brief variants, or machine-readable compatibility.

## Terms

- **Battlecard:** a compact seller guide for how to position against a competitor, including where they win, where they are weaker, and what to say.
- **Defensive prep:** preparation for a competitor that may be relevant even when there is not enough evidence to say the competitor is active in the live deal.

## Workflow Guidance

### 1. Resolve the comparison anchor

- Require one useful anchor: named competitor(s), a named account or deal with competitor context, or a clear product, workflow, segment, or market category to compare.
- Preserve the user's exact seller, competitor, account, and objection wording. Infer the seller from the prompt or provided material only when credible; otherwise ask one targeted question.
- When the user gives a clear product, workflow, segment, or market category but no competitor names, discover likely competitors from seller context, buyer context, product scope, maintained competitive material, and public evidence. Keep the discovered set focused and label uncertainty.
- User confirmation is required for any required anchor inferred from sources rather than provided by the user.
- If the anchor is ambiguous, do a bounded candidate pass before asking: at most three source reads, only enough to offer up to three concrete candidates with one-line rationale.
- When a company-like name could be a competitor or customer, use a bounded ~~CRM check when available. If it resolves to a customer and the user did not clearly name it as a competitor, treat it as

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: demo-exec-and-seller-dash
description: "Use only when the user explicitly requests a fictional, connector-free Sales demo or walkthrough of executive forecast, seller account home, Northstar meeting prep and customer deck, and reviewed Salesforce follow-up. Never select it for ordinary real seller, account, pipeline, forecast, or meeting requests; this self-contained demo explicitly opts out of shared instructions and dependencies as requirements, but they may already be loaded or read in parallel. Start the hosted demo without discovering providers or offering installations."
---

# 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.

Ru

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 33 — file references are metadata, not package contents.

View saved version →

---
name: enrich-company-and-contact-data
description: "Own company, contact, lead, and prospect discovery or enrichment, including who to reach out to at a prospective customer when the person or role must first be identified. Cover firmographic or technographic completion, named-company profiling, entity resolution, ICP matching, prospect lists, segmentation, sales signals, market scans, and enrichment-backed comparisons. Exclude meeting preparation, drafting outreach to an already identified recipient, and prioritizing an established account book."
---

# Enrich Company And Contact Data


## Context-Gathering Intake

Whenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance.

Prepare a sales person with a trusted, decision-ready view of companies or contacts: what is known, what is a strong match, what is still uncertain, and what action the data supports. This skill owns evidence resolution, ICP-fit and coverage comparisons, and source-grounded signal analysis; it does not own rep-work priority, outreach execution, or CRM writes.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Enrichment Ranking

Use this priority order when the request is broad or the working set is ambiguous.

1. Explicit user-provided rows, domains, contacts, companies, ICP criteria, requested fields, or stated ranking rule
2. The named CRM account set, territory, target list, or documented ICP that the user points to
3. Entities that satisfy every hard filter, such as geography, industry, company size, technology, role, or seniority
4. Entities with high-confidence identity resolution and enough comparable evidence to support the requested output
5. Entities with a clear fit implication, reachable buying-team path, or source-grounded external signal
6. Near matches and unresolved entities, clearly separated from qualified results

Do not silently broaden a supplied list into discovery, merge ambiguous entities, or rank by a criterion the user cannot inspect.

If the user asks to score or tier a list, keep the judgment limited to ICP fit, enrichment completeness, identity confidence, or defined signal strength. If the user asks which accounts to work now, where to focus, or what rep action deserves priority, route to `seller-account-dashboard`.

## Key Dependency Categories

These are particularly important for this workflow; use your best judgment to potentially include other data sources to improve quality.

- [Blocking] ~~Sales Intelligence for company/contact discovery, firmographics, technographics, intent, lookalikes, and provider-native signals. It blocks discovery, contact discovery, lookalikes, intent, and provider-native enrichment when equivalent requested data is not already grounded.
- ~~CRM for account identity, customer status, ownership, lifecycle stage, opportunity context, and duplicate resolution
- ~~Knowledge & Files for ICP definitions, territory rules, target lists, segmentation rules, and enrichment conventions
- User-provided rows, CSVs, exports, domains, emails, and ICP notes when they already define the work
- Public research only for narrow validation or gaps that configured sources cannot answer

Start with the category that owns the requested fields, then attempt only additional categories that materially improve coverage, identity confidence, or the decision. If a material or user-named provider has no callable capability, explicitly say it is unavailable in this session before discussing a hypothetical provider workflow. When that prevents a filtered company search, request only company name and the fields required to verify the user's actual hard filters. Company name is the identifier; do not require a second identifier, domain, provider URL, personal contact, or optional enrichment field unless the user explicitly nee

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: find-customer-quotes
description: "Use when the user wants verbatim customer or prospect quotes, voice-of-customer evidence, theme validation, objection evidence, product-friction examples, or support for a product area, use case, or sales narrative. Retrieve from transcripts, call notes, supplied transcript-like recordings or exports, and other grounded call material using explicit speaker-confidence and provenance rules. Read the Sales index and this focused workflow even when the user already supplied every transcript excerpt."
---

# Find Customer Quotes


## Context-Gathering Intake

Whenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance.

Extract high-confidence customer or prospect language from transcript-like evidence. This skill owns quote discovery, verification, selection, and readable provenance; it is not call analytics, paraphrase generation, legal review, or a posting workflow.

## Common Skill Instructions

MANDATORY: If the Sales index has not genuinely been read in this conversation, read [the Sales index](../index/SKILL.md), then read this focused skill in full before extracting quotes or answering. User-supplied transcripts establish the evidence source; they never waive the required Sales routing and instruction reads.

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

Use the narrowest evidence lane that can support the requested quote set.

- [Blocking] ~~Meeting Transcripts for transcript search, fetched transcript text, speaker labels, participants, dates, companies, and source links. It blocks the default live-source quote-extraction path; explicit transcript-like material already in context satisfies the need.
- ~~CRM only for account identity, customer/prospect status, and company or segment filters that narrow transcript search
- ~~Knowledge & Files for uploaded or exported transcripts and grounded call notes that preserve direct language and speaker context

Transcript-like evidence is required. ~~CRM, account summaries, public research, internal notes, and memory can narrow scope but are never quote evidence. If no live or user-provided transcript-like material exists, ask for a transcript export, pasted transcript text, recording export with text, or grounded call notes.

## Reference Loading

`SKILL.md` owns the normal transcript-first path, thresholds, and readable output. Use [references/extraction-and-output.md](references/extraction-and-output.md) when transcript parsing is ambiguous, speaker-role confidence is hard to judge, quote ranking or deduplication needs the full rules, JSON is requested, or failure handling needs the exact response shape.

## Terms

- **Quote candidate:** a verbatim snippet that may be useful, but still needs speaker, context, and usage checks before being treated as customer evidence.
- **Customer confidence:** confidence that the speaker is actually a customer or prospect rather than an internal teammate, partner, or unknown speaker.
- **Fallback evidence:** relevant non-customer or lower-confidence material that may explain a gap but should not be presented as a customer quote.
- **Safe usage notes:** guidance on attribution, sensitivity, confidence, and where the quote can responsibly be reused.

## External-Speaker Evidence Gate

Before treating any quote as customer or prospect evidence, verify from available participant context, attendee domains, company or role labels, or surrounding transcript text that the speaker is external to the user's organization. Internal sellers, coworkers, internal product users, partners, and customer proxies never qualify, even when their feedback is relevant. Without affirmative external affiliation, keep customer confidence below threshold and exclude the quote; report `0/[target]` when none qualify.

## Workflow Gu

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: find-key-internal-sources
description: "Use when a seller needs to find the best internal experts, owners, approvers, documents, channels, source-of-truth materials, or escalation routes for a customer question, product topic, competitive objection, implementation issue, account task, or other sales-support need. Route questions such as 'who knows about this?', 'what should I read?', 'where is the source of truth?', and 'which internal channel or document should I use?' here."
---

# Find Key Internal Sources

Find the smallest reliable internal route that helps a seller get an answer or unblock work: the right people, maintained docs, public channels, decision forums, and escalation paths. The default output is a quick, evidence-backed routing map plus a draft-ready first ask. This workflow is read-only and never posts, assigns, or updates systems.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

Use only the categories needed for the selected route; do not fan out across every source by default.

- ~~Knowledge & Files for maintained source-of-truth pages, owner metadata, wikis, field guides, playbooks, FAQs, runbooks, launch docs, and decision records
- ~~Internal Messaging for public channels, channel topics, threads, active contributors, escalation routes, support channels, and decision forums
- ~~CRM for customer or account identity, ownership, opportunity context, and CRM-visible blockers that clarify an account-specific question

Prefer canonical ownership and source-of-truth material over chat mentions. ~~CRM can resolve account truth, but it does not by itself prove who owns the internal answer.

## Reference Loading

`SKILL.md` owns the normal route selection, bounded search, ranking, and output map. Load references only when their extra detail matters:

- Use [references/search-patterns.md](references/search-patterns.md) when query fan-out, compound facets, source-specific search, or stopping rules need more detail.
- Use [references/company-context.md](references/company-context.md) only after the generic pass, when user-provided or connector-visible terminology is likely to change the route.

## Terms

- **Source-of-truth page:** the maintained doc, wiki, tracker, or page that should be treated as the most authoritative answer source.
- **DRI:** directly responsible individual, the person accountable for a topic, decision, or follow-through.
- **SME:** subject matter expert, someone with practical depth on the topic even if they are not the accountable owner.
- **Decision forum:** the recurring meeting, channel, doc, or group where tradeoffs and approvals are handled.

## Workflow Guidance

### 1. Resolve the topic and route

- Require a concrete topic_or_task: customer question, product topic, objection, implementation issue, account blocker, initiative, or source-of-truth gap.
- Infer it from the active thread or provided Sales output when clear. If still ambiguous, make a bounded candidate pass of at most three source reads, then ask one friendly question with up to three concrete candidates.
- Treat ambiguous company-like names as possible account anchors. Use a bounded ~~CRM lookup when available before relying on internal docs or messages for account-specific routing.
- Default to quick. Use deep only when requested or when a high-stakes question clearly needs broader corroboration.

Choose the smallest answer route that satisfies the request:

- owner_route — who owns, approves, knows, or should be contacted
- doc_route — what to read, which page is maintained, or what wording is approved
- channel_route — where to ask, discuss, escalate, or get support
- full_map — experts, docs, and channels together when the request actually needs all three

### 2. Search canonical sources first

- For owner_route, start with maintained ownership, directory, rout

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: follow-up-after-call
description: "Use after a completed customer, prospect, partner, or important internal sales call, discovery session, demo, or conversation, including when the user supplies or uploads a transcript, notes, recording summary, or other grounded evidence. Advise on, assess, qualify, recap, produce seller-ready follow-up actions and drafts, or build a completed-call discovery, pilot, evaluation, or customer-readout deck."
---

# Follow Up After Call


## Context-Gathering Intake

Whenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance.

Turn grounded call evidence into a seller-ready follow-up package that preserves what was actually said, makes ownership visible, and gives the seller copy they can use immediately. This skill owns the post-call synthesis and drafts, including an explicitly requested document; it does not send, post, create email drafts, or update CRM.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

These categories are particularly important for this workflow; use other sources only when they materially improve the package.

- [Blocking] ~~Meeting Transcripts for the primary transcript, grounded notes, participant language, decisions, commitments, objections, and source links. It blocks the default live-source follow-up path; explicit grounded call evidence already in context satisfies the need.
- ~~Calendar for recent-call identification, attendees, timing, and upcoming related meetings
- ~~CRM for account, opportunity, contact, owner, and CRM-ready next-step context
- ~~Email for customer-facing thread context when the call evidence or promised follow-up lives there
- ~~Internal Messaging for internal account context and a safe suggested destination for the team recap
- ~~Knowledge & Files for exported transcripts, call notes, account notes, and follow-up assets

Grounded call evidence is required. CRM, calendar, files, and messages can enrich the package but cannot substitute for a transcript, grounded notes, or a customer-facing thread that records the call. If evidence is missing, stale, or conflicting, state the limitation rather than reconstructing the call.

## Reference Loading

`SKILL.md` owns the normal evidence-first workflow, chat-first draft behavior, and output package. Load references only when their extra detail changes the decision:

- Use [references/request-schema.yaml](references/request-schema.yaml) when normalizing structured input, relative call dates, meeting-recording identifiers, or fallback evidence paths.
- Use [references/opportunity-and-channel-selection.md](references/opportunity-and-channel-selection.md) when opportunity ranking or internal destination safety is ambiguous.

## Workflow Guidance

### 1. Resolve the call and evidence

- If the user supplies a transcript, notes, link, or clearly identified call, start there.
- If supplied context identifies multiple plausible calls but the request asks for one follow-up, ask which call to use before searching, enriching, combining calls, or drafting; offer the supplied call or account names as choices.
- If the call-resolution path isn't clear, ask the user via [User Input](../../shared_skill_instructions.md#user-input). For a bare invocation such as “Follow up after my call,” do not assume a meeting; offer:
  - `Use my most appropriate recent grounded call`
  - `Use a call, account, attendee, or date I specify`
  - `Use transcript or notes I provide`
- For “my latest call,” “today’s call,” “earlier today,” “yesterday,” “last week,” “my most appropriate recent meeting,” or a named account without a source, treat the wording as a retrievable anchor: search the narrowest recent window in ~~Calendar and ~~Meeting Transcripts, then offer up to three concrete candidates via [Use

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: get-rep-call-feedback
description: Use when the user wants evidence-backed coaching for one rep's calls, especially by comparing the rep with peer examples to identify repeatable best practices, specific upgrade moments, and practical next-call language.
---

# Get Rep Call Feedback


## Context-Gathering Intake

Whenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance.

Turn grounded call evidence into practical coaching for one rep. This skill compares the target rep with relevant peer examples, extracts repeatable moves, and maps them to exact moments the target rep can improve. It owns the coaching readout only; it does not create scorecards, send feedback, post messages, or save coaching artifacts.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

These categories are particularly important for this workflow; use other sources only when they materially improve call selection or coaching context.

- [Blocking] ~~Meeting Transcripts for target and peer call search, summaries, transcript moments, speaker context, dates, companies, and clickable call links. It blocks the default live-source feedback path; explicit transcript-like call evidence already in context satisfies the need.
- ~~Knowledge & Files for user-provided or exported transcripts, call notes, manager examples, and prior coaching context

Transcript-like call evidence is required for behavioral claims. Manager notes, CRM outcomes, and generic impressions can shape focus, but cannot substitute for observed call evidence. If live transcripts are unavailable, continue from sufficiently detailed pasted or exported material and label the coverage limit.

## Reference Loading

`SKILL.md` owns the normal benchmarked-coaching loop and output format. Load references only when their extra detail matters:

- Use [references/call-transcripts-connector-playbook.md](references/call-transcripts-connector-playbook.md) when date-window conversion, attendee-filter limitations, threshold fallback, or sparse-result recovery needs more detail.
- Use [references/request-schema.yaml](references/request-schema.yaml) for structured input normalization.
- Use [references/source-priority.md](references/source-priority.md) when evidence quality is mixed.
- Use [references/output-contract.md](references/output-contract.md) when checking required sections or downstream compatibility.

## Terms

- **MAP:** mutual action plan, a shared customer-and-seller plan with owners, milestones, and dates.

## Workflow Guidance

### 1. Resolve the target and comparison set

- If neither a benchmarked target/comparison set nor a focused-coaching anchor is clear, ask the user via [User Input](../../shared_skill_instructions.md#user-input). For a bare invocation such as “give me call feedback,” do not assume a target rep, peer set, or coaching focus; offer: `My calls compared with two relevant peers`, `A named rep compared with named peers`, and `Focused coaching on a supplied call set or theme`.
- If the user names only “my recent calls” without a peer basis or focused-coaching anchor, offer the same explicit choices before gathering deeper evidence. Do not infer a representative rep, peer set, or feedback mode from a fresh request.
- Require a target rep or clearly supplied target call set, plus transcript-like call evidence.
- For benchmarked feedback, prefer user-named peer reps. If peers are omitted, use named top performers only when the user explicitly asks for that comparison; otherwise ask for at least two peers or offer source-derived candidates after a bounded search.
- Accept an explicit coaching theme, call type, product focus, account, time window, audience, or requested depth when provided. Do not force optional scope.
- Use product focus only when the us

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: index
description: "Route customer- and revenue-facing work through Sales first: seller and leadership dashboards, prospects, accounts, calls, deal and renewal strategy, pipeline, forecasts, commercial research, internal support, business cases, sales presentations, customer-facing slides, PowerPoint, Google Slides, coaching, and verbatim customer quotes from supplied call notes. Activate for seller, leader, customer, prospect, partner, account, opportunity, or commercial intent; read this index and the focused workflow even when evidence is supplied."
---

# Sales Index Skill

The intent of this skill is to correctly route to skills within the Sales plugin. All other skills in this plugin are not implicitly invokable, and must be discovered via this skill.

## Initial Skill Frontmatter Read.

MANDATORY: Read the frontmatter description for ALL skills in this plugin, and based on that, decide which to trigger and read more deeply. Do this quickly before handling any other instructions. Select the best focused owner based on those descriptions; the selected skill defines its own applicability, clarifications, modes, and workflow behavior.

Reading a wildcard, aggregated catalog, or all skill frontmatter does **not** load the selected workflow. Once the focused owner is known, explicitly read its exact `skills/<selected-skill>/SKILL.md` path in full in its **own bounded read** before proceeding; do not bundle it with Sites, dependencies, or other skills, and allocate enough output tokens that the selected instruction is not truncated. The catalog scan, shared instructions, and dependency documentation never substitute for this complete focused read.

A standalone customer-facing PowerPoint or decision deck requested from a complete user-supplied customer fact packet, with no new meeting preparation, customer ROI/business-case analysis, or completed-call evaluation required, is owned by `sales-presentations`. Read `skills/sales-presentations/SKILL.md` by itself in full before reading the generic Presentations authoring skill or selecting `build-business-case`; a finished fact packet is the content brief, not a request to invent another seller workflow.

## Mandatory Focused Workflow Path

If the selected focused skill's description explicitly declares a self-contained instruction-path opt-out, honor that focused skill's declared exception: shared instructions and dependencies are optional, including when already loaded or read in parallel; follow the self-contained opening without discovering providers, calling connectors, suggesting installation, or performing external writes. Never infer an exception for another skill.

For every real Sales workflow, load all applicable instructions before the first clarification or `request_user_input` call, before resolving dependencies, suggesting plugin installation, calling a connector, or preparing a substantive response:

1. Read this Sales index and select the specific focused Sales skill that owns the request based on its description.
2. Read that focused skill in full, including its `## Key Dependency Categories`.
3. Read [the shared Sales skill instructions](../../shared_skill_instructions.md) in full.
4. Read [Sales dependencies](../../dependencies.md) in full.
5. Read any mandatory workflow reference named by the focused skill before its first question; then clarify, resolve dependencies, offer an allowed installation, gather evidence, or respond. Reading installed instructions is safe setup, not inspecting the user's files or connectors.

Instruction reads and other safe setup tool calls may run in parallel for every workflow, including self-contained demonstrations; no strictly sequential tool-call barrier is required.

MANDATORY: For a requested document, deck, or workbook, read and follow the focused Sales owner in full before loading an authoring skill, inspecting a template, or creating the artifact; the authoring skill never replaces the seller workflow.

## Broad 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: plan-deal-strategy
description: Use when the user wants strategy for one active deal, renewal, negotiation, buying process, or initial sales motion for an offer or product. Build a grounded deal map or practical sales plan with objections, sequencing, posture, and prioritized next actions. Use prepare-for-meeting instead for multi-account same-day customer call queues.
---

# Plan Deal Strategy


## Context-Gathering Intake

Whenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance. For a sufficiently grounded first-sale motion, deliver the initial plan before any optional clarification.

Turn active-deal evidence or clearly supplied offer context into a practical strategy for advancing a sale or shaping an initial sales motion. This skill owns the deal map, buying committee, negotiation posture, objections, sequencing, and action plan; it is not first-call prep, data-first prospecting, or a writeback workflow.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

These categories are particularly important for this workflow; use other sources only when they materially improve the strategy.

- [Blocking] ~~CRM for authoritative account and opportunity identity, stage, amount, close date, owner, contacts, and recent activity. It blocks the default active-deal strategy path unless sufficiently grounded deal truth is already in context.
- ~~Meeting Transcripts for stakeholder language, objections, commitments, decisions, procurement signals, and call continuity
- ~~Email for customer-facing progression, approvals, negotiation, legal/procurement exchange, and unanswered asks
- ~~Internal Messaging for internal blockers, owner alignment, escalation paths, and execution risk
- ~~Knowledge & Files for account plans, mutual action plans, implementation docs, risk logs, and strategy artifacts
- ~~Calendar for upcoming decision forums, executive meetings, procurement/legal milestones, and timing pressure
- ~~Sales Intelligence only when it sharpens a stakeholder or company hypothesis after the deal is anchored

Keep ~~CRM authoritative for CRM-owned deal truth. Supporting sources sharpen risks, stakeholders, timing, and actions; they do not invent or override stage, amount, owner, close date, or active-deal presence.

## Reference Loading

`SKILL.md` owns the normal deal-strategy flow and output package. Load references only when their extra detail matters:

- Use [references/request-schema.yaml](references/request-schema.yaml) for structured input, legacy aliases, mode enums, stage hints, time-window bounds, or seed-evidence normalization.
- Use [references/risk-rubric.md](references/risk-rubric.md) when risk type, severity, likelihood, confidence, prioritization, or mitigation fields are ambiguous.

## Workflow Guidance

### 1. Qualify and choose a mode

- Use this when there is an active account, opportunity, renewal, buying process, or sufficiently detailed user-provided first-sale context; a first sale does not require prior discovery or an existing opportunity.
- Seek enough evidence to identify the current deal motion and at least one blocker, stakeholder question, or next-action need. If the anchor is sufficient but evidence is thin, produce a low-confidence pack with explicit gaps rather than inventing detail.
- If the request is first-call prep with little prior evidence, route to `prepare-for-meeting` when a meeting anchor exists; otherwise ask for basic account context and provide lightweight manual prep.
- Default to `Full Strategy Pack`. If the user asks for only one artifact, use the matching partial mode and keep the investigation scoped to it.

#### First-Sale Motion From Supplied Context

- A user-provided product or offer, target buyer, pilot or evaluation, and stated objections are a 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: prepare-for-meeting
description: "Use when the user wants to prepare for one or more upcoming seller meetings with customers, prospects, partners, accounts, or important stakeholders; gives a bare request such as Meeting prep or prep my meetings; requests daily or date-based seller meeting preparation; asks to organize a same-day customer call queue; asks for the most important qualifying meeting of the day; identifies seller meetings only by company, attendee, topic, or date; or wants a customer-facing presentation or deck for a first call, EBC, executive workshop, or upcoming customer meeting. Produce an individual meeting brief, chronological multi-meeting agenda, or deliberate customer presentation as appropriate. Exclude neutral product-discovery interviews and user-research discussion guides without seller, account, opportunity, or commercial intent."
---

# Prepare for Meeting


## Context-Gathering Intake

Whenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance.

Prepare a sales person for a critical customer or internal meeting, with all relevant context needed to help them reach the stated or assumed goal of the meeting.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Meeting Ranking

Use this priority order for selecting meetings if the specific meeting is ambiguous.

1. Explicit user request, named meeting, named account, named topic, or stated preference
2. Meetings the user owns, leads, presents in, or is expected to drive
3. Customer, prospect, partner, renewal, opportunity, or strategic account meetings
4. Large or cross-stakeholder internal meetings with decisions, dependencies, launches, escalations, or leadership visibility
5. Meetings with buyer, executive, technical decision-maker, or senior stakeholder attendance
6. Meetings with explicit decisions, blockers, risks, commitments, or time-sensitive next steps
7. Meetings where prep is likely to materially improve the user’s next action

Routine internal syncs, 1:1s, recruiting meetings, and performance discussions are lower priority, but may still qualify when explicitly requested, user-owned, or clearly high-stakes.

## Key Dependency Categories

These are particularly important for this workflow; use your best judgment to potentially include other data sources to improve quality.

- [Blocking] ~~Calendar for meeting identity, invite context, agenda, and attendees. It blocks only when the meeting must be discovered or selected.
- ~~Meeting Transcripts for prior decisions, objections, commitments, and continuity
- ~~Email for prior meeting notes, recent questions, and customer-facing context
- ~~Internal Messaging for internal strategy, blockers, owners, and dependencies
- ~~Knowledge & Files for prior meeting notes, strategy docs, and assets
- ~~CRM for account, opportunity, renewal, and contact truth
- ~~Sales Intelligence only when it materially improves preparation

Avoid unsupported claims. If context is missing, stale, or conflicting, state the limitation.

## Workflow Guidance

These meeting-specific steps modify and override the shared [Default Workflow](../../shared_skill_instructions.md#default-workflow).

- 1. Resolve Dependencies and Clarify
    - HARD STOP: For a genuinely bare request such as “Meeting prep” or “prep my meetings,” first ask: “Should I run this as: Prep for an upcoming meeting, Overview of today's meetings, or Overview of tomorrow's meetings?” Do not ask which event to prepare, call any connector, inspect earlier meetings, research an account, or draft until the user selects a mode. Never infer the target from earlier calls.
    - “My next customer meeting,” “my upcoming customer call,” a named meeting, an explicit date, and a supplied invitation already select upcoming-meeting mode. Do not ask the generic mode que

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: review-forecast
description: Use when the user wants forecast posture, forecast accuracy, commit, upside, forecast-call preparation, or a pipeline or deal-risk review for a seller book, team, period, report, or named deal set. Produce a manager-ready forecast rollup, risk posture, recommendation changes, evidence gaps, and follow-up actions.
---

# Review Forecast


## Context-Gathering Intake

Whenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance.

Turn CRM or exported pipeline truth into a fast, manager-ready forecast readout. This skill owns the rollup, risk posture, recommendation changes, and follow-up actions; the initial review is read-only and never changes forecast categories, close dates, CRM records, tasks, or messages.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

These categories are particularly important for this workflow; use other sources only when they materially change a top recommendation.

- [Blocking] ~~CRM for authoritative opportunity, amount, stage, forecast category, close date, owner, next step, activity, report, and snapshot truth. It blocks unless a CRM report/export, pasted snapshot, or linked forecast-truth source is already grounded in context.
- ~~Knowledge & Files for forecast docs, manager notes, close plans, deal-desk trackers, approval trackers, and category conventions
- ~~Meeting Transcripts for recent customer evidence that changes timing, stakeholder, urgency, objection, or next-step confidence
- ~~Email for customer engagement, timing, unanswered asks, and commercial or procurement movement
- ~~Internal Messaging for manager, deal-desk, legal, product, approval, blocker, and account-team signals

Use ~~CRM as the default forecast truth. Use a user-provided/exported pipeline snapshot only as a fallback when CRM cannot be used. Notes, messages, and transcripts are supporting evidence, not substitutes for missing opportunity truth.

## Reference Loading

`SKILL.md` owns the normal forecast-review path and output shape. Use [references/request-schema.yaml](references/request-schema.yaml) when structured input, posture/category/amount enums, comparison inputs, or enrichment-mode normalization matters.

## Workflow Guidance

### 1. Resolve scope and forecast conventions

- If the review scope or forecast truth path is not clear, ask the user via [User Input](../../shared_skill_instructions.md#user-input). For a bare invocation such as “review the forecast,” do not assume an owner book or truth source; offer: `My current forecast-period owner book from live CRM`, `A named team, owner, report, or pipeline view`, and `A pasted/exported forecast snapshot or deal set`.
- If the user names only “my forecast” without defining the source, offer the same explicit choices before building a rollup. Do not retrieve deeper opportunity evidence or render a posture review until the user selects a scope and truth path.
- Require one scope anchor: owner/book, team, period, named report or pipeline view, focused accounts, focused opportunities, or a supplied deal set.
- Require one forecast truth source: ~~CRM data, a CRM report/export, pasted pipeline table, current snapshot, or linked forecast context. If none exists, stop and ask for the smallest usable source rather than inferring a forecast from anecdotes.
- Before rendering a posture review, establish the forecast posture standard, category convention, and amount basis. Find concrete defaults in the supplied data, ~~CRM metadata, or ~~Knowledge & Files first. If any required choice is only inferred, present the sourced default and ask the user to confirm it before producing the posture review; proceed without confirmation only when the active thread or supplied source clearly defines all three.
- Do not inter

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: review-rep-call-trends
description: Use when the user wants to understand how a sales or customer-facing rep's call behavior is changing over time. Produce an evidence-backed trend readout with improvements, regressions, stable patterns, coaching actions, and calls to re-listen.
---

# Review Rep Call Trends


## Context-Gathering Intake

Whenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance.

Turn a representative time-based call sample into objective coaching guidance. This skill compares older and newer call evidence to identify genuine improvement, regression, and stable patterns. It owns the readout only; it does not create trackers, send feedback, post messages, or save artifacts.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

These categories are particularly important for this workflow; use other sources only when they materially improve sampling or interpretation.

- [Blocking] ~~Meeting Transcripts for time-sliced call search, summaries, transcript moments, speaker context, dates, companies, and clickable call links. It blocks the default live-source trend path; explicit older/newer call evidence already in context satisfies the need.
- ~~Knowledge & Files for user-provided or exported transcripts, call summaries, manager-provided call sets, and prior coaching context

Call summaries or transcripts are required for trend claims. Manager notes, CRM outcomes, and generic impressions may provide context, but cannot substitute for older-versus-newer call evidence. If the sample is small or skewed, return a limited trend readout rather than overgeneralizing.

## Reference Loading

`SKILL.md` owns the normal time-sliced trend workflow and output format. Load references only when their extra detail matters:

- Use [references/request-schema.yaml](references/request-schema.yaml) for structured input normalization.
- Use [references/rubric.md](references/rubric.md) when the compact behavior categories are insufficient for classifying evidence, especially technical-success or meeting-craft signals.

## Workflow Guidance

### 1. Resolve the rep and comparison basis

- If the target rep or comparison basis is not clear, ask the user via [User Input](../../shared_skill_instructions.md#user-input). For a bare invocation such as “review call trends,” do not assume a rep or time window; offer: `My calls over the default trailing 90 days`, `A named rep over the default trailing 90 days`, and `Supplied older/newer call sets or a custom window`.
- If the user names only “my call trends” without a comparison basis, offer the same explicit choices before broad retrieval. Do not infer a representative rep, comparison window, or trend-review mode from a fresh request.
- Require a target rep or clearly supplied target call set and a comparison basis: time window, older/newer sets, transcript set, call summaries, or explicit coaching dimension.
- After the user selects “my calls,” use the current user when available. For an ambiguous manager-style request, ask for the rep's exact display name or email before broad retrieval.
- If an attendee-filtered search returns zero results, try small grounded variations: first/last name only, then an obvious nickname when context supports it. If those still return zero, ask for the rep's exact display name in the selected ~~Meeting Transcripts source.
- After the user selects the default Trend Review path, use the trailing 90 days split into three non-overlapping slices: 0-30 days, 31-60 days, and 61-90 days. Convert every relative window to concrete absolute dates before searching.
- Preserve user-specified motion, product focus, account, coaching dimension, or audience. If a supplied date phrase could materially change the sample, ask one brief clarification

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: sales-company-research
description: Research companies, partners, and referral channels to shape draft outreach approaches, messages, or partner motions for an already known customer, recipient, or audience. Exclude who-to-contact discovery, contact identification, prospect-list enrichment, descriptive company profiling, and internal source finding.
---

# Sales Company Research

Turn external company or partner research into a grounded, draft-only outreach approach. This skill owns research-to-outreach work: company or partner context, fit hypotheses, likely motion, and message drafts. It does not own data-first prospect-list enrichment, internal source-of-truth lookup, sending messages, or CRM writes.

## Common Skill Instructions

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

- ~~Sales Intelligence for company, contact, partner, firmographic, similarity, and external-signal context
- ~~CRM for existing account, ownership, lifecycle, opportunity, and prior-engagement truth
- ~~Knowledge & Files for approved positioning, proof points, partner criteria, and outreach guardrails
- Public research for company-controlled facts, reputation, partner programs, and current market context

Use the user-provided company, domain, partner type, product, or offer as the anchor. If a material anchor is missing, ask only for the smallest input that changes the research path; otherwise proceed with clearly labeled assumptions.

## Workflow

1. Resolve the research target and commercial purpose: company fit, partner fit, referral landscape, reputation, or outreach approach.
2. Gather the narrowest useful evidence from authoritative sources first. Keep sourced company or partner facts distinct from inferred fit, likely buyer need, and recommended motion.
3. Explain why the target or partner type is promising, uncertain, or a poor fit. Name material evidence gaps instead of filling them with generic claims.
4. Draft only the outreach artifact the user asked for, such as an approach, short email, message, connection request, or partner script. Do not send, post, create a draft in an external system, or update CRM.

## Routing Boundaries

- Use `enrich-company-and-contact-data` when the primary output is a list, missing fields, contact discovery, segmentation, qualification, or firmographic comparison.
- Use `find-key-internal-sources` when the primary question is which internal owner, document, channel, approver, or source of truth to use.
- Use `plan-deal-strategy` when the primary job is advancing a defined sale, negotiation, renewal, buying process, or initial sales motion rather than researching a target to shape outreach.

### Next Step Options

After the first output, offer the most relevant follow-up from the options below. Offer one clear transition, not a menu. Suggest ONLY these unless you are very confident another option is more useful:
- Improve the fit hypothesis, audience, angle, or sequencing using the user's guidance.
- Draft an alternate outreach version for a different stakeholder or channel.
- Hand the target to meeting prep or deal strategy when an active conversation or motion exists.
- Create a concise research brief or internal account-team note after the content is reviewed.
- Close the smallest material evidence gap that would change the outreach approach.

Next steps to avoid:
- Sending outreach, creating external drafts, or writing CRM without a separate explicit request.

## Output

Return a compact research-to-outreach package:

```md
# Sales Research: [Target or Partner Segment]

## Sourced Context
- [Fact + source]

## Fit And Motion
- **Fit hypothesis:** [Inference and confidence]
- **Likely need or partner angle:** [Inference and evidence basis]
- **Risks / gaps:** [What remains unknown]

## Recommended Outreach Approach
- [Audience, angle, sequencing, and safe next step]

## Draft 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
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."
---

# Sales Leadership Dashboard

Create 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.

Ordinary forecast analysis remains with `review-forecast`; fictional demonstrations remain with the self-contained demo skill.

## Common Skill Instructions

MANDATORY: 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.

MANDATORY: Read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md) and the [shared dashboard lifecycle](../../references/dashboard-lifecycle.md).

**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.

**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.

## Key Dependency Categories

- [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.
- ~~Knowledge & Files for leadership targets, forecast conventions, scorecards, and account plans.
- ~~Internal Messaging for verified ownership, seller support, approvals, and customer blockers.
- ~~Meeting Transcripts and ~~Email for grounded customer decisions, risks, and next steps.
- ~~Calendar for actual customer meetings and decision timing when material.

Sources beyond CRM are optional. Never widen the user's authorized scope, invent an account universe, or let supporting evidence override CRM truth.

## Build The Operating Canvas

**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-das

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: sales-presentations
description: Use for explicitly requested customer-facing PowerPoint or Google Slides creation from an already completed meeting brief or approved customer proposal, or a complete user-supplied customer fact packet needing a standalone buyer-ready decision deck without new seller analysis. Use as the presentation partner for finished seller-workflow outputs; ongoing meeting preparation, customer ROI or business-case analysis, buyer-ready decision-deck development requiring new seller analysis, and completed-call evaluation belong to their respective seller workflows.
---

# Sales Presentations

## Common Skill Instructions

MANDATORY: 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.

MANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).

## Key Dependency Categories

- [Blocking] ~~Presentation Authoring for creating the requested editable PowerPoint or Google Slides deck through the available [@Presentations](plugin://presentations@openai-primary-runtime) capability.
- ~~Knowledge & Files for the supplied template, source deck, customer materials, and reviewed account evidence.

Turn the current Sales workflow output and its evidence into a customer-facing decision narrative. This skill owns sales-specific narrative, audience, and safety guidance; the latest [@presentations](plugin://presentations@openai-primary-runtime) plugin owns slide authoring, template handling, rendering, and visual QA.

## Invocation

- Use this skill only when the user explicitly requests a deck or accepts a deck offer. If the initial request already asks for slides, complete the triggering Sales workflow and build the deck in the same run.
- Treat the triggering question and the immediately preceding or current Sales output as the content brief. Build the deck directly from that material; do not replace it with a generic company or product pitch.
- After completing the focused and shared Sales instruction chain, resolve the blocking `@presentations` capability before inspecting templates, loading artifact helpers, or drafting. Read and follow its installed skill immediately before authoring. If it is unavailable, use the native plugin-install surface when available; if installation is unavailable or declined, explain that an editable deck cannot be created without that capability. Never recover an excluded plugin from a global cache, substitute another slide implementation, or repeat a declined offer.
- Produce the requested editable deck, not only an outline. Preserve the source package and cited evidence so later edits remain grounded.

## Customer-Facing Standard

- Write for the named customer and meeting audience. Start with their priorities, workflows, requirements, and decision; introduce the seller solution only as the response.
- Build a clear arc: customer context -> what matters -> recommended approach -> value or proof -> risks and plan -> decision or next step.
- Give each slide one decision-useful takeaway and use a conclusion-style headline. Prefer customer language and direct answers over product taxonomy or feature inventories.
- Keep the deck customer-safe. Exclude internal strategy, opportunity probability, negotiation posture, margins, unverified competitive claims, private CRM notes, and seller-only coaching.
- Preserve evidence posture. Label assumptions, ranges, open questions, and dependencies; never convert an inference or benchmark into a customer-confirmed fact. Put useful citations near material claims and include a compact sources/assumptions appendix when needed.
- For enterprise evaluation decks, emulate the strongest CompuCom pattern: organize around the buyer's questions, lead each section with a direct answer, separate confirmed capability from caveat or availability, map personas/work

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: seller-account-dashboard
description: "Build or update a real seller account dashboard, account home, customer workspace, owned book of business, seller pipeline operating canvas, or clearly labeled placeholder or representative view; also handle explicit account prioritization, rankings, ranked worklists, account focus, and weekly account priorities. Reuse verified CRM or authoritative supplied account data and an existing matching dashboard. Never use for fictional demos or net-new account discovery."
---

# Seller Account Dashboard

Build an ongoing, customizable, real-data operating canvas for one seller, or an explicitly requested, clearly labeled empty placeholder. Account prioritization is one useful requested view, not the identity or scope of the whole dashboard.

## Common Skill Instructions

MANDATORY: 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. Before the first clarification, next read [the shared Sales skill instructions](../../shared_skill_instructions.md), [Sales dependencies](../../dependencies.md), and [shared dashboard lifecycle](../../references/dashboard-lifecycle.md), in that order. Follow all five before selecting, rendering, refreshing, or publishing.

## Key Dependency Categories

- [Blocking] ~~CRM only for populated or representative dashboards: account ownership, the account universe, opportunities, contacts, stage, amount, and activity; authoritative user-supplied scoped records can satisfy it. Exception: a clearly labeled empty placeholder never requires CRM.
- ~~Calendar for verified meetings, decision timing, and in-flight customer motion.
- ~~Meeting Transcripts for customer history, objections, decisions, and stakeholder context.
- ~~Email for customer requests, confirmed response status, and promised follow-ups.
- ~~Internal Messaging for current account changes, active workstreams, owners, and blockers.
- ~~Knowledge & Files for territory rules, account plans, target lists, and suppression conventions.
- ~~Sales Intelligence for corroborated fit, contacts, and why-now context after CRM anchors the set.

Sites is optional and deferred; never block the first useful local result on site setup or publishing.

## Real Account Canvas

**Choice protocol:** Each `request_user_input` call MUST contain exactly one question (`questions.length === 1`); await its response before the next separate call, including within the same turn. Resolve a verified role mismatch, matching unpublished-local-project choice, dashboard goal, and style separately in that order; never combine them. Ask the existing-dashboard question only after exactly one matching unpublished dashboard is verified or authoritatively identified. If no matching dashboard exists, skip this question and proceed directly to the dashboard goal; never infer an existing project from named accounts or the dashboard request. Each applicable choice MUST have exactly three options, overriding any general two-or-three guidance; exactly one is suffixed `(Recommended)` and appears first. A matching unpublished project's labels are exactly **Use existing (Recommended)**, **Modify existing**, and **Create new**; never inspect an authoritative user-supplied identity/path just to confirm it. The client supplies Other; never add it yourself. If the user explicitly requests one question at a time in chat, ask each in chat instead of using the picker.

**Dashboard goal:** 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 seller choices, personalized only from reliable existing memories and quickly available authorized context: **Account priorities and changes (Recommended)**, **Pipeline and forecast risk**, and **Customer meetings and follow-ups**. 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.