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` for owner, territory, portfolio, watchlist, daily-monitor, or “which accounts need attention?” requests. If the user selected Monitor but did not supply a watchlist, owner, territory, or portfolio, offer:
  - `Accounts I own in CRM`
  - `A named owner or territory`
  - `A watchlist or account list I provide`
  Do not broaden to a representative seller or retrieve deeper evidence until the user selects a scope.
- Require exactly one account for Adhoc. Require a watchlist, owner, territory, portfolio, or sufficiently detailed account list for Monitor.
- Default to the last 14 days only when the user does not provide another window. An explicit historical start and end is authoritative and includes both dates: apply `timestamp >= start` and `timestamp < day_after_end`. Never silently expand to the first of the month, the present day, or a fresh 14-day window. Preserve supplied focus areas such as expansion, churn, rollout blockers, or stakeholder movement.
- Accept `sfdc_account_id` as a legacy alias for `crm_account_id`. When structured input conflicts with prompt wording, use the structured input as the source of truth and state the resolved scope.
- After the mode and scope are known, if the anchor is ambiguous, make a bounded candidate pass before asking: start with ~~CRM when available, make at most three source reads, and offer up to three concrete candidates.
- If the user says `okay` in response to concrete candidates presented in the current conversation, pick a suitable recent, important-looking, or high-signal account from those candidates instead of skipping. Ask one concise clarification when no suitable account, owner portfolio, or watchlist is visible.

### 2. Bound and resolve the account universe

- For Adhoc, resolve one account by stable CRM id, exact name/domain, or sufficiently detailed user-provided account context.
- When the user names an account and a specific renewal, retrieve the exact CRM Account and its corresponding Opportunity through direct, bounded, read-only CRM lookups before optional research. Preserve the returned account name, account relationship, requested renewal identity, and year; retry a schema or call-shape error with the provider's supported arguments rather than treating it as an unavailable account.
- For Monitor, use an explicit watchlist as the full scope. Otherwise use the requested owner/territory/portfolio in ~~CRM with a bounded first pass.
- For owner-scoped Monitor, prefer primary-owner scope; paginate only while the provider indicates more results and until 50 accounts are collected.
- If the primary-owner lookup returns zero accounts and the user explicitly requested account-team, territory, role, collaborator, or go-to-market-linked coverage, retry once with the selected ~~CRM app's supported filters and the same cap.
- If the broader retry times out or fails, continue with primary-owner results when present; otherwise ask for a watchlist or narrower owner scope.
- Keep Monitor to at most 50 accounts. If the resolved universe is larger, use upcoming external customer meetings in ~~Calendar over the next 14 days to reduce to at most 50; if that cannot reduce it, ask for a narrower scope instead of picking an arbitrary slice.
- Prefer exact name/domain matches and do not trust the top resolver result blindly when several plausible accounts remain.

### 3. Collect bounded recent evidence

- For each selected account, collect primary ~~CRM truth and user-provided context first. Use ~~Knowledge & Files for account plans or notes that explain the active workstream.
- For an explicit historical window, first derive the inclusive start and exclusive end from **this user's actual requested dates, as-of cutoff, and relevant timezone**; never reuse another request's dates. Apply those derived bounds **before every time-varying provider call**: CRM opportunity/account history, activity and modified-date queries, email, files, transcripts, internal messages, and calendar. Select the Salesforce history/activity object and actual date field appropriate to the requested signal, and constrain it server-side as `<history-date-field> >= <window-start> AND <history-date-field> < <exclusive-window-end>`; bound every Slack search with both `after:<day-before-window-start> before:<exclusive-window-end>`, an exact `on:<in-window-day>`, or the provider's exact timezone-aware equivalent. **Example only:** for June 16–July 16, 2026 in UTC, `CreatedDate >= 2026-06-16T00:00:00Z AND CreatedDate < 2026-07-17T00:00:00Z`, `after:2026-06-15 before:2026-07-17`, and `on:2026-07-13` are valid; compute different values for every other window or as-of time. Never fetch an unbounded denormalized timeline such as `Next_Step_History__c`, never issue an unbounded Slack/email/file search, and never retrieve out-of-window records for later filtering. A current Account/Opportunity lookup may return stable identity and requested-renewal fields only, not history blobs. If a provider cannot enforce the requested window or an exact in-window day, skip that retrieval and explicitly disclose the unavailable in-window evidence; locally filter only evidence the user has already supplied.
- A current or undated CRM Account or Opportunity record may identify the account and named renewal, but it is **identity context**, not evidence of a historical-period change. Do not present present-day fields, later Slack/email messages, or post-window CRM state as facts that changed during the requested period. Ground each claimed change in an in-window timestamped record; when historical CRM evidence is unavailable, state the gap instead of inferring the missing delta.
- For Adhoc, or when primary evidence is thin, deepen selectively in this order when relevant: ~~Email, ~~Knowledge & Files, ~~Meeting Transcripts, ~~Internal Messaging, then ~~Calendar.
- For Monitor, finish the bounded primary pass across the account set before deepening individual accounts. Deepen only accounts with a possible material delta, ambiguity, or high-value risk/opportunity.
- Parallelize only independent account lookups, with a practical cap of 10 at a time. Treat a batch timeout or schema error as a call-shape failure, not proof that the source is unavailable; retry failed accounts once by stable account id when available, then mark them unavailable and continue with surviving accounts.
- Stop when the recent story is supported. If a recency source was checked and found no match, say `checked/no match` when that absence materially affects confidence.

### 4. Normalize, score, and interpret signals

- Normalize evidence into the fixed taxonomy in `references/signal-taxonomy.md`; do not invent new signal labels unless the user explicitly extends the workflow.
- For every signal preserve type, summary, source, recency, confidence, evidence, citation, and suggested action.
- Deduplicate several sources describing the same event. Corroboration raises confidence; weak, stale, contradictory, or unsupported evidence lowers confidence and often becomes an Evidence gap.
- Distinguish actionable account risk from hygiene-only context such as ownership gaps, missing routing fields, or ambiguous associations; surface hygiene only when it affects monitoring confidence or the suggested action.
- For Adhoc, order signals by importance to the account story: risk/opportunity first, then dependencies, then supporting context.
- For Monitor, rank fresh, high-confidence, action-relevant change. Prioritize Churn or retention risk and Expansion opportunity; down-rank stale or speculative signals and compress accounts with no material delta.
- Give each ranked account an attention score of High, Medium, or Low and a directional posture of Expansion ready, Expansion blocked, Retention risk, or Execution risk.

### 5. Separate evidence from interpretation

- Put clickable source links close to the claims they support. For CRM, use connector-provided record URLs; construct a URL from an id only when trusted connector metadata exposes the instance base URL. Use plain source labels when no stable link exists and do not expose naked record ids as the primary action path.
- Keep raw evidence and strategic interpretation visibly separate. Every recommended action must trace to a signal or evidence item.
- If CRM and manual account truth are both unavailable, state that the recency anchor is unavailable and do not imply the result is current.

### 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:
- Deepen one account or close the smallest material evidence gap.
- Draft a concise internal account-team update grounded in the signals.
- Hand the selected account to deal strategy or meeting prep when the evidence points to an active motion or upcoming conversation.
- Check whether a matching daily or weekly automation already reruns this `analyze-account-signals` skill for the same monitor scope; if none exists, offer to create one that reruns the skill and flags which accounts need attention, why it matters, and the next best sales action.
- Draft CRM-ready updates for review when missing or stale fields are affecting confidence.

Next steps to avoid:
- Creating tasks, posting updates, or writing CRM changes automatically.

### Automation Offer Guard

For `Monitor Summary` outputs, a recurring seller account watch is the preferred next step when the user has provided a reusable scope such as a watchlist, owner, territory, or portfolio and the summary would benefit from daily or weekly refresh. Frame the value in sales language: catching pipeline movement, expansion signals, retention risk, stalled next steps, stakeholder changes, upcoming customer meetings, and account-team blockers before they get missed.

The automation must be a scheduled rerun of this skill, not a separate custom digest. When creating or describing the automation, make the prompt call this skill directly and preserve the same normalized request shape the skill accepts where possible:

```text
Use the Sales `analyze-account-signals` skill in `Monitor Summary` mode.
Rerun it for the same seller account scope: [watchlist, owner, territory, portfolio, or CRM filter].
Return the standard Monitor Summary output.

mode: "monitor"
owner_id: "[owner id when used]"
owner_email: "[owner email when used]"
watchlist_accounts: [same watchlist when used]
time_window: "[same or agreed recency window, default 14d]"
focus_areas: [same focus areas such as expansion, churn, rollout blockers, stakeholder movement]
output_style: "inbox_summary"
```

For territory or portfolio scopes that are not expressible as `owner_id`, `owner_email`, or `watchlist_accounts`, keep the stable scope in the plain-language prompt text and let this skill resolve the account universe using its normal Monitor Summary guidance.

The recurring output should follow this skill's `Monitor Summary` format: ranked accounts requiring attention, material deltas, run metadata, and no-major-delta handling. Keep it read-only; it may recommend next sales actions, but must not create tasks, post digests, store monitoring state outside the automation, or write CRM updates unless the user separately asks and approves.

Before offering a recurring monitor, check whether the user already has a matching local automation installed. Inspect local automation records under `$CODEX_HOME/automations/*/automation.toml`, or `~/.codex/automations/*/automation.toml` when `CODEX_HOME` is unset, and match by name, prompt, skill name, mode, account set, owner, territory, portfolio, or other stable scope details. Treat active and paused matches as already installed.

- If a matching automation exists, do not suggest creating another one. Continue with the next most relevant non-automation follow-up.
- If no matching automation exists, end with one clear offer to check/create a daily or weekly rerun of `analyze-account-signals` for the same scope. Describe the recurring output as a short seller-ready digest of accounts needing attention, why each matters commercially, and the recommended next action. Do not create or update the automation until the user explicitly agrees.
- If the automation surface is unavailable, do not mention tool details; offer to help set up a recurring check when automations are available.

## Modes

- `Adhoc Account Brief` — one account, default brief output.
- `Monitor Summary` — bounded watchlist/owner/portfolio view, default inbox-style output.

## Output Format

### Adhoc Account Brief

```md
# Account Snapshot

- **Account:** [Linked account when available]
- **Time Window:** [Window]
- **Current Posture:** [1-2 grounded lines]

## Key Recent Signals

- **[Plain-English signal label]** — [What changed] · [Fresh/Recent/Stale] · [High/Medium/Low confidence] · [Source link/label]

## Strategic Interpretation

- [What the signals likely mean for land, expand, retention, or execution risk; label inference]

## Recommended Actions

1. [Action] — [Evidence or signal link] — [Expected outcome]

## Open Questions / Missing Evidence

- [Unknown or gap] — [smallest follow-up evidence that would reduce uncertainty]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

### Monitor Summary

```md
# Ranked Accounts Requiring Attention

| Account | What Changed | Why It Matters | Attention | Posture | Suggested Action | Confidence / Evidence |
| --- | --- | --- | --- | --- | --- | --- |
| [Linked account] | [Delta] | [Impact] | [High/Medium/Low] | [Posture] | [Action] | [Link/label] |

## Material Deltas

| Date | Account | Signal | Status | Delta Summary | Impact | Next Step | Confidence |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [Date] | [Account] | [Label] | [New/Updated/Worsened/Resolved] | [Delta] | [Impact] | [Action] | [Confidence] |

## Run Metadata

- **Time Window:** [Window]
- **Data Freshness Cutoff:** [Cutoff or limitation]
- **Scope:** [Universe, checked count, ranked count]
- **Delta Since Last Run:** [Only when prior-run context exists]

## No Major Delta

[Include only when useful.]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

## Rules

- Do not fabricate accounts, owners, opportunities, metrics, signals, dates, links, or recommended actions.
- Do not use public web/news research, external enrichment, or task trackers unless the user explicitly extends the workflow and supplies a relevant source.
- Do not create tasks, posts, digests, CRM updates, or other writebacks in this workflow.
- Use plain-English display labels rather than raw taxonomy tokens in user-facing output.
- Rewrite unsupported claims as questions, risks, or evidence gaps rather than assertions.
- If a monitor run has no material delta, say so concisely instead of padding the ranking.

## Failure Handling

If account resolution fails, state what identifier is missing or ambiguous and ask for the smallest clarification. If optional sources fail, continue with the strongest grounded evidence and name material gaps. If Monitor scope cannot be safely reduced to 50 or fewer accounts, ask for a watchlist or narrower scope.

Referenced files: 3

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-like names as possible account anchors. When ~~CRM is available, resolve the account and matching opportunity before relying on indirect context.
- If the customer and workflow are both too weak for a stable hypothesis, ask only the smallest clarifying question.

### 2. Find the account-native anchor first

- Start with user-provided metrics, notes, links, or exports. Otherwise look for the highest-signal account-native artifact before broad search: exact-match ~~Knowledge & Files queries such as `[customer] business case`, `value case`, `ROI`, `pilot target`, or `expansion path`; then the matching ~~CRM opportunity; then relevant ~~Meeting Transcripts.
- Fetch the strongest anchor first. High-signal anchors contain the named customer, workflow, decision audience, commercial stakes, metrics, urgency, or caveats.
- Use adjacent sources only to validate material gaps such as workflow pain, approval path, budget ownership, timing, risks, or customer-facing follow-up.
- Preserve commercial anchors from account-native evidence, including pilot amount, expansion path, target value, budget range, close timing, and paid-pilot terms. If CRM is thin, keep the sourced fact and separately name the CRM gap.
  - Example: `Known from ~~Knowledge & Files source pack: SGD 420K pilot target and SGD 1.8M expansion path. Missing from ~~CRM: opportunity stage, owner, and close date.`
- Stop the first pass once the core case is supported; do not continue low-yield searches merely because more sources exist.
- For a named public company, run a focused public-primary pass unless the user disables it or the account-native anchor already answers the material why-now question. Use it to sharpen strategic priorities and executive wording, never to delay the first useful case or replace account-native proof.

### 3. Build the customer value logic

- Name the customer objective, business pressure, relevant buyer or team, constraints, and actual workflow before naming seller capabilities.
- Describe the workflow in business language: actors, steps, handoffs, bottlenecks, tools, KPIs, and what good looks like.
- Prioritize one to three use cases. For each, explain the workflow problem, why it matters now, who cares, supporting evidence, and remaining validation.
- Map each use case to the fewest applicable value buckets: `Enhanced Productivity`, `Cost Reduction`, `Risk Reduction`, `Revenue Acceleration`, and `Time to Market`.
- Make the causal chain explicit: workflow change -> operational effect -> business outcome -> metric.

### 4. Quantify only what the evidence supports

- Label material claims and inputs as `Known`, `Inferred`, `Assumed`, or `Missing`.
- Use this evidence order when sources conflict: customer-provided metrics; product telemetry or usage data; discovery or transcript evidence; ~~CRM, ~~Knowledge & Files, or internal account notes; public primary materials; analogous wins or directional benchmarks.
- For a finance-ready case, show formula, inputs, source/label, low/base/high scenarios, caveats, and confidence. Useful formula patterns include:
  - Productivity: `users x tasks per period x time saved per task x labor cost x adoption rate`
  - Cost: `current cost baseline - future cost baseline`
  - Risk: `incidents avoided x average cost per incident x confidence factor`
  - Revenue: `impacted revenue pool x improvement rate x confidence factor`
  - Time to Market: `cycle-time reduction x value of earlier release or deployment`
- If required inputs are missing, keep the math structural: show the formula, mark missing inputs, state what can be said directionally, and list the smallest questions that would make it finance-ready.

### 5. Draft the decision-useful package

- Translate operational impact into the customer’s business outcomes, then explain why the seller solution fits this workflow and buyer need.
- Keep public strategic context separate from account-native proof. Use analogous wins as support for a hypothesis, never as proof for this customer.
- Cite material claims with useful clickable links when available; use a plain source label only when no stable link exists.
- When the user requests a value-case document or deck, finish this business-case workflow before loading the matching authoring skill: use Google Slides for a native Slides deck, Presentations for PowerPoint, Google Docs for a native document, or Documents for Word. The explicitly requested artifact is the first deliverable, not an optional follow-up.
- Directly read the exact supplied template, existing file, workbook, and other named sources before composition. Preserve the template's actual masters, layouts, typography, branding, and placeholders; reuse or copy the specified template without modifying its original unless the user explicitly requests an in-place update.
- Carry grounded decision logic, customer evidence, formulas, missing inputs, caveats, and source links into the artifact. Create only the requested unshared output, verify its substantive finished content by readback, and return its real link; do not invent a template, file, source, ROI, or completed deliverable.

### 6. Build the Decision Deck

- For an explicitly requested customer ROI, commercial proposal, business-case, or decision deck, this selected business-case skill remains the seller-workflow owner. Read and follow [Sales Presentations](../sales-presentations/SKILL.md) as the downstream presentation partner before a substantive final response, gathering evidence, or invoking an artifact-authoring skill.
- If the user accepts a deck offer after the case is complete, read and follow [Sales Presentations](../sales-presentations/SKILL.md) at that point. Turn this exact case into the deck; do not restart as a generic product overview.
- After a substantive default or finance-ready case, prefer this as the single next-step offer unless the user has already requested another follow-up.
- Build an 8-12 slide decision deck: executive summary; what we heard; prioritized workflows/use cases; proposed solution; value model and assumptions; commercial structure; deployment, security, and governance; proof; recommended proposal structure; sources/open questions; and the decision requested. Combine or move sections to an appendix when evidence or audience warrants.
- Make the commercial choice legible: connect persona and workload to product surface, capacity or cost model, governance, and expected value. Keep unconfirmed pricing, ROI, eligibility, and terms visibly labeled.

### 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 case using the user's guidance or close the smallest material validation gap.
- Produce a customer-ready executive summary or value narrative for review.
- Produce a champion talk track or internal account-team note for review.
- Build a value-model table or spreadsheet-ready model structure.
- Turn the reviewed case into an 8-12 slide customer decision deck using `@presentations`.
- Turn the case into a concise meeting pre-read or decision document after the content is reviewed.

Next steps to avoid:
- Saving, sharing, posting, creating a document, or updating a system before the user reviews the content and explicitly requests that action.

### Mandatory Deck Offer

- End every successful non-deck output with this exact final line: `Would you like me to turn this into an 8–12 slide customer decision deck using @presentations?`
- Treat this as the one required next-step transition; do not append a competing menu or another offer after it.
- Skip it only when the user already requested or received the deck, explicitly declined slides, or the workflow is blocked before producing a usable case.

## Modes

- `Default Package` — the full business case below.
- `Structural Case` — use when the customer and workflow are clear but credible quantified inputs are missing.
- `Finance-Ready Case` — use when sourced inputs support formulas and low/base/high scenarios.
- `Focused Output` — use when the user asks only for an executive summary, ROI table, customer-ready narrative, differentiators, or validation questions; include a compact evidence posture and gaps.
- `Decision Deck` — use when the user explicitly requests or accepts a customer-facing commercial proposal or executive decision presentation.

## Output Format

Use this structure for the default package.

```md
# Business Case: [Customer / Initiative]

## Executive Summary
[Customer objective, why now, priority workflow/use cases, likely value story, seller fit, and confidence.]

## Strategic Initiatives
- [Known/Inferred/Assumed/Missing: initiative + source]

## Key Challenges
- [Customer or workflow challenge + evidence label/source]

## Priority Workflows
- **[Workflow]:** [Actors, bottleneck, KPI, and why it matters]

## Priority Use Cases
1. **[Use case]** — [Problem, buyer/team, why now, evidence, validation gap]

## Value Hypothesis by Use Case
| Use Case | Value Bucket | Causal Chain | Evidence Posture | Confidence |
| --- | --- | --- | --- | --- |
| [Use case] | [Exact bucket] | [Change -> effect -> outcome -> metric] | [Known/Inferred/Assumed/Missing] | [High/Medium/Low] |

## Metrics and Assumptions
| Metric / Input | Value | Label | Source | Why It Matters |
| --- | --- | --- | --- | --- |
| [Input] | [Value or Missing] | [Known/Inferred/Assumed/Missing] | [Link/label] | [Formula role] |

## ROI or Value View
| Use Case | Formula | Low | Base | High | Caveats |
| --- | --- | --- | --- | --- | --- |
| [Use case] | [Formula] | [Value/Structural] | [Value/Structural] | [Value/Structural] | [Gap/confidence] |

## Solution Differentiators
- [Differentiator tied to workflow, buyer need, and expected business effect]

## Proof Points or Analogous Wins
- **Account-native proof:** [Evidence or Missing]
- **Analogous / public support:** [Evidence, clearly not customer proof]

## Caveats and Open Questions
- [Most important validation gap and smallest next collection step]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

## Rules

- Do not invent customer numbers, buyers, workflow owners, tools, approvals, commercial terms, ROI, or source links.
- Do not turn public strategic language, benchmarks, or analogous wins into customer-confirmed impact.
- Do not hide missing data behind polished prose; say whether the case is structural or finance-ready and why.
- Prioritize one to three use cases and the fewest value buckets that explain the decision.
- Keep this workflow read-only unless the user explicitly requests a specific document or presentation; that request authorizes creating or updating only the requested artifact. Do not post, send, share, update CRM, modify the original template, or create unrelated files.

## Failure Handling

If no credible customer/workflow anchor exists, state the blocker and ask for the smallest missing input. If optional lanes are unavailable, continue with the strongest grounded evidence and make the resulting confidence limits visible.

Referenced files: 5

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 account context or ask the user to choose.
- Do not gather broad enrichment before the user confirms an inferred required anchor.

### 2. Gather evidence in authority order

Use this order unless the user specifies a narrower lane:

1. User-provided notes, decks, transcripts, prior briefs, and linked material
2. ~~Knowledge & Files competitive docs, battlecards, account plans, and positioning
3. ~~CRM for named account or deal truth
4. ~~Meeting Transcripts and ~~Internal Messaging when they materially change the talk track
5. Official public competitor and seller sources
6. Investor, regulatory, or other primary public materials
7. ~~Sales Intelligence and reputable secondary coverage for a specific remaining gap

- Do not let generic web research replace stronger user or internal material.
- Establish a seller baseline from seller-controlled sources when the seller is known: positioning, product lines, target segments, customer proof, recent launches, and comparison language.
- Validate claims about current positioning, launches, pricing, partnerships, and public proof with public primary sources.
- For competitor-only runs, seek multiple distinct evidence units when available. For account-scoped runs, add account evidence when the user supplied it or a connected source can fetch it narrowly.
- Treat internal field signals as directional unless corroborated by account evidence, maintained docs, or public proof.
- For each important source, extract a concrete evidence unit: what is claimed, what is confirmed, why buyers may care, how to counter or reframe, and what not to overclaim.
- Cite material claims with clickable links when available. If a lane is unavailable, stale, thin, or conflicting, say so and continue with the strongest remaining evidence.

### 3. Build dossiers before synthesis

For each in-scope competitor, capture the relevant available facts:

- profile, target market, and what they sell
- positioning and buyer appeal
- pricing or pricing talk track only when supported
- recent launches, releases, partnerships, or public proof
- where they win and where the seller can separate
- likely objections, discovery questions, talk tracks, and landmines

Do not collapse competitors into one generic story. Keep distinct evidence and uncertainty for each.

### 4. Add account context carefully

- When an account is named, use user-provided account notes first and ~~CRM for account and opportunity truth.
- Use ~~Knowledge & Files, ~~Meeting Transcripts, or ~~Internal Messaging selectively when they sharpen the live account implication.
- Do not let public research or generic field chatter invent account status, competitor presence, or deal posture.
- If there is no direct evidence that a competitor is active in the deal, label the account section Defensive prep.

### 5. Synthesize the seller response

- Default to brief; use objections, positioning, or account_overlay when the request calls for a narrower shape.
- Compare at most five competitors in one matrix unless the user explicitly asks for more.
- For 1-v-1, use Area | Seller | Competitor | Readout. For 1-v-many, use Area | Seller read | Status | Main pressure.
- Use statuses such as Lead, Pressure from [Competitor], Mixed, and Not determined; do not force a winner when evidence does not support one.
- Keep the tone factual and calm. Include what to say, what to clarify, proof to use, and what not to overclaim; avoid a feature bakeoff unless requested.
- The package should answer what each competitor is doing, where they are dangerous, why they win, why they lose, how to compete, and what the seller or strategist should say next.

Example 1-v-1 row:

| Area | MyCompany | Competitor Alpha | Readout |
| --- | --- | --- | --- |
| Deployment fit | Strong for governed enterprise rollout | Strong for fast team-level adoption | Mixed; clarify buyer governance needs |

Example 1-v-many row:

| Area | MyCompany read | Status | Main pressure |
| --- | --- | --- | --- |
| Buyer simplicity | Strong if the buyer values one accountable platform | Pressure from Competitor Beta | Competitor Beta may look simpler for a narrow departmental use case |

### 6. Create and verify the artifact

- When a native Google Slides competitive deck is requested, read and follow the Google Slides authoring skill before artifact creation; preserve this workflow's evidence contract and any exact template, respect source-discovery boundaries, and create only the requested fresh, unshared presentation instead of the default HTML.
- Default output: create a self-contained UTF-8 HTML brief with inline CSS and no external assets, then provide a concise chat summary. If the user explicitly asks for chat, plain text, or Markdown only, skip HTML and render the same substance in chat.
- Use a user-provided destination when supplied. Otherwise write a sanitized-seller-compintel-date.html file in the current workspace; use a safe temporary directory when a workspace file would be inappropriate. Ask before overwriting an existing user-visible file.
- Use a restrained, neutral, deck-inspired layout unless the user supplies brand conventions. Do not hardcode a company palette, logo, product name, or visual system.
- Include top-level sections or tabs: Overview, Competitors, Guidance, and Sources.
- Useful generic tooltip or card labels include Trigger, Discovery questions, Positioning, Verified signals, Where they win, Where the seller can separate, Why this works, Proof, Use when, and Landmine / do not say.
- Sources must show clickable provenance, evidence limitations, and which dependency categories were used, unavailable, or not relevant.
- Read the generated file back and verify the required sections, source provenance, and embedded styling are present. When a browser or Playwright-style renderer is available, render it once and fix blank pages, broken layout, unreadable contrast, or missing CSS before returning the link.
- Return the clickable artifact link first, followed by a short readout and a useful next-step offer. Do not narrate HTML mechanics in ordinary user-facing copy.

### 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:
- Add an account-specific overlay that separates confirmed deal evidence from defensive prep.
- Create an objections-only or positioning-only version for the immediate seller need.
- Prepare a meeting brief using the competitive risks and discovery questions.
- Draft a concise internal enablement or account-team update for review.
- Check whether a matching weekly automation already reruns this `build-competitive-brief` skill for the same competitor, product, category, or account scope; if none exists, offer to create one that gives the seller a reusable competitive digest.
- Close the smallest material competitive evidence gap.

Next steps to avoid:
- Sending, posting, or turning unsupported competitor claims into customer-facing assertions.

### Automation Offer Guard

For durable competitor, category, product, or account-specific competitive scopes, a weekly competitive digest is the preferred automation offer when the user would benefit from reusable field intelligence rather than a one-off battlecard. Frame the value in sales language: what changed in the competitive landscape, why buyers may care, where the seller can separate, what to say, what to clarify, and what not to overclaim.

The automation must be a scheduled rerun of this skill, not a separate custom research digest. When creating or describing the automation, make the prompt call this skill directly and preserve the same competitive scope and mode:

```text
Use the Sales `build-competitive-brief` skill.
Rerun it weekly for the same competitive scope: [competitor, product, workflow, category, segment, region, or account].
Return the standard competitive brief output, including source posture and landmines.

seller_company_name: "[seller company when known]"
product_scope: "[same product scope]"
workflow_scope: "[same workflow or buyer problem]"
competitor_scope: "[same competitor category or market category]"
competitor_names: [same named competitors when used]
account_name: "[same account when account-specific]"
mode: "[brief, objections, positioning, or account_overlay]"
known_objections: [same recurring objections when used]
```

For broad category or product scopes where named competitors are discovered by the skill, keep the stable scope in the plain-language prompt text and let this skill resolve likely competitors using its normal comparison-anchor guidance. Do not offer this automation for a narrow one-time objection, meeting-specific prep, or sparse evidence gap unless the user clearly wants a recurring competitive watch.

The recurring output should follow this skill's competitive brief contract: context, seller baseline, competitive landscape summary, competitor snapshots, comparison takeaways, response strategy, what not to overclaim, and sources. Keep it read-only; it may recommend talk tracks, discovery questions, proof, and internal updates for review, but must not post, send, share, or turn unsupported competitor claims into customer-facing assertions unless the user separately asks and approves.

Before offering the weekly competitive digest, check whether the user already has a matching local automation installed. Inspect local automation records under `$CODEX_HOME/automations/*/automation.toml`, or `~/.codex/automations/*/automation.toml` when `CODEX_HOME` is unset, and match by name, prompt, skill name, cadence, competitor, product, category, segment, account, mode, known objections, or other stable scope details. Treat active and paused matches as already installed.

- If a matching automation exists, do not suggest creating another one. Continue with the next most relevant non-automation follow-up.
- If no matching automation exists, end with one clear offer to check/create a weekly rerun of `build-competitive-brief` for the same scope. Describe the recurring output as a seller-ready competitive digest with what changed, why it matters, what to say, proof to use, and landmines to avoid. Do not create or update the automation until the user explicitly agrees.
- If the automation surface is unavailable, do not mention tool details; offer to help set up a recurring competitive digest when automations are available.

## Modes

- brief — default; canonical competitive brief, matrix, response guidance, and sources
- objections — buyer objections, proof points, discovery questions, talk tracks, and do-not-say guidance
- positioning — comparison framing, danger zones, differentiators, and response strategy
- account_overlay — account-specific implications, clearly separating confirmed deal evidence from defensive prep
- chat_or_markdown_only — same evidence contract without an HTML artifact, only when explicitly requested

## Output Format

For the HTML artifact and Markdown-only fallback, preserve this content contract:

```md
# [Seller] Competitive Brief

## Context
[Scope, buyer/account context, mode, and evidence posture]

## Seller Baseline
[Seller positioning and relevant proof]

## Competitive Landscape Summary
[What matters most and why]

## Competitor Snapshot
### [Competitor]
- **What they claim:** [Grounded claim]
- **What is confirmed:** [Evidence-backed fact]
- **Why buyers may care:** [Buyer appeal]
- **Where they win:** [Supported strength]
- **Where we can separate:** [Supported response]
- **Landmine / do not say:** [Overclaim to avoid]

## Comparison Matrix Takeaways
[Matrix plus the few implications that change seller behavior]

## Response Strategy
- **Say:** [Talk track]
- **Clarify:** [Discovery question]
- **Prove:** [Evidence]

## What Not To Overclaim
- [Uncertainty, conflict, or unsupported claim]

## Sources
- [Clickable source + what it supported]
- [Dependency category status and material gaps]

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

Add Account Implications for account_overlay, and label unsupported competitor presence as Defensive prep.

## Example Prompts

- `Build a competitive brief for MyCompany vs Competitor Alpha.`
- `Create a battlecard for MyCompany against Competitor Alpha and Competitor Beta in financial services.`
- `Compare MyCompany's enterprise workflow platform against the top three alternatives for regulated buyers.`
- `Build an account-specific defensive prep brief for ExampleCorp where Competitor Alpha may be in the deal.`
- `Create a shareable HTML competitive brief for MyCompany vs Competitor Alpha.`

## Rules

- Never fabricate competitor capabilities, pricing, customer proof, account posture, or source links.
- Keep facts, field signals, and inference visibly separate.
- If evidence is sparse, narrow the brief and name the smallest evidence gaps that would improve it.
- Do not post, send, share, or update systems from this workflow unless the user later explicitly requests a separate supported action.
- Always cite material source-backed claims with hyperlinks when useful links are available.

Referenced files: 4

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.

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.

```js
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](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](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](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](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](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](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](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](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/salesforce.md), [references/sources/gmail.md](references/sources/gmail.md), [references/sources/google-calendar.md](references/sources/google-calendar.md), [references/sources/granola.md](references/sources/granola.md), [references/sources/slack.md](references/sources/slack.md), [references/sources/google-drive.md](references/sources/google-drive.md), and [references/sources/gtm-resource-hub.md](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](scripts/render_demo_dashboard.py) from the seller [workspace template](assets/account-priority-workspace.template.html) and division-leader [command-center template](assets/sales-leadership-dashboard.template.html). 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:

```bash
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](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](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.

Referenced files: 33

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 needs it. Obtain explicit approval before any credit-consuming search, export, enrichment, or access to personal contact data. When explaining an unavailable provider or a credit-safe provider workflow, explicitly state in the final response: "Do not run any credit-consuming search, export, enrichment, or personal-contact access without the user's prior explicit approval."

## Workflow Guidance

These enrichment-specific steps modify the corresponding stages in the shared [Default Workflow](../../shared_skill_instructions.md#default-workflow). Continue the remaining default stages, including [Produce The First Output](../../shared_skill_instructions.md#3-produce-the-first-output) and [Offer One Next Step](../../shared_skill_instructions.md#4-offer-one-next-step).

- 1. Clarify and Gather Context
    - Resolve the smallest useful mode, entity scope, task shape, requested fields, ranking rule, and result limit.
    - If the anchor is ambiguous, make at most two narrow source calls to surface concrete candidates, then ask the user to choose before deeper enrichment. When two or three concrete modes, entities, or candidates are available, use [User Input](../../shared_skill_instructions.md#user-input); otherwise ask one narrow text question.
- 2. First Draft
    - Start from the user-defined working set or the canonical source for the request, then retrieve only evidence that materially improves the result.
    - Follow the selected connected Sales Intelligence provider's own installed plugin instructions before provider-specific search, enrichment, intent, similarity, or recovery; do not assume Sales includes a provider-specific skill.
    - For broad discovery, search before heavy enrichment and enrich only the final shortlist unless the user explicitly asks for exhaustive treatment.
    - Verify hard filters before calling a row qualified. Put close but unsupported candidates in Near Matches, Unclear, or Excluded.
    - Render the smallest useful table or shortlist, with field-level clickable source links, confidence, and visible gaps.

## Overall Rules

- Cite sourced claims with hyperlinks whenever links are available. If a source cannot provide a link, name the source and the limitation.
- CRM owns internal account truth; enrichment providers own provider-native external fields; user-provided records define the working set unless the user asks for discovery.
- Use Sales Intelligence for provider-native discovery, contact discovery, lookalikes, and signal scans; use CRM for existing customers, ownership, lifecycle stage, opportunity context, and named CRM lists; use Knowledge & Files for named ICP, territory, target-list, or segmentation rules that are not supplied.
- Do not use indirect or mirrored sources, broad web search, or Computer Use as substitutes for the authoritative category.
- Keep sourced facts separate from `Inference:`. Never invent emails, phones, titles, technologies, funding, hiring signals, intent, or missing fields.
- Do not claim exhaustive coverage from a bounded query or a user-supplied list. Filtering every supplied row may be complete **within that supplied list only**; it never establishes a complete market, territory, provider inventory, or all matching companies. When Sales Intelligence is unavailable, explicitly state that coverage is limited to the supplied companies and fields, and keep provider limits, weak matches, and missing lanes visible.
- Do not update CRM, execute outreach, create records, or send messages in this workflow. If the user wants a CRM change, prepare the proposed field updates and require explicit approval before a separate write action.

## Output Contract

Every mode must include a compact `## Sources & Coverage` section before proposed next steps:

- **Used:** [Linked source or source label] — [fields, rules, or signals it supplied]
- **Unavailable or limited:** [Material category or provider gap] — [impact on confidence or coverage]
- **Coverage:** [Exact supplied working set or query bound; explicitly state when market/provider coverage is not exhaustive]

### 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:
- Export the results to a spreadsheet with the visible evidence, confidence, and unresolved fields preserved.
- Prepare reviewed updates to the source of truth, such as CRM records, for missing or corrected fields.
- Verify near matches, ambiguous identities, or the smallest material coverage gap.
- Refine the filters, ICP rule, requested fields, or result limit using the user's guidance.
- Hand a qualified shortlist to account prioritization or company research when the user wants the next selling action.

Next steps to avoid:
- Executing outreach, silently broadening the working set, or updating CRM without explicit approval.

## Modes

### 1. Enrich Provided Records

- Use when the user supplies companies, contacts, domains, emails, rows, a CSV/export, or a CRM-backed list and wants missing fields completed or cleaned.
- Preserve the full supplied set, normalize obvious duplicates, and surface identity ambiguity instead of silently dropping or merging rows.
- Use CRM for customer/account truth when available, then enrich requested external fields.

#### Output Format

```md
# Enrichment Results

| Input Record | Resolved Entity | [Requested Field] | [Requested Field] | Confidence / Notes | Missing Or Unresolved |
| --- | --- | --- | --- | --- | --- |
| [Original input] | [Matched company/contact + source link] | [Grounded value + source link] | [Grounded value + source link] | [High/Medium/Low + reason] | [Gap or ambiguity] |

## Key Readout

- [Most useful pattern or implication]
- [Important source gap, duplicate, or weak match]
- [Recommended next check or action]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

### 2. Discover Companies Or Contacts

- Use when the user asks for new companies, contacts, likely buyers, decision makers, lookalikes, or ICP matches.
- Start from explicit search criteria or seed companies. Return only qualified matches as clean hits and keep near matches separate.
- For contacts, verify role, seniority, and company assignment before recommending a person.

#### Output Format

```md
# Qualified Matches

| Company / Contact | Why It Fits | Key Evidence | Confidence | Source |
| --- | --- | --- | --- | --- |
| [Entity] | [Hard criteria satisfied] | [Compact grounded evidence] | [High/Medium/Low] | [Clickable link] |

## Near Matches

- [Entity] — [Why it is close but not qualified]

## Gaps / Caveats

- [Coverage, provider, identity, or source limitation]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

### 3. Compare, Segment, Or Scan Signals

- Use when the user asks to compare a bounded set, score or tier a list, or find entities matching a defined external signal.
- Keep the visible comparison, tiering rule, or signal/proxy definition in the output so the user can inspect the judgment.
- Do not convert a weak proxy into a stronger claim.

#### Output Format

```md
# [Comparison / Segmentation / Signal Scan]

| Entity | [Comparison Field Or Tier] | Evidence / Signal | Confidence | Source | Notes |
| --- | --- | --- | --- | --- | --- |
| [Entity] | [Grounded value or visible tier] | [Observed signal or rationale] | [High/Medium/Low] | [Clickable link] | [Gap or caveat] |

## What Is Still Unclear

- [Missing field, unsupported ranking input, or next verification step]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

Referenced files: 1

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 Guidance

### 1. Resolve theme and evidence scope

- If the theme or transcript-like evidence scope isn't clear, ask the user via [User Input](../../shared_skill_instructions.md#user-input). For a bare invocation such as “Find customer quotes for me,” do not assume a theme or transcript set; offer:
  - `Use the most common blocker from recent Meeting Transcript evidence`
  - `Use a theme, objection, product area, or narrative I specify`
  - `Use a specific transcript or call set I provide`
- For a broad request such as “Find customer quotes about the most common blocker in my recent customer calls,” treat both the recommended theme and broad recent-call scope as a clarification case; offer:
  - `Use the blocker theme you recommend from recent Meeting Transcript evidence`
  - `Use a blocker theme I specify`
  - `Use a specific transcript or call set I provide`
  Do not search transcript evidence or draft a quote set until the user selects one.
- Require a feedback theme, objection, product area, use case, narrative, or a specific transcript set after that clarification. Preserve the user’s wording.
- Default to five quotes per theme. Process many themes in small batches.
- Normalize time windows: use explicit dates when supplied; treat “last month” as trailing 30 days unless the user says “last calendar month”; use calendar meaning for “last quarter” and trailing meaning for “last N days/weeks.”
- If a date phrase is too ambiguous to convert responsibly, ask one brief clarification unless the user clearly signals flexibility.
- For an ambiguous account, segment, or transcript set, make a bounded pass and offer up to three concrete candidates via [User Input](../../shared_skill_instructions.md#user-input). Do not search transcript evidence or draft a quote set until the user selects one. Use ~~CRM only to resolve filters; do not gather CRM content as quote evidence.
- If a recent call-follow-up, pasted transcript, upload, or linked call clearly supplies the theme and evidence source, proceed without asking.

### 2. Search transcript evidence first

- Start with ~~Meeting Transcripts when available, using the theme plus one or two intent terms such as `pain point`, `blocker`, `request`, `limitation`, or `need`.
- Apply company, segment, and date filters only when the user supplied or confirmed them. Start with 10-15 results and a relevance threshold around 0.7.
- If the selected ~~Meeting Transcripts source exposes an account-segment filter with a known enum, use the connector-visible value that matches the user's wording.
- Do not invent additional user intent. If the user asks only for a theme, keep the query theme-centric.
- If sparse, simplify the query, lower relevance modestly to about 0.6, then expand toward 20-40 results only when coverage still needs it.
- Fetch the top-ranked transcripts first and expand only until enough high-confidence, diverse evidence exists or the first pass is clearly thin.
- For pasted, uploaded, or exported material, parse only transcript-like text that preserves enough speaker/context evidence to classify customer or prospect likelihood.
- Keep a mapping of theme, search-result metadata, fetched transcript content, connector-specific refetch handle, and call or transcript URL when available. Do not assume a fixed transcript schema; inspect the fetched shape and adapt.

### 3. Extract verbatim candidates

- Keep only direct, substantial language that expresses a pain point, blocker, constraint, concern, unmet need, request, purchase condition, or other theme-relevant signal.
- Keep wording verbatim. Do not clean up grammar, join fragments, or convert paraphrases into quotes.
- Exclude paraphrases that are not direct quotes unless the user explicitly asks for paraphrases. If requested, label them separately and never present them as verbatim quotes.
- Exclude obvious internal seller statements, generic praise, garbled fragments, and tiny snippets without usable meaning.
- Preserve transcript, call, date, company, speaker label, participant context, and source link when available.

### 4. Verify speaker and rank precisely

- For each candidate, inspect nearby transcript context and assign `speaker_role_guess` as `customer`, `prospect`, `internal_seller`, or `unknown`; `customer_confidence` from 0.0-1.0; `theme_relevance` from 0.0-1.0; and a concise evidence note.
- Keep only candidates with `customer_confidence >= 0.8` and `theme_relevance >= 0.75` by default.
- If coverage is thin, prefer fewer quotes over lowering customer confidence. You may lower theme relevance slightly, to about 0.65, only when speaker evidence remains strong.
- Rank by customer confidence, theme relevance, diversity across calls/customers, specificity/actionability, then readability while remaining verbatim.
- If no candidate passes the customer threshold, report `0/[target]` customer/prospect quotes. Do not backfill the main quote set with unknown or internal speakers.

### 5. Deduplicate and select exemplars

- Normalize whitespace and punctuation for comparison only; never alter displayed quote text.
- Drop exact and near-duplicate quotes.
- Default to one quote per call. Use a second quote from the same call only when it adds materially different evidence or is needed to reach the target with strong quotes.
- Prefer breadth across customers when identity is available.
- Keep relevant non-customer transcript snippets only in a separate fallback section, labeled by role such as `internal evidence`, `vendor-eval evidence`, `partner-readiness evidence`, or `unknown non-customer evidence`.

### 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:
- Search an adjacent or narrower theme to improve evidence coverage.
- Expand or tighten the transcript, account, segment, or time-window scope.
- Package the selected quotes into a business case, competitive brief, meeting prep, or evidence appendix.
- Draft a source-safe internal summary of what the quotes support and what they do not support.
- Close the smallest speaker-identity or transcript-quality gap.

Next steps to avoid:
- Paraphrasing quotes, presenting ambiguous speakers as customers, or implying legal or compliance approval.

## Modes

- `Theme Quote Set` — default; grouped readable Markdown for one or more themes.
- `Specific Transcript` — extract from user-named or supplied calls only.
- `JSON` — use only when the user explicitly asks for machine-readable output or a downstream workflow requires it.

## Output Format

Use readable Markdown by default.

```md
# Customer Quotes

## [Theme]

**Coverage:** [returned]/[target] high-confidence customer/prospect quotes · [spread/quality note]

- “[Verbatim quote]”
  - **Speaker:** [Name or Unknown] · **Customer confidence:** [0.00] · **Theme relevance:** [0.00]
  - **Context:** [Company/call/date when known]
  - **Why it fits:** [Concise transcript-grounded evidence note]
  - **Source:** [Clickable transcript/call link, or no useful link available]

## Gaps

- [Theme with weak coverage, speaker ambiguity, transcript quality issue, or missing evidence]

## Internal / Non-Customer Evidence

- “[Verbatim fallback snippet]”
  - **Speaker / context:** [Known context] · **Role:** [non-customer classification] · **Customer confidence:** [0.00] · **Theme relevance:** [0.00]
  - **Usage note:** Useful for [internal purpose]; do not present as a customer quote.
  - **Source:** [Link/label]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

Omit empty optional sections. Include internal or non-customer quotation text only when the user explicitly requests fallback evidence; otherwise explain an external-speaker coverage gap without quoting non-customers.

Include compact Method Notes when search breadth, transcript formatting, repeated calls, or speaker-label quality lowered confidence. Keep each theme's coverage explicit even when the result is `0/[target]`.
Do not print `speaker_role_guess` in readable summaries unless the user explicitly asks for role metadata or a quote needs an ambiguity caveat.
Use clickable source links when available; otherwise say `no useful link available`.

## Example Prompts

- `Find customer quotes about a feedback theme.`
- `Find customer quotes about setup friction from recent enterprise calls.`
- `Pull prospect quotes about data residency from the last month of call notes.`
- `Find quotes that support the "faster account research" story from these transcripts.`

## Rules

- Do not fabricate or infer quote text, speaker names, titles, roles, companies, dates, transcript links, or call metadata.
- Do not treat every quote from a relevant call as relevant, or every relevant quote as customer-spoken.
- Do not treat missing speaker labels as high confidence unless surrounding context strongly establishes an external participant.
- Keep quotes verbatim and make provenance visible near each quote.
- Prefer precision, diversity, and honest gaps over a padded list.
- This workflow is not for exhaustive call analytics, exact speaker identity verification when transcripts lack evidence, or legal/compliance review.
- Keep this workflow read-only. Do not post, send, package, or save quotes unless the user explicitly asks in a later step.

## Failure Handling

If no transcript-like evidence is available, state that quote extraction cannot be grounded and ask for the smallest usable source. If transcript formatting is poor or speaker identity is ambiguous, return fewer quotes, name the limitation, and keep lower-confidence evidence out of the customer/prospect set.

Referenced files: 2

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, routing, or source-of-truth pages; use messages to confirm current practice or fill gaps.
- For doc_route, discover maintained docs through metadata only and preserve user-supplied result limits, document-type, title, and privacy filters on every query, including retries. Before reading content, require a topic-matched maintained authoritative source; reject generated follow-up packages, pre-reads, meeting summaries, one-off deliverables, and review or evaluation artifacts. If no trustworthy source remains, report the evidence gap instead of opening a generated document.
- For channel_route, start with public channel names, topics, purposes, and documented escalation routes; inspect recent public threads only when they change confidence.
- Use ~~CRM first for account identity and deal context when the route is customer-specific, then use ~~Knowledge & Files or ~~Internal Messaging for internal ownership.
- In quick, make one canonical source attempt, one narrow fallback when the first pass is empty, thin, or misleading, and at most one fetch or thread read per top candidate.
- Broaden only when the first pass is weak, the topic spans distinct surfaces, or the user asked for deep. Stop when a supported route is good enough, results stabilize, or additional searching produces low-confidence duplicates.

### 3. Build useful search facets

- Start with exact topic terms, then add aliases, abbreviations, legacy/current names, product/team names, and task-shape terms such as owner, approval, policy, runbook, playbook, FAQ, support, or escalation.
- For a compound question, keep separate tracks for the product/account surface and the control/process surface. Do not let a strong policy hit replace product routing, or a launch page replace approval ownership.
- Use [references/search-patterns.md](references/search-patterns.md) when query fan-out, source-specific search, or stopping rules need more detail.
- Use company-specific terminology only when it comes from the user or connector-visible source truth. Do not invent internal names, channel patterns, URLs, or ownership conventions.
- Apply organization-specific expansions only after generic candidate retrieval, keep base scoring primary, and cap the total context-based boost per candidate at `+0.25`.

### 4. Pull, score, and rank candidates

Normalize candidates by type, title or name, URL, source, evidence, ownership signal, and freshness. Deduplicate near-identical entries.

Rank by:

1. direct relevance to the requested answer route
2. authority and maintenance signal
3. freshness
4. cross-source confirmation
5. practical usefulness for the seller's next action

- Prefer direct evidence links over profile-only or mention-only matches.
- Prefer maintained source-of-truth pages, field guides, FAQs, and playbooks over one-off notes.
- Prefer channels whose topic, purpose, linked guide, or recent threads show an ownership path over channels that merely mention the topic.
- For people inferred mainly from ~~Internal Messaging, require a recent ownership or expertise signal, defaulting to the last 90 days; omit or down-rank stale candidates.
- Exclude deactivated or inactive users. Default to public channels only; include private channels, group DMs, direct messages, or externally shared channels only when the user explicitly asks and access is appropriate.
- Keep distinct routes when a topic spans product/GTM guidance and policy, security, implementation, pricing, or approval ownership.

### 5. Render the routing map

- Return only the depth the request needs. For a single route, keep the other required sections compact with Not searched in quick pass or No high-confidence candidate found.
- Explain each candidate's answer-path type: DRI, approver, SME, maintainer, accountable team, decision forum, launch owner, escalation channel, support channel, or feedback channel.
- Include a one-line rationale, direct link when available, evidence signal, and freshness or confidence when it affects trust.
- If the user's wording conflates two surfaces, add a short framing note explaining the split and continue with both routes unless the distinction changes which sources are safe to use.
- Recommended First Ask must be a concrete draft the seller can send to the best owner or public channel. Draft it in chat; do not post it.
- Coverage Gaps must name unavailable or weak categories, the effect on confidence, and the smallest useful next step.

### 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:
- Draft the first ask to the recommended owner, expert, or public channel.
- Open and synthesize the strongest source-of-truth document for the seller's question.
- Prepare a concise escalation note when the supported route requires escalation.
- Create a reusable routing note with the verified people, docs, channels, and caveats.
- Find the smallest missing source that would resolve an ownership or approval gap.

Next steps to avoid:
- Posting, assigning, escalating, or updating ownership automatically.

## Modes

- quick — default; up to three candidates each for experts, docs, and channels, with bounded retrieval
- deep — five to eight candidates each when evidence quality supports them
- owner_route, doc_route, channel_route, full_map — answer-shape routes; combine with quick or deep

## Output Format

```md
# Internal Routing Map: [Topic]

[Optional framing note when the topic spans distinct ownership surfaces.]

## Experts
- **[Name / team]** — [DRI / approver / SME / other type]; [why this route]. [Evidence link] · [confidence/freshness]

## Docs
- **[Doc]** — [source-of-truth / field guide / FAQ / other type]; [why it matters]. [Link] · [confidence/freshness]

## Channels
- **[#channel]** — [support / escalation / decision forum / other type]; [why ask here]. [Link] · [confidence/freshness]

## Recommended First Ask
> [Draft-ready question or handoff, addressed to the best owner or public channel.]

## Coverage Gaps
- [Missing or weak source, confidence impact, and smallest useful next step]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

## Example Prompts

- `Find the key internal sources for a customer question.`
- `Find who owns the Enterprise SSO rollout path for ExampleCorp.`
- `Find the docs and channels for answering a customer's security review question.`
- `Route this implementation blocker to the right internal people and source of truth.`

## Rules

- Do not fabricate owners, experts, channels, documents, source-of-truth paths, links, or ownership certainty.
- Keep facts and inference separate; label uncertain ownership Likely or Possible.
- Keep the routing-map phase read-only. Do not post, send, assign, or update anything.
- Prefer fewer high-confidence routes over long noisy lists.
- Always cite sources with hyperlinks when useful links are available; say (no useful link available) when the absence matters.

Referenced files: 3

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 [User Input](../../shared_skill_instructions.md#user-input). Do not retrieve deeper context or draft a package until the user selects one.
- When the call or account anchor is ambiguous, make at most three source reads to produce concrete candidates; do not gather broad enrichment before the user chooses.
- Treat ambiguous company-like names, partner names, and account shorthands as possible account anchors. When ~~CRM is available and account identity affects which call to retrieve, use a bounded ~~CRM lookup to disambiguate the account before relying on weaker account context; it never substitutes for grounded call evidence.
- If exactly one plausible grounded candidate remains, ask the user to confirm it via [User Input](../../shared_skill_instructions.md#user-input) before drafting. If no grounded evidence can be found, ask for the transcript, notes, or specific call rather than producing a recap from surrounding account context.
- Treat pasted notes, uploads, and user-linked material as valid working evidence; label them as user-provided when they cannot be verified.

### 2. Gather only useful enrichment

- Prefer grounded evidence in this order: ~~Meeting Transcripts transcript; retrievable meeting-recording transcript; other exported transcript; pasted transcript or grounded notes; ~~Knowledge & Files meeting notes; then an ~~Email thread or message as a recovery lane.
- Fetch a user-provided call or transcript handle directly. Otherwise search with the account plus date or timeframe and at most two meeting-topic terms, then fetch the best match.
- Preserve supplemental source-of-truth, call-notes, or transcript links alongside the primary evidence rather than replacing it.
- For an external account call, use ~~CRM when available to resolve the relevant account or opportunity and sharpen names, commercial context, and the one-sentence CRM next step.
- Check ~~Calendar for a related upcoming meeting when timing changes the next step. Use ~~Email, ~~Internal Messaging, and ~~Knowledge & Files only when they add promised actions, blockers, owners, links, or destination context.
- If the transcript explicitly names a meeting or file that could affect the follow-up, do one targeted lookup in ~~Calendar or ~~Knowledge & Files using the exact title and date when available. Include the link if found; otherwise say it was not found in that checked source/window rather than claiming no such meeting or file exists.
- Stop once the package is grounded and the highest-value account/timing context is covered; name missing enrichment instead of continuing broad searches.

### 3. Classify the call and extract commitments

- Decide whether the call is external customer/partner-facing or internal. External email copy and CRM text apply only to external calls.
- Extract decisions, commitments, asks, objections, blockers, owners, and dates. Use `Unknown` or `TBD` when the evidence does not establish them.
- If multiple CRM opportunities are plausible, choose the one matching the call topic, attendees, product, timing, and recent activity. If none is credible, keep the CRM sentence generic and append `(paste into the relevant opp)`.
- When opportunity intent, candidate ranking, or the safest internal channel is not obvious, use [references/opportunity-and-channel-selection.md](references/opportunity-and-channel-selection.md).

### 4. Deliver in the requested format

- Return the package in chat by default, even when an email or internal channel is available. When the user explicitly asks for a Google Doc, Word document, existing meeting note, or supplied template, deliver that requested artifact instead of substituting chat.
- Complete this focused follow-up workflow before invoking the matching document authoring skill. Directly inspect the exact supplied file or template, preserve its structure and branding, update an existing document only when requested, and otherwise create a fresh separate document.
- Preserve the grounded recap, action owners, decisions, commitments, dates, and source links in the document. Read back meaningful finished content before returning the actual document link; do not invent a file, link, source, or completed write.
- Do not create an email draft, send outreach, post an internal message, or write CRM in this workflow.
- Keep verbatim email and internal-message copy in Markdown block quotes so the seller can review and copy it.

### 5. Build the Customer Readout Deck

- For an explicitly requested completed-call discovery, pilot, evaluation, or customer-readout deck, this selected follow-up skill remains the seller-workflow owner. Read and follow [Sales Presentations](../sales-presentations/SKILL.md) as the downstream presentation partner before a substantive final response, gathering evidence, or invoking an artifact-authoring skill.
- For a substantive external call, when the user requests a deck or accepts the deck offer, read and follow [Sales Presentations](../sales-presentations/SKILL.md). Turn the grounded call package into a 6-10 slide customer readout; do not create this mode for a routine or internal call unless the user explicitly asks for an internal presentation.
- After a substantive evaluation, pilot, security, commercial, or deployment call, prefer this as the single next-step offer unless another requested action is clearly more useful.
- Cover: what we heard and agreed; requirements by theme; direct answers to commercial, security, integration, and rollout questions; open questions with owners; proposed evaluation or deployment plan; recommendation; and the next decision.
- Preserve the customer's wording and distinguish `Agreed`, `Proposed`, `Open`, and `Unverified`. Never turn seller follow-up intent into a customer commitment.

### 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:
- Refine the external email, internal recap, CRM sentence, or action list using the user's guidance.
- Create the reviewed email draft or post the reviewed internal recap when the user explicitly requests it.
- Add the reviewed recap and action items to an existing meeting note or create a new follow-up note.
- Prepare CRM-ready updates for review.
- Turn a substantive external evaluation call into a 6-10 slide customer readout deck using `@presentations`.
- Offer a scheduled follow-up only when the user requests ongoing follow-up or a full package contains a grounded future commitment, decision date, or meeting.

Next steps to avoid:
- Sending, posting, or updating CRM before the user reviews and explicitly requests the action.

### Mandatory Deck Offer

- End every successful non-deck output with this exact final line: `Would you like me to turn this into a 6–10 slide readout deck using @presentations?`
- Treat this as the one required next-step transition; do not append a competing menu or another offer after it.
- Skip it only when the user already requested or received the deck, explicitly declined slides, or the workflow is blocked before producing grounded follow-up material.

### Automation Offer Guard

Offer a follow-up automation only when the mandatory deck offer is skipped and the user requests a reminder, scheduled check, monitoring, or recurring follow-up, or when a full follow-up package contains a grounded future commitment, decision date, or next meeting. For a one-time recap, decision summary, action list, or focused draft, choose a relevant non-automation next step; do not inspect automation records or suggest recurring work merely because the source mentions a future date. When scheduling is useful, use the grounded timing anchor and frame the automation as a rerun of this skill for the same call/account and standard follow-up package.

Only after establishing that an automation is relevant, check whether a matching local automation already exists under `$CODEX_HOME/automations/*/automation.toml`, or `~/.codex/automations/*/automation.toml` when `CODEX_HOME` is unset. Match by prompt, skill name, account, meeting title, attendee, opportunity, trigger time, or other stable scope details. Treat active and paused matches as already installed.

- If a matching automation exists and the mandatory deck offer is skipped, offer to review or adjust it rather than creating another one.
- If no matching automation exists and the mandatory deck offer is skipped, end with one clear offer to create the automation, describing the output as a seller-ready follow-up package produced after the next call or at the agreed follow-up time. Do not create or update the automation until the user explicitly agrees.
- If the automation surface is unavailable, avoid tool details and simply offer to help set up a recurring or scheduled follow-up check when automations are available.

## Modes

### 1. Full Follow-Up Package

Default when the user asks to follow up after a call. Return every section below in order.

### 2. Focused Draft

Use when the user asks only for an email, internal recap, CRM note, or next-step extraction. Still ground it in call evidence; return the requested section plus a compact `Call Summary`, material gaps, and the status line.

### 3. Customer Readout Deck

Use only when explicitly requested or accepted for a substantive external evaluation, discovery, pilot, or deployment conversation. Follow the deck guidance above instead of the normal chat output format.

## Output Format

Use bold section labels, not top-level headings, for the normal package.

```md
**Call Summary**

- **Primary evidence:** [Clickable transcript/notes link or source label]
- **TL;DR:** [2-4 grounded bullets]
- **Context / Goal:** [Why the call happened]
- **Key Points:** [Important customer/internal signals]
- **Decisions / Commitments:** [What was agreed]
- **Risks / Blockers:** [What could slow follow-through]

**Next Steps**

**Customer**
- [ ] [Action] — [Owner or Unknown] — [Due date or TBD] — [Notes]

**Seller**
- [ ] [Action] — [Owner or Unknown] — [Due date or TBD] — [Notes]

**External Comms**

Subject options (recommended first):
1. [Subject]
2. [Subject]
3. [Subject]

Recommended subject: [Subject]

> Hi <FirstName>,
>
> [150-220 word grounded follow-up email]
>
> Best,
> [Seller]

Draft link: Not created; copy drafted in chat only.

**CRM Next Steps**

[Exactly one sentence with call date, seller action, customer action, and outcome/success criterion.]

**Internal Follow-Up**

Suggested destination: [Safe internal channel/link, or “No verified internal channel found”]

> **[Meeting title]**
>
> [One concise summary paragraph]
>
> **Attendees:** [Names or Unknown]
>
> **Key Notes**
> - [Grounded note]
>
> **Decisions**
> - [Decision or None confirmed]
>
> **Action Items**
> - [Action] — [Owner or TBD] — [Due date or TBD]
>
> **Open Questions / Risks**
> - [Question or risk]
>
> **Source**
> - [Clickable call-notes/transcript link, or no useful link available]

No email draft, Slack post, or CRM update was created.

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

## Output Rules

- Bias toward decisions, risks, next steps, buying process, procurement, technical blockers, and stakeholder movement.
- For an internal call, write exactly `Not applicable: this was an internal call.` under both `External Comms` and `CRM Next Steps`; do not draft external copy.
- Keep the external email concise, customer-safe, and free of sensitive internal language. Never invent recipients, commitments, pricing, dates, or draft links.
- Keep the CRM text to exactly one sentence. For an unresolved opportunity, append `(paste into the relevant opp)`.
- Suggest an internal destination only when it appears internal and relevant. If channel safety is unclear, say to verify before posting; never fabricate a channel URL.
- Before saying no verified internal destination exists, search ~~Internal Messaging once for the account, meeting title, or workstream when that source is available.
- Use useful clickable source links when available, and name source gaps that materially lower confidence.
- Default to one consolidated internal recap; split it into a top-level message plus thread only when the user asks or a verified channel norm requires it.
- Use native mentions for attendees and owners when the selected app supports them; otherwise use readable names.
- Keep the internal draft free of `##` headings. Its opening summary should name the launch path, business impact, decision point, or main follow-through theme without repeating the TL;DR.
- Keep the internal recap compact, de-duplicated, and team-facing; include owners or `TBD` rather than implying ownership.
- Always include the plain status line above after `Internal Follow-Up` unless the user explicitly asks for a different status format.

## Failure Handling

If the call cannot be grounded, state the blocker in one line, say what evidence is needed, and return only safe partial material such as candidate calls or a blank fill-in structure. If optional enrichment is unavailable, still produce the grounded package and label the missing lane.

Referenced files: 3

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 user requests it, the dataset mixes motions or products enough to make comparison noisy, or one grounded area is needed to find better exemplars. Choose one area or a small user-specified set from the user's wording or call evidence; never run placeholder-only product searches.
- If a required target, peer set, or supplied call-set anchor remains ambiguous after the user selects a lane, make at most three narrow source reads, offer up to three concrete candidates, and confirm any inferred anchor before gathering deeper evidence.
- If the user supplies transcripts, a clear target/peer/window for benchmarked feedback, or a clear target or call set plus a focused-coaching anchor, proceed without a setup detour.

### 2. Build a fair call sample

- Start with ~~Meeting Transcripts. Search by the rep's exact email or display name and convert relative windows to absolute dates before retrieval.
- Default to the trailing 30 days for the target and trailing 60 days for peers unless the user supplies a window; use the same user-specified window for both sides unless asked otherwise.
- Aim for at least 15 target calls and at least 15 peer calls total. Use about 15 per peer only when strict peer-by-peer benchmarking is requested.
- Keep the target and peer mix comparable by motion, segment, product focus, and topic when those dimensions are visible. Do not compare mostly discovery calls with mostly procurement calls without calling out the mismatch.
- Search summaries first. Use a few bounded query variations around the rep plus the requested motion or theme; lower thresholds or broaden the window only when it is likely to improve the sample.
- If the user provides a company or account, include it in the query text and any available structured filter; do not rely on structured filters alone.
- If targets are not met after a bounded pass, produce a limited feedback memo, state the shortfall, and name the next search that would improve confidence instead of padding the analysis.

### 3. Find peer exemplars and target moments

- Search for the moment, not just the meeting label: agenda control, discovery, value framing, objection handling, stakeholder mapping, pricing, security, procurement, next steps, or mutual action plan.
- Prefer peer moves repeated across multiple calls, or several strong moments in one clearly relevant call.
- Fetch only the calls needed to validate the pattern and show useful moments. For each fetched call, retain readable title/date/company context, motion, live link, connector-specific refetch handle for internal retrieval only, and three to eight observed moments.
- Tag evidence internally as Peer exemplar, Target strength, or Target opportunity.
- For each target opportunity, identify the exact moment, the peer move that fits it, and concrete language the rep could use next time.

### 4. Synthesize coaching without a scorecard

- Do not create a formal rubric, rating, ranking, or scorecard.
- Turn repeated peer behavior into a short best-practice list: what the peer does, why it works, one to three supporting peer examples, and a stealable line when the transcript supports one.
- Map those practices to specific target moments: “In this target call, when this happened, use this peer move; here is how it could sound.”
- Normally surface five to ten stealable peer moments and five to ten specific target upgrades; use fewer when the evidence does not support that many.
- Keep strengths visible alongside upgrades so the output is useful for coaching, not just critique.

### 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:
- Focus the coaching on one skill, motion, account, or call moment.
- Add a practical 30-day practice plan grounded in the observed opportunities.
- Draft a concise manager-to-rep or self-coaching note for review.
- Compare an additional bounded call set when it would improve confidence or find better exemplars.
- Turn the steal sheet into a reusable coaching document after review.

Next steps to avoid:
- Creating a scorecard, inferring performance or personality, or sending feedback automatically.

## Modes

- Benchmarked Feedback — default when target and peer evidence are available.
- Focused Coaching — use when the user names one theme, motion, account, or small call set.
- Limited Feedback — use when peer evidence, transcript depth, or comparable sample size is thin; clearly separate supported observations from coverage gaps.

## Output Format

Return these sections in order.

```md
# Call Feedback: [Target Rep]

## TL;DR

- [3-6 evidence-backed coaching takeaways]

## Dataset Coverage

- **Target calls reviewed:** [N; goal >=15]
- **Peer calls reviewed:** [N total; peers included; goal >=15]
- **Coverage window:** [Absolute target window] / [Absolute peer window]
- **Comparable mix:** [Motion, segment, product focus, or mismatch]
- **Confidence / limits:** [Shortfall, missing transcripts, or none material]

## Peer Exemplars: Stealable Moves

### [Behavior]

- **What they do:** [Observable move]
- **Why it works:** [Observable effect]
- **Examples:** [Readable call context + short excerpt + inline call link]
- **Stealable line:** “[Only transcript-supported language]”

## Target Rep: Specific Upgrade Opportunities

### [Upgrade]

- **Moment observed:** [Readable target call context + short excerpt + inline call link]
- **Peer exemplar move:** [Readable peer context + short excerpt + inline call link]
- **Apply it like this:** [Specific behavior and suggested language]

## Next-Call Steal Sheet

- [10-15 practical behaviors or example lines]

## Optional 30-Day Practice Plan

[Include only when requested.]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

## Example Prompts

- `Give feedback on a rep's calls.`
- `Give feedback on Jamie's last three discovery calls.`
- `Compare this rep's demo calls with strong peer examples and suggest coaching points.`
- `Review these transcripts for talk-listen balance, qualification, and next-step clarity.`

## Rules

- Ground every coaching claim in a call excerpt, transcript moment, or repeated observable pattern; never invent call content, outcomes, attendees, metrics, or deal context.
- Cite examples with readable title/date/company context and compact inline numbered Markdown links. Prefer live transcript or call URLs; never expose raw connector ids.
- Keep excerpts short, normally one to three lines and no more than 25 quoted words from one source.
- Use peer examples only when the call mix is reasonably comparable; state mismatches and lower confidence when it is not.
- If a useful call has no stable link, use readable context and say that no direct link was available.
- Keep recommendations behavior-based and immediately usable. Do not infer intent, personality, or performance from thin evidence.

## Failure Handling

If the target, peer set, or call evidence cannot be resolved, state the smallest missing input and offer concrete candidates when available. If evidence is sparse, return the limited memo with supported observations, explicit coverage gaps, and the next bounded search that would improve it.

Referenced files: 5

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 Orientation

For broad orientation requests such as “what can you do?”, “help me get started”, “what should I try?”, or “how do I use Sales?”, do not choose a focused workflow. Load [the canonical orientation response](references/orientation-response.md) and return its user-facing content as written. Treat that file as the canonical, updatable output surface for this branch. Offer the full skill catalog only when the user asks for it.

Referenced files: 2

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 sufficient first-sale anchor even without CRM, a named customer, pricing, a prior discovery call, or a confirmed security posture.
- **Deliver a substantive first-pass plan before requesting clarification or using `request_user_input`.** Include buyer discovery, pilot sequencing, conditional data-handling safeguards, practical staff-time mitigation, and concrete next sales actions; preserve the user's supplied pilot duration.
- State missing details as assumptions or unresolved questions. Ask optional follow-up questions only after the useful plan; never invent an existing opportunity, customer commitment, pricing, or approved security posture.

### 2. Resolve the deal anchor

- Start with the user-named account, opportunity, renewal, initiative, link, or notes.
- Accept `sfdc_account_id` as a legacy alias for `crm_account_id`.
- When available, use ~~CRM first to identify the account and the opportunity that best matches the named product, solution, renewal, stakeholders, timing, and recent activity.
- If the user asks for deal strategy but did not supply an account, opportunity, renewal, initiative, link, or notes, use ~~CRM first to search, rank, and offer up to three concrete current-opportunity candidates via [User Input](../../shared_skill_instructions.md#user-input). For a bare invocation such as “Plan the deal strategy for my most appropriate current opportunity,” do not assume a target; offer the connector-backed candidates and ask the user to choose before broad enrichment or drafting.
- Build a small alias set from the selected opportunity name, product or solution terms, activity titles, and user wording. Use it to validate related meetings, threads, and docs and reject same-account artifacts for a different deal motion.
- If multiple plausible deals remain, make at most three source reads to offer up to three concrete candidates via [User Input](../../shared_skill_instructions.md#user-input), then ask the user to choose before broad enrichment. If exactly one inferred candidate remains, ask the user to confirm it via [User Input](../../shared_skill_instructions.md#user-input) before broad enrichment or drafting.
- If CRM is unavailable but user-provided evidence is sufficient, continue with a clear CRM gap. Do not treat same-account evidence for another opportunity as proof for the selected motion.

### 3. Gather evidence by lane

- Use the selected account and deal-motion aliases to find relevant recent evidence in ~~Meeting Transcripts, ~~Email, ~~Internal Messaging, ~~Knowledge & Files, and ~~Calendar.
- Prefer the narrowest relevant window; default to the last 90 days unless the user provides another window.
- Do not require transcript, thread, or document links up front; use the selected account and deal-motion aliases to discover relevant artifacts.
- Read enough to support the current motion, stakeholder posture, procurement risks, and next actions. If the first same-account artifact belongs to another deal motion, continue to the next targeted result when available; otherwise skip it, label the gap, or ask the user to choose.
- Record each lane as available, unavailable, empty, stale, conflicting, or user-provided-only. Stop once the core strategy is supported; do not chase indirect substitutes for unavailable source truth.

### 4. Build the strategy

- Build a concise deal map: initiative, target outcome, motion/timeline, active workstreams, recent account or service context that materially changes deal execution when evidenced, blockers, and dependencies.
- Build the buying committee from evidenced people and roles. Use roles `economic_buyer`, `decision_maker`, `champion`, `influencer`, `blocker`, `procurement`, `legal`, `security`, or `unknown`; stance `supportive`, `neutral`, `skeptical`, `blocking`, or `unknown`; and influence `high`, `medium`, `low`, or `unknown`. Label inferred role, stance, or influence with `Inference:`.
- Build procurement risks with severity, likelihood, confidence, owner or suggested owner, mitigation, timing, and source. Load `references/risk-rubric.md` when classification or prioritization is ambiguous.
- Produce 5-7 high-signal actions by default. Each action needs an owner or suggested owner, due date or `TBD`, expected outcome, linked risk/stakeholder, and source.

### 5. Separate evidence from inference

- Cite useful source links inline when available; use plain source labels only when no stable link exists.
- Do not link meeting join URLs, generic room URLs, or opaque connector ids as evidence.
- If evidence conflicts, lower confidence and add an evidence gap instead of forcing a conclusion.
- Use exact dates and confirmed customer-side owners only when directly evidenced. Otherwise use relative timing, `TBD`, or `Suggested owner:`; avoid exact-day due dates when confidence is low or evidence is sparse.
- Use public or user-provided market context only when it sharpens a company or stakeholder hypothesis after the deal is anchored. Treat it as supporting context, never a hard dependency or override for account/deal truth.

### 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:
- Turn the prioritized actions into a mutual action plan or execution tracker.
- Prepare the next customer, partner, or internal meeting around the highest-risk decision.
- Draft stakeholder-specific email or Slack language for review.
- Draft CRM-ready opportunity updates for review.
- Deepen one blocker, stakeholder, or procurement risk where evidence is still thin.

Next steps to avoid:
- Sending messages, updating CRM, or creating downstream artifacts without a separate explicit request.

## Modes

- `Full Strategy Pack` — default; return every section below.
- `Deal Map Only` — return Deal Snapshot, Deal Map, Evidence Gaps, and Inference Notes.
- `Buying Committee Only` — return Deal Snapshot, Buying Committee Map, Evidence Gaps, and Inference Notes.
- `Procurement Risk Only` — return Deal Snapshot, Procurement Risk Register, Evidence Gaps, and Inference Notes.
- `Next Actions Only` — return Deal Snapshot, Prioritized Next Actions, Evidence Gaps, and Inference Notes.

## Output Format

For a full strategy pack, return sections in this exact order.

```md
# Deal Strategy: [Account / Opportunity]

## Deal Snapshot

- **Account:** [Name + source]
- **Opportunity:** [Name or Unknown]
- **Stage:** [CRM-backed value or Unknown]
- **Close Date:** [Evidenced date or Unknown]
- **Time Window:** [Window]
- **Run Mode:** [Mode]
- **Coverage Summary:** [Available, unavailable, empty, stale, or user-provided-only lanes]

## Deal Map

- **Initiative:** [Business initiative]
- **Target Outcome:** [Customer/business outcome]
- **Current Motion:** [Stage, timeline posture, and deal movement]
- **Active Workstreams:** [3-6 grounded bullets]
- **Top Blockers or Dependencies:** [Up to 5 grounded bullets]

## Buying Committee Map

| Stakeholder | Title | Org | Role | Stance | Influence | Last Signal | Confidence | Source |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Name] | [Title] | [Org] | [Role] | [Stance] | [Influence] | [Signal] | [High/Medium/Low] | [Link/label] |

## Procurement Risk Register

| Risk ID | Risk Summary | Risk Type | Severity | Likelihood | Owner or Suggested Owner | Mitigation | Target Date | Confidence | Source |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| R1 | [Risk] | [Type] | [High/Medium/Low] | [High/Medium/Low] | [Owner] | [Step] | [Date/TBD] | [High/Medium/Low] | [Link/label] |

## Prioritized Next Actions

1. **Action:** [Concrete action]
   - **Owner or Suggested Owner:** [Owner]
   - **Due:** [Date, relative timing, or TBD]
   - **Linked Risk IDs:** [IDs or None]
   - **Linked Stakeholders:** [Names or None]
   - **Expected Outcome:** [Outcome]
   - **Source:** [Link/label]

## Evidence Gaps

- **Gap:** [Material missing/conflicting evidence]
  - **Impact:** [How confidence or execution is affected]
  - **Smallest Next Collection Step:** [Most efficient way to close it]

## Inference Notes

- Inference: [Claim inferred rather than directly stated, with basis]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

## Rules

- Do not fabricate stakeholders, approvals, blockers, owners, commitments, amounts, stages, close dates, or exact dates.
- Keep facts and inference separate; omit empty inference notes rather than padding them.
- Prefer fewer strong actions over broad advice, and prioritize the risks most likely to block signature or slip timing.
- Use human-readable Title Case labels in normal output; use machine-readable keys only when the user asks for JSON or YAML.
- Keep this workflow read-only. Do not update CRM, send messages, post recaps, or create downstream artifacts unless the user explicitly asks in a later step.
- If evidence is sparse but the deal anchor is sufficient, produce a low-confidence pack with explicit gaps rather than stopping.

## Failure Handling

If no credible active-deal anchor exists, state the blocker, offer concrete candidates when available, and ask for the smallest missing input. If optional lanes are unavailable, continue with the strongest grounded evidence and make the resulting confidence limits visible.

Referenced files: 3

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 question. If meeting identity must be discovered and Calendar is unavailable, resolve its blocking dependency before any meeting-choice question: use the native install surface for the user-named or genuinely available provider. If installation is unavailable or declined, immediately follow [User Input](../../shared_skill_instructions.md#user-input): when `request_user_input` is available, offer two or three likely ways to identify the meeting, such as pasting the invitation, giving the customer/account, or naming an attendee; otherwise ask once in chat. Continue from the selected or supplied context and never repeat a declined installation offer.
    - When the user supplies an exact Calendar event ID or link, read that event directly; do not run a broad event search. If the direct read is unavailable, continue from the supplied invitation when sufficient and retain the unverified provenance label below.
    - PROVENANCE HARD REQUIREMENT: When the user supplied the meeting identity and no Calendar event was directly read, the final `**Meeting source:**` must begin with the exact words `User-supplied meeting identity; not Calendar-verified`. A matching email invitation only corroborates that user-supplied identity; cite it after the required label, never instead of it. When the Calendar event was directly read, cite it beside the date and omit the separate source line.
    - When the user asks for their next meeting and Calendar returns exactly one qualifying future customer event, select it directly and read the invite; do not ask the user to reconfirm an already unambiguous request. Ask the user to choose only when multiple credible candidates remain, the user supplied a conflicting candidate, or the selection would materially change the result.
    - When the user supplies an effective or as-of time, treat it as the strict evidence cutoff for email, messages, documents, and transcripts. Apply an instant-precise provider-side cutoff before fetching message bodies; for Gmail, use `before:<Unix epoch seconds>`, not a date-only `before:<date>`. Skip sources whose timestamps cannot be safely bounded.
    - Apply the same effective-time cutoff to CRM records before reading their contents: constrain Salesforce SOQL with `CreatedDate <= <as-of instant>` and `LastModifiedDate <= <as-of instant>`, or use a verified historical snapshot. If the exposed CRM action cannot apply the cutoff or no historical row remains, skip current CRM data and disclose the gap instead of consuming a record modified after the request time.
    - A future calendar invitation may identify the target meeting, but its recording, transcript, generated notes, summaries, and other artifacts created after the effective time are unavailable. Use earlier meetings or messages only when they predate that cutoff.
    - If another request leaves the mode unclear, ask the user via [User Input](../../shared_skill_instructions.md#user-input) rather than assuming upcoming-meeting prep.
    - If intent is "prep for an upcoming meeting" and the user did not supply a meeting, account, attendee, topic, or date, search and rank up to three candidates. Select a sole qualifying future meeting directly; use [User Input](../../shared_skill_instructions.md#user-input) only when multiple credible candidates remain. Do not retrieve deeper context or draft a brief until the target is unambiguous. All suggested events must be in the future relative to the user's current time.
        - This search should just be for the next 3 business days, with 25 max results, and no broad free-text query unless the user supplied an account, attendee, topic, or keyword
    - Resolve the account or workstream from the user request, invite, attendees, attendee domains, and nearby context. If CRM has multiple opportunities, use the one that matches the meeting topic, attendees, product, and recent activity; do not let an unrelated same-account opportunity drive the brief. If no credible anchor exists, state the gap instead of inventing one.
    - After the first draft, offer the most relevant follow-up from the Next Step Options below.

### Requested Meeting Documents And Decks

- For an explicitly requested customer-meeting deck, this selected meeting-preparation skill remains the seller-workflow owner. Read and follow [Sales Presentations](../sales-presentations/SKILL.md) as the downstream presentation partner before a substantive final response, gathering evidence, or invoking an artifact-authoring skill.
- When the user explicitly requests a meeting-prep document or deck, that artifact is the first deliverable, not a later optional next step. Apply this focused meeting-prep workflow before the matching document or presentation authoring skill.
- Directly inspect a supplied existing document, presentation, or template and preserve its actual sections, slide layouts, brand system, and placeholders; update that file only when requested, otherwise create a separate artifact without altering the original.
- Carry the verified meeting goal, attendees, account context, agenda, open questions, risks, decisions, next steps, and source links into the requested artifact. Verify substantive content by reading back the finished document or deck, then return its actual link; never substitute an unverified or invented file.

### Next Step Options

Use these as high-value transitions. Offer one clear transition, not a menu. Suggest ONLY these unless you are very confident another option is more useful:
- Install new connectors if they could materially improve output quality
- Improve or refine the brief based on the user's guidance.
- Add the prep to an existing meeting note or create a new meeting document as a pre-read. If needed and possible, offer to attach the document to the calendar invite. Be mindful of the broader audience when creating this prep doc; don't add your draft verbatim.
- Draft a concise Slack or email update for attendees, owners, or internal stakeholders.
- For a confirmed external meeting, turn the reviewed brief into a 6–9 slide customer presentation using `@presentations`.
- For `Daily Prep Digest` outputs, check whether a matching daily automation already reruns this `prepare-for-meeting` skill in that mode; if none exists, offer to create one that gives the seller a morning view of today's customer meetings, watchouts, and suggested closes.
- Set a heartbeat automation to follow-up with summary and action items after the meeting.

Next steps to avoid:
- Talk tracks or facilitation scripts

### Mandatory Deck Offer

- For a successful `Single Meeting Prep` output about an external customer, prospect, partner, renewal, or opportunity meeting, end with this exact final line: `Would you like me to turn this into a 6–9 slide customer presentation using @presentations?`
- For a successful `Daily Prep Digest` containing at least one qualifying external meeting, end with this exact final line: `Would you like me to turn one of these meeting briefs into a 6–9 slide customer presentation using @presentations?`
- This is the single required transition for qualifying outputs; do not append a competing automation or document offer.
- Skip the offer when the user already requested or received the deck, explicitly declined it, no external meeting qualifies, or the workflow is blocked.

### Automation Offer Guard

For `Daily Prep Digest` outputs where the mandatory deck offer does not apply, a daily meeting-prep brief is the preferred automation offer when the user benefits from starting each day with a seller-ready view of customer, prospect, partner, renewal, opportunity, or high-stakes internal meetings. Frame the value in sales language: knowing which meetings matter today, what account or deal context changed, where the watchouts are, and how to close each meeting toward a concrete next step.

The automation must be a scheduled rerun of this skill, not a separate custom calendar summary. When creating or describing the automation, make the prompt call this skill directly and preserve the same digest shape:

```text
Use the Sales `prepare-for-meeting` skill in `Daily Prep Digest` mode.
Rerun it daily for today's qualifying seller meetings in the user's timezone.
Return the standard Daily Prep Digest output with chronological meeting briefs and priority watchouts.

mode: "Daily Prep Digest"
date: "today"
meeting_scope: "customer, prospect, partner, renewal, opportunity, or high-stakes internal meetings"
```

The recurring output should follow this skill's `Daily Prep Digest` format: today's meetings, each meeting's goal, key context, watchout, suggested close, and cross-meeting priority watchouts. Keep it read-only; it may recommend preparation and follow-up actions, but must not create meeting notes, attach documents, send messages, post updates, or write CRM unless the user separately asks and approves.

Before offering the daily prep brief, check whether the user already has a matching local automation installed. Inspect local automation records under `$CODEX_HOME/automations/*/automation.toml`, or `~/.codex/automations/*/automation.toml` when `CODEX_HOME` is unset, and match by name, prompt, skill name, mode, cadence, meeting scope, or other stable scope details. Treat active and paused matches as already installed.

- If a matching automation exists, do not suggest creating another one. Continue with the next most relevant non-automation follow-up.
- If no matching automation exists and the mandatory deck offer does not apply, end with one clear offer to check/create a daily rerun of `prepare-for-meeting` for the Daily Prep Digest. Describe the recurring output as a morning seller brief for the meetings that need attention, why each matters commercially, and the recommended close or next step. Do not create or update the automation until the user explicitly agrees.
- If the automation surface is unavailable, do not mention tool details; offer to help set up a recurring meeting-prep brief when automations are available.

## Overall Rules
- When a material clarification has two or three highly likely answers, follow [User Input](../../shared_skill_instructions.md#user-input).
- Always cite sources using hyperlinks so users can click through to source docs
- Identify whether each material fact was user-supplied or directly retrieved. Claim that a source was checked, returned no results, or supports a specific link only when a completed source action in this conversation establishes that exact claim; tool discovery, an attempted call, and nearby unrelated results are not evidence.

## Modes
### 1. Single Meeting Prep

- Use when the user names one meeting, account, attendee, invite, or topic.
- You can pull in relevant information from other related meeting and context, but ensure that you make the link to the target meeting clear.
- Preserve Summary, Goal, Open questions, a duration-appropriate Proposed agenda, Recommended posture, and Confidence and gaps even in an executive-concise brief. When the supplied invitation is the only evidence, keep these sections brief and identify missing account history or CRM context without installing or querying an unnecessary provider.
- Keep the opening compact: meeting title, date/time, and sourced attendees. Include `**Meeting source:** User-supplied meeting identity; not Calendar-verified` only when no Calendar event was directly read. Keep that label even when a later email or message corroborates the invitation; corroboration does not replace user-supplied provenance or count as direct Calendar verification. Mention a material decline naturally in the attendee line; do not add separate Format, Accepted, or Declined fields.
- For a demo or walkthrough, include Recommended walkthrough spine: one customer-specific storyline in a Markdown blockquote, followed by a few sourced proof points explaining why it matters. Omit this section for other meetings. Include People to lean on only when evidence supports the named attendees' roles or contributions; do not infer roles from attendance alone. Weave useful background into these sections and the Summary rather than adding a generic Background Context section.
- Use sentence-case headings and a readable numbered agenda. Adapt the heading, timing, and stage count to the actual invite; for a 30-minute meeting, prefer about five well-spaced stages with a bold time range and outcome, then a compact explanation on the following line. Tailor the stages to the meeting, not necessarily a demo. If the duration is unknown, label any suggested duration as a proposal.

#### Output Format

```md
# [Meeting name]

**Date:** [Date/time, with a link to the directly read Calendar event when available]
**Attendees:** [Compact sourced names/roles; mention a material decline naturally]

## Summary

- [Core meeting objective]
- [Current account, opportunity, or workstream signal]
- [Top implication, risk, or source gap]

## Goal

- [Concrete decision, alignment, feedback, commitment, or next step]

## Recommended walkthrough spine

> [One customer-specific storyline connecting the demonstrated workflow to the outcome the customer needs.]

- [Sourced customer priority or workstream signal that makes this story relevant]
- [Sourced proof point, constraint, or prior commitment the walkthrough should address]

## Open questions

- [Most important unresolved question]
- [Question tied to invite, CRM, notes, or message context]
- [Decision or clarification needed]

## Proposed 30-minute agenda

1. **0–3 min — Define the outcome**
   [Confirm the customer decision or result this meeting should enable.]

2. **3–8 min — Align on the starting point**
   [Check the relevant customer context, constraints, and success criteria.]

3. **8–18 min — Work through the core scenario**
   [Use the customer-specific storyline or main decision topic.]

4. **18–25 min — Resolve open questions**
   [Test the risks, objections, or tradeoffs that could change the decision.]

5. **25–30 min — Agree on the next step**
   [Confirm the decision, owner, and next commitment.]

## People to lean on

- **[Person]:** [Sourced role/contribution and a concrete question or ask]

## Recommended posture

[Decision-oriented commercial stance; distinguish recommendations from customer commitments.]

## Confidence and gaps

[Source-quality limits, conflicting or missing evidence, and what would materially improve confidence. Follow [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements) here without adding a duplicate section.]

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

### 3. Customer Presentation

- Use deliberately, only when the user requests a deck or accepts the mandatory deck offer.
- Build for one confirmed external meeting, not an undifferentiated daily meeting set. Good fits include first calls, EBCs, and executive workshops.
- Read and follow [Sales Presentations](../sales-presentations/SKILL.md). Convert the reviewed meeting brief into a 6–9 slide customer-safe narrative using `@presentations`.
- Recommended flow: customer-specific point of view and meeting objective; relevant business priorities; two or three tailored workflows; architecture or operating-model diagram when useful; proof and customer examples; discussion questions; proposed next step.
- Keep unresolved questions visible rather than presenting assumptions as customer facts.

### 2. Daily Prep Digest

Use when the user asks for today’s, tomorrow’s, or another date-based meeting summary.

Start from calendar, apply the shared selection rules, keep qualifying meetings, and order them chronologically. Keep separate briefs for separate meetings.

### Output Format

```md
## Today's Meetings

### [Time] — [Meeting Name]

**Attendees:** [Names + roles]

- **Goal:** [What to accomplish]
- **Key context:** [Relevant account, deal, project, or workstream signal]
- **Watchout:** [Risk, blocker, dependency, or source gap]
- **Suggested close:** [Next step, owner, commitment, or decision]

## Priority Watchouts

- [Most important cross-meeting risk]
- [Meeting needing special preparation]
- [Missing context or follow-up needed before meetings]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

Referenced files: 1

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 interpret company-specific forecast categories, stage gates, or Commit/Upside norms beyond source-backed thread context, ~~CRM metadata, manager notes or RevOps docs from ~~Knowledge & Files, or user-provided guidance.
- If scope is ambiguous, make a bounded candidate pass before asking: at most three source reads, only enough to offer up to three concrete choices.
- Use owner scope only after the user explicitly selects or confirms it. When the user names accounts or opportunities, intentionally bypass owner-book scope; when the user names a report, team, or pipeline view, use that narrower scope and state it.
- Prefer the canonical ~~CRM report or filter for a named team, segment, book, or pipeline view and state the exact filter. For example, if a Startups forecast is represented by `Sales_Coverage_Opp__c = 'Startups'`, use that first instead of broadening across owner, account, and stamped-segment fields. Broaden only when the user asks, the canonical definition is known to be incomplete, or it returns an implausibly thin result; label the broader filter and do not compare it as if it were canonical.

### 2. Build the forecast truth set

- Start with the canonical ~~CRM report/filter or supplied export. State the exact scope, period, source, amount basis, and data freshness in the output.
- For live ~~CRM, do only the minimum field or schema discovery needed to identify scope, amount, forecast, stage, owner, close-date, next-step, activity, and risk fields. Skip current-user and account-object discovery unless the scope is “my book” or account-level fields are needed.
- For a normal first pass, gather current open deals in scope and build the rollup first, normally by forecast category and optionally stage: deal count, primary amount, and expected forecast amount.
- Inspect detail rows only for the highest-value, highest-risk, stale, materially changed, or concentration-driving opportunities.
- Gather prior-snapshot rows only when the user supplies a comparison snapshot, a named snapshot/report is available, or the user explicitly asks for movement. Do not use broad field history to imply true forecast movement.
- If current-versus-prior coverage is partial, label that directly.
- Treat OpportunityHistory or similar field history as field history, not forecast-snapshot movement, unless a true prior snapshot exists.
- If data is too thin for category recommendations, downgrade to a risk-only readout and say why.

### 3. Add bounded evidence only where it changes the call

- Default to `light` enrichment for the top one to three uncertain or material deals after the rollup exists. Use `none` when the user asks for forecast-data-only review; use `standard` only for a requested deep review or when missing supporting evidence would materially change a high-value recommendation.
- Use ~~Meeting Transcripts and ~~Email for recent customer engagement, urgency, stakeholder, objection, decision-process, and timing signals.
- Use ~~Internal Messaging and ~~Knowledge & Files for blockers, approvals, close-plan gaps, legal/procurement risk, or manager context.
- Do not enrich every deal by default. Stop when the top recommendations are supported; name missing lanes that would materially change confidence.
- Do not broaden enrichment while a required scope anchor or forecast convention is unresolved; resolve or confirm it first.
- Do not let supporting lanes override CRM-owned amount, stage, forecast category, owner, close date, or opportunity state.

### 4. Evaluate risk and recommendation posture

- Evaluate material deals for next-step clarity, timing credibility, stakeholder coverage, decision-process visibility, proof of urgency, recent engagement, and data freshness.
- Flag supported hygiene signals such as missing next steps, stale activity, unclear close dates, weak stakeholder coverage, and category/amount/stage changes.
- Flag portfolio concentration when too much posture depends on one deal, owner, stage, segment, product, or timing bucket.
- Use simple `low`, `moderate`, and `high` risk labels. Separate sourced facts from directional inference.
- Recommend keep, downgrade, upside, or follow-up-check posture only when evidence supports it. Phrase unsupported changes as questions or `Needs confirmation`.
- When current and prior snapshots are supplied, add a concise `What Changed` subsection. Without a prior snapshot, say true movement was not evaluated and use current-state examples only when supported, such as booked Closed Won, Commit concentration, stale close dates, missing next steps, or large Closed Lost/churn rows.

### 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:
- Inspect one high-risk or concentration-driving deal more deeply.
- Draft a concise manager or forecast-call summary for review.
- Create a spreadsheet-ready rollup or risk follow-up structure.
- Draft CRM-ready corrections or next-step text for review.
- Check whether a matching weekly automation already reruns this `review-forecast` skill for the same scope and forecast convention; if none exists, offer to create one that gives the seller or manager a weekly forecast-risk readout.

Next steps to avoid:
- Automatically changing forecast categories, close dates, amounts, or CRM records.

### Automation Offer Guard

For current forecast, movement, or risk-review outputs, a weekly forecast-risk brief is the preferred automation offer when the user has a reusable owner book, team, report, pipeline view, period, or deal set plus stable forecast conventions. Frame the value in sales language: spotting commit risk, upside movement, stale next steps, close-date pressure, concentration, and deals that need manager attention before the forecast call.

The automation must be a scheduled rerun of this skill, not a separate custom pipeline summary. When creating or describing the automation, make the prompt call this skill directly and preserve the same forecast scope and conventions:

```text
Use the Sales `review-forecast` skill.
Rerun it weekly for the same forecast scope and convention.
Return the standard Forecast Review output.

owner_name: "[owner name when used]"
owner_email: "[owner email when used]"
focus_accounts: [same focused accounts when used]
focus_opportunities: [same focused opportunities when used]
forecast_period: "[same period or rolling current period]"
forecast_posture_standard: "[defend_commit, identify_upside, or conservative_manager_ready]"
forecast_category_convention: "[same sourced or user-confirmed convention]"
amount_basis: "[carr_arr, acv, tcv, weighted_amount, or crm_primary_amount]"
enrichment_mode: "[none, light, or standard]"
```

For team, report, or pipeline-view scopes that are not expressible as owner, account, or opportunity fields, keep the stable scope in the plain-language prompt text and let this skill resolve the forecast truth set using its normal workflow guidance.

The recurring output should follow this skill's Forecast Review format: review scope, overall forecast posture, key movements, highest-risk deals, recommendation changes, evidence gaps, and follow-up actions. Keep it read-only; it may recommend checks, corrections, or CRM-ready text for review, but must not change forecast categories, close dates, amounts, CRM records, tasks, or messages unless the user separately asks and approves.

Before offering the weekly forecast brief, check whether the user already has a matching local automation installed. Inspect local automation records under `$CODEX_HOME/automations/*/automation.toml`, or `~/.codex/automations/*/automation.toml` when `CODEX_HOME` is unset, and match by name, prompt, skill name, cadence, owner book, team, report, pipeline view, forecast period, amount basis, category convention, or other stable scope details. Treat active and paused matches as already installed.

- If a matching automation exists, do not suggest creating another one. Continue with the next most relevant non-automation follow-up.
- If no matching automation exists, end with one clear offer to check/create a weekly rerun of `review-forecast` for the same scope. Describe the recurring output as a manager-ready weekly forecast brief covering risk, upside, stale next steps, concentration, and recommended checks. Do not create or update the automation until the user explicitly agrees.
- If the automation surface is unavailable, do not mention tool details; offer to help set up a recurring forecast-risk brief when automations are available.

## Modes

- `Current Forecast Review` — default; current rollup, top risks, recommendations, and actions.
- `Movement Review` — use when a prior snapshot or explicit comparison source exists; add true movement.
- `Risk-Only Review` — use when forecast truth is sufficient for risk but too thin for posture changes.
- `Focused Deal Review` — use for named accounts or opportunities instead of a full book.

## Output Format

Return these sections in order.

```md
# Forecast Review: [Scope]

## Review Scope

- **Scope:** [Owner, team, report, period, or deal set]
- **Forecast truth:** [Live CRM, export, pasted data, or linked source]
- **Amount basis:** [CARR/ARR, ACV, TCV, weighted amount, or CRM primary amount]
- **Category convention:** [Sourced convention or user-confirmed interpretation]
- **Data freshness:** [Date/time or limitation]

## Overall Forecast Posture

[Manager-ready posture summary]

| Forecast Category | Deal Count | Primary Amount | Expected Amount | Confidence |
| --- | ---: | ---: | ---: | --- |
| [Category] | [Count] | [Amount] | [Amount] | [High/Medium/Low] |

## Key Movements

- [True movement backed by a prior snapshot, or “True movement not evaluated; no prior snapshot was available.”]

## Highest-Risk Deals

| Deal | Amount | Current Posture | Risk | Why | Recommended Check or Change | Source |
| --- | ---: | --- | --- | --- | --- | --- |
| [Deal] | [Amount] | [Category] | [Low/Moderate/High] | [Evidence] | [Action or posture] | [Link/label] |

## Recommendation Changes

- **[Deal]:** [Keep / Downgrade / Upside / Needs confirmation] — [grounded reason and confidence]

## Evidence Gaps

- [Gap] — [impact on confidence] — [smallest next collection step]

## Follow-Up Actions

1. [Action] — [Owner or suggested owner] — [Due or TBD] — [Expected outcome] — [Source]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

## Rules

- Do not fabricate opportunities, amounts, stages, close dates, owners, forecast categories, customer engagement, movements, or links.
- Explain whether the review used live CRM truth, exported/report data, pasted pipeline data, or another user-provided source.
- Include true movement only with a prior snapshot or explicit comparison source; otherwise keep `Key Movements` and state the limitation.
- Label uncertain recommendations `Likely`, `Possible`, or `Needs confirmation`; avoid false precision.
- Keep the initial review read-only. Draft downstream manager notes, CRM-ready text, spreadsheet structure, or risk follow-up only when requested; never write or send without a separate explicit approval step.

## Failure Handling

If scope or forecast truth cannot be resolved, state the blocker, offer concrete candidates when available, and ask for the smallest missing source or convention. If optional evidence is unavailable, continue from the forecast truth set and make the confidence limit visible.

Referenced files: 2

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.
- If the target remains ambiguous after the user selects a lane, make at most three narrow source reads, offer up to three concrete candidates, and confirm any inferred anchor before deeper analysis.

### 2. Collect summaries across time

- Start with ~~Meeting Transcripts and search each time slice separately. Use the rep's exact email or display name, a limit of about 25 per slice, and `score_threshold=0` when supported—or the lowest practical threshold—so the sample is not biased toward only “strong” calls.
- When the user names a focus such as discovery, demo, renewal, objections, or technical troubleshooting, use a short matching query. Otherwise use an empty or neutral query to avoid biasing the sample.
- Aim for 30-60 deduplicated calls when available, with a mix of call types and companies visible in summaries. If a slice is sparse, expand it once by about 30 days and state the adjustment.
- If there are hundreds of calls, prioritize the most recent calls plus a smaller older baseline while preserving visible call-type and company variety.
- Build the trend view from summaries first: date, company, title, topics, call link, and the retrieval handle kept only for fetching.
- Do not claim improvement or regression from a single recent call or from outcomes alone.

### 3. Compare supported behavior categories

- Compare the same categories across older and newer slices whenever possible.
- Use the core categories: opening/agenda, discovery depth, qualification/prioritization, positioning/narrative, objection handling, next steps and mutual action plan, technical accuracy, clarity/concision, executive presence, and listening/turn-taking.
- When the calls are technical or solution-oriented, use the rubric's additional categories for problem framing, diagnosis/troubleshooting, solution design/tradeoffs, and technical-plus-business stakeholder management.
- Prefer three to six categories with the clearest evidence. Mark mixed evidence as Inconsistent rather than forcing a trend.
- Call something Improved or Regressed only when the time comparison supports a directional shift. Use Stable for repeated patterns without clear movement.

### 4. Fetch a small validation set

- Fetch full context only where summaries are ambiguous, a trend needs validation, or a concrete coaching moment would help.
- Normally inspect one to two strong recent calls, one to two recent calls with friction, and one to two older baseline calls.
- Capture two to six brief moments: what happened, why it mattered, category, readable title/date/company context, and live link.
- Keep quotes short and use the full content to validate—not replace—the summary-level sample.

### 5. Turn trends into action

- Tie each improvement, regression, and stable pattern to evidence from the compared slices.
- Recommend exactly three coaching actions for the next two weeks. Each action needs a skill to practice, an if/then play, a five-to-ten-minute drill, and an observable check for the next calls.
- Select three to eight calls to re-listen to, favoring the clearest recent and baseline examples that explain the coaching priorities.

### 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:
- Drill into one improved, regressed, or inconsistent behavior category.
- Turn the top three actions into a two-week practice plan or coaching note for review.
- Compare a bounded peer-exemplar set for one coaching priority.
- Select and summarize the most useful calls to re-listen to.
- Set up a future trend refresh for the same rep, scope, and comparison basis.

Next steps to avoid:
- Making performance judgments from thin evidence or sending feedback automatically.

## Modes

- Trend Review — default trailing-window analysis.
- Focused Trend Review — use for a named motion, category, account set, or supplied older/newer calls.
- Limited Trend Readout — use when one slice, transcript depth, or sample balance is insufficient for confident movement claims.

## Output Format

Return these sections in order.

```md
# Rep Call Trends: [Target Rep]

## Coverage

- **Target rep:** [Name]
- **Window analyzed:** [Absolute start] -> [Absolute end]
- **Time slices:** [Older / middle / recent absolute ranges]
- **Calls reviewed:** [N summaries], [M full fetches]
- **Sample shape / limits:** [Mix, sparse slice, or confidence note]

## What Improved

- **[Behavior change]** — [Evidence from older vs newer readable call context + inline links] — [Why it matters]

## What Regressed / Risk Signals

- **[Behavior change]** — [Evidence from older vs newer readable call context + inline links] — [Why it matters]

## What Stayed Consistent

- **[Stable or inconsistent pattern]** — [Evidence + inline links]

## Top 3 Coaching Actions: Next 2 Weeks

1. **Practice:** [Skill]
   - **If / then:** [In-the-moment play]
   - **Quick drill:** [5-10 minute drill]
   - **Look for next:** [Observable signal]

## Calls to Re-Listen

- [Readable date, company, title + inline link] — [Why this call matters]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

## Example Prompts

- `Review a rep's call trends.`
- `Review Jamie's call trends over the last month.`
- `Compare this rep's recent discovery calls to their earlier calls and flag changes.`
- `Find improvement and regression patterns across this rep's demo calls.`

## Rules

- Do not invent calls, behavior, outcomes, metrics, quotes, dates, companies, or links.
- Every improvement or regression claim must compare older and newer evidence and cite at least one readable call link; do not turn anecdote into trend.
- Prefer explicit structure, questions, summaries, objections, and next steps over speculative interpretation. Do not infer intent or personality.
- Cite with readable title/date/company context and compact inline numbered Markdown links, such as `2026-03-24, ExampleCorp, Pilot & Pricing [1](https://example.com/call/123)`. Prefer live transcript or call URLs; never expose raw connector ids.
- When one statement is supported by multiple calls, append multiple numbered links inline.
- Keep excerpts short, normally no more than 25 quoted words from one source.
- If a useful call has no stable link, use readable context and say that no direct link was available.

## Failure Handling

If the target or comparison basis cannot be resolved, state the smallest missing input and offer concrete candidates when available. If the sample is sparse or uneven, produce the limited readout, name which movement claims are unsupported, and suggest the smallest additional call set or window that would improve confidence.

Referenced files: 3

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 Outreach
> [Draft-only message]

No message was sent and no CRM record was changed.

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}
```

## Rules

- Cite material sourced claims with useful links when available.
- Label inference clearly; do not invent company facts, partner terms, contacts, reputation claims, or fit evidence.
- Keep outreach draft-only. Never send, post, create external drafts, or write CRM in this workflow.

Referenced files: 1

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

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

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. Ground **Team Focus** in actual managers, sellers, account counts, forecasts, targets, and attributable coaching priorities.

## Evidence And Safety

- 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.
- 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.
- 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.
- Never invent forecast targets, weekly movement, seller growth, sources, stakeholders, meetings, customer replies, scenarios, or ownership.
- 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.
- Include source labels only for sources actually consulted; real `sourceCoverage` entries must have `verified: true`.
- 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.

## Preserve The User's Dashboard

- 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.
- 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.
- 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**.
- Follow `sites-building` and `sites-hosting` when operating on an existing hosted project or after hosting is authorized.
- If no correct private Site exists, refresh the stable user-owned local dashboard, return the actual local result, and offer private hosting.
- Return the current dashboard with exactly one next step from the shared lifecycle.
- **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.

Referenced files: 1

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/workloads to solution and cost, and close with a recommendation, sources, assumptions, owners, and next decision.

## Template Choice

- Follow the latest `@presentations` template precedence: use a supplied customer or company deck as the visual source; otherwise honor explicit style direction; otherwise use a current built-in template.
- When visual choice would materially help, offer up to three concise options before authoring: exact named templates currently exposed by `@presentations`, a customer-supplied brand/template deck, or a clearly labeled custom treatment. Never invent a built-in template name.
- Recommend **Codex Grid Layout Library** when it is available and the deck needs a restrained, evidence-led executive style. A CompuCom-inspired clean customer briefing is a custom treatment, not a built-in template.
- Do not block on template choice when the user has no preference; use the current `@presentations` default.

## Deck Rules

- Use 16:9 unless the user or source template requires another format.
- Use the slide count and narrative pattern defined by the triggering Sales skill. Add an appendix for detailed assumptions, Q&A, or sources rather than crowding the core story.
- Prefer simple native diagrams only when they clarify architecture, workflow, operating model, or rollout. Use charts and tables as evidence, not decoration.
- Keep commercial, security, integration, and deployment claims time-bounded and source-backed. Treat the final proposal, order form, security documentation, or other contract-specific source as authoritative where applicable.
- End with a concrete customer decision, discussion, or next step. Do not end on a generic product summary.

Referenced files: 1

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**. Keep these stable defaults when context is thin; safe relevant preferences may refine the focused wording and recommended direction, never reduce the three choices or exclude any other grounded dashboard capability.

**Design style:** After the goal, 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 quickly available authorized context; never use a fixed pair. Keep descriptions to at most eight words and apply the selected preset's internal character and density consistently. 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. Make dark surfaces accessible, require verified live/urgency claims, and never imply ornamental terminal controls execute. Follow the shared lifecycle's private, evidence-feasible image-generated design-reference workflow before implementation unless the user explicitly declines images.

**Complete canvas, personalized focus:** Keep every grounded **Home**, **Accounts**, and **Pipeline** capability available regardless of the chosen goal. Place a concise **Your focus** module at the top of Home only when that saved goal has relevant verified account priorities/changes, opportunity risks/blockers, or upcoming meetings/follow-ups; never invent a priority, change, task, forecast, or metric to fill it. For **Account priorities and changes**, show both the grounded next action and the latest verified change together when both exist; the action must never silently replace the selected account-change evidence. Make account search, scoped group filters, sourced priority sorting when genuine scores exist or accessible alphabetical sorting of verified account names when they do not, verified stakeholders/checklists, and safe CRM account links available within this same durable dashboard, never a competing one-off page.

1. If already-available evidence confirms the current user is not a seller or account owner and no authorized target was supplied, 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 seller, explicit owner/territory/named-account scope, and **complete owned-account universe** from CRM or sufficiently authoritative supplied records. Include accounts without open opportunities; supporting sources may contextualize but never create or override that universe or CRM-owned truth.
2. For a requested working seller dashboard, generate the authoritative initial HTML with the real `render_real_dashboard.py` helper and its retained `../demo-exec-and-seller-dash/assets/account-priority-workspace.template.html` scaffold; never replace the renderer with an ad-hoc static page. Personalize **Home**, **Accounts**, and **Pipeline**, requested additional sections, data, layout, and flows without breaking the generated grounded payload or its real interactive controls; omit unsupported or nonworking controls without removing functional canonical interactions.
3. Populate **Home** with verified customer requests, upcoming meetings, outstanding follow-ups, recent changes, and review items. Populate **Accounts** with every owned account exactly once, relationship status, supported descending priority signals, verified reply-needed items, stakeholders, history, and a safe next action; omit unsupported optional scores, status widgets, and empty sections, and preserve verified zero values.
4. Populate **Pipeline** with every grounded opportunity once, grouped by its current customer blocker; preserve actual CRM stage, verified value, renewal/expansion motion, and the next practical action. When a verified upcoming meeting controls progress, surface meeting preparation in both account and opportunity context.
5. For the broad ongoing Home/Accounts/Pipeline dashboard, follow the production renderer's grounded persona payload, **not** the legacy `references/template-payload.schema.json` ranking-pane contract. Preserve verified source provenance, source-category status and impact, links, and private `evidenceGaps`; add `seller`, `accountDetails`, and `connectedSources` only from evidence. Unsourced account rank, value, priority score, status, and owner subfields are optional and MUST be omitted. Keep source account order without invented ordinal badges or priority labels; never show or narrate `Value unavailable`, `Unavailable`, `Not available`, or compatibility sentinels. Preserve legitimate zero values and distinguish account value from each opportunity amount.
6. Use `workNow`, `watch`, and `paused` only as compatibility collections; they must not remove owned accounts, replace the default views, or make a ranked shortlist the entire dashboard. Keep meetings separate from recent communications and label reply state only when established. Never fabricate accounts, ownership, contacts, stakeholders, sources, meetings, replies, dates, urgency, scores, values, forecast targets, movement, or scenarios.
7. Render grounded JSON or an explicitly marked empty placeholder with `../../scripts/render_real_dashboard.py --persona seller --mode <real|placeholder|representative> --payload <verified-payload.json> --project-dir <stable-user-owned-project>`. When the user explicitly requests `index.html` in the private working directory, use `--project-dir "$PWD"` and verify the complete self-contained `$PWD/index.html`. The renderer-created structural HTML and JavaScript are authoritative: never `apply_patch`, replace, rewrite, or move their existing controls after rendering; refine the verified payload or supported style inputs and rerun the same production renderer. Keep the canonical `tab-home`, `tab-accounts`, `tab-pipeline` controls correctly linked to `view-home`, `view-accounts`, `view-pipeline`; preserve `accounts-list`, `account-search-clear`, `account-drawer`, and `account-drawer-close`. The `priority-sort` button MUST remain inside the original `priority-column` table header; keep `aria-sort` on that same header and verify a real click toggles its direction and the grounded account order. When no genuine priority scores exist, never invent them: keep the separate `account-name-sort` button inside its original `account-name-column` header and verify it alphabetically orders actual verified account names, reverses them, and resets to the original source order with truthful `aria-sort`. Never create `account-sort-column`, move the priority button onto an account-name/value column, or replace a true priority score with account value. Exercise actual Home/Accounts/Pipeline activation, keyboard and ARIA state, search, grounded filters, priority sorting when genuine scores exist or grounded account-name sorting otherwise, and the account-details drawer; repair any broken interaction before returning. Never use the fictional demo renderer or fictional Meridian fixtures; the production helper safely embeds the payload and preserves existing customized HTML during data refreshes.

## Existing Dashboard And Publication

- Identify an existing dashboard only from the current linked Site, the project's `.openai/hosting.json` project ID, or one unambiguous owner/persona/scope match; authoritative user-provided identity/path is sufficient without file inspection. Never select fictional Meridian, another user's dashboard, an unrelated site, an incomplete identity, or an ambiguous candidate.
- Reuse the matching private dashboard's existing project, URL, source, and user customizations. For one matching unpublished local project, follow the shared existing/modify/new choice; create a duplicate only on explicit **Create new**, and never replace a customized page with the original template.
- Without a matching private Site, create and iterate in a stable user-owned local project. Return the working local dashboard and offer a private Site; do not create, publish, externally share, or change hosting until the user explicitly agrees. This local-first requirement overrides the Sites skills' normal automatic-publication default.
- Return the actual existing-site or local dashboard link first, followed by a concise grounded summary, material evidence gaps, and exactly one next step from the shared lifecycle.

## Explicit Account Ranking

- Enter this narrower mode only when the user explicitly requests a ranked-list deliverable, ranking-only worklist, account focus, or weekly priorities. A broad ongoing dashboard that also says "prioritize accounts" remains the normal Home/Accounts/Pipeline workflow and never authorizes invented ordinal ranking.
- Honor the user's named accounts, owner, territory, ranking basis, motion, and capacity first. Default an otherwise broad ranking request to CRM-backed open opportunities, mixed net-new/expansion motion, and deal value or ACV adjusted for timing, momentum, risk, why-now evidence, reachable contacts, actionability, and available seller capacity.
- Apply [suppression and fallbacks](references/suppression-and-fallbacks.md). Keep each account in exactly one of **Suggested Focus**, **Monitor**, or **Suppress Or Block**; if a duplicate-outreach risk still permits a distinct safe action, retain it in Suggested Focus and explain that constraint. Suppress or block only when no seller action is appropriate.
- Show source-backed why now, contacts, commercial context, motion, safe next action, confidence, evidence gaps, and **Source & Run Details** covering account set, ranking basis, source of truth, motion goal, source coverage, assumptions, and material limitations. Prefer fewer executable rows over fabricated certainty.
- When stable source-of-truth links exist and the user explicitly requests the legacy ranked-list pane, render the retained `assets/account-priority-pane.template.html` inside the same durable seller project. Only this explicit pane uses `references/template-payload.schema.json`, its required legacy `rank`/`value` fields, and its value-compatibility sentinel; never apply those requirements to a broad dashboard. Preserve its exact template, map Suggested Focus/Monitor/Suppress Or Block to `workNow`/`watch`/`paused`, escape every JSON `<` as `\u003c`, and replace `__PRIORITIZE_ACCOUNTS_DATA_JSON__` exactly once.
- For an unlinked supplied list, use a grounded chat ranking unless an offline interactive view is explicitly requested. When a requested dashboard cannot be rendered, organize chat fallback under Home, Accounts, and Pipeline; keep ranking-only fallback in the three ranking groups with evidence gaps and source details.

## Follow-Ups And Safety

- For a substantive explicit ranking-only request with reusable scope, first check active and paused matching automations under `$CODEX_HOME/automations/*/automation.toml`, or `~/.codex/automations/*/automation.toml` when unset. Only if none matches, offer one weekly read-only rerun of `seller-account-dashboard` carrying forward the same owner/account scope, ranking basis, motion, and suppression rules; never offer ranking automation solely for a broad account dashboard or alongside its separate full-dashboard refresh.
- Do not create an automation, access restricted CRM data, send outreach, schedule meetings, update CRM, create records, externally share, publish, or change hosting without the separately required explicit authorization and normal security controls.

Referenced files: 4