Update to Sales

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 232
    },
    {
      "relative_path": "references/request-schema.yaml",
      "size_in_bytes": 2248
    },
    {
      "relative_path": "references/signal-taxonomy.md",
      "size_in_bytes": 4869
    }
  ],
  "name": "analyze-account-signals",
  "skill_md_contents": "---\nname: analyze-account-signals\ndescription: 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.\n---\n\n# Analyze Account Signals\n\n\n## Context-Gathering Intake\n\nWhenever this skill needs a material clarification, follow the shared [User Input](../../shared_skill_instructions.md#user-input) guidance.\n\nTurn 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.\n\n## Common Skill Instructions\n\nMANDATORY: If they are not already in context, read and follow [the shared Sales skill instructions](../../shared_skill_instructions.md).\n\n## Key Dependency Categories\n\nThese categories are particularly important for this workflow; use other sources only when they materially improve the signal story.\n\n- [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.\n- ~~Meeting Transcripts for recent customer language, decisions, commitments, objections, follow-ups, and stakeholder movement\n- ~~Email for customer-facing progression, unanswered asks, tone shifts, attachments, and promised next steps\n- ~~Internal Messaging for internal coordination, blockers, stakeholder alignment, and escalation signals\n- ~~Knowledge & Files for account plans, notes, briefs, implementation docs, and prior account context\n- ~~Calendar for recent or upcoming customer sessions, commitments, and scope reduction for large portfolios\n\nUse ~~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.\n\n## Reference Loading\n\n`SKILL.md` owns the normal mode split, bounded retrieval, and output shape. Load references only when their extra detail changes the decision:\n\n- Use [references/request-schema.yaml](references/request-schema.yaml) when structured input, legacy aliases, selector precedence, or machine-readable output shape matters.\n- Use [references/signal-taxonomy.md](references/signal-taxonomy.md) when signal classification, confidence, recency, ranking, delta status, or display labels are ambiguous.\n\n## Workflow Guidance\n\n### 1. Choose the mode and scope\n\n- 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:\n  - `Adhoc Account Brief for one account`\n  - `Monitor Summary for accounts I own in CRM`\n  - `Monitor Summary for a watchlist, owner, or territory`\n- 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.\n- 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:\n  - `Accounts I own in CRM`\n  - `A named owner or territory`\n  - `A watchlist or account list I provide`\n  Do not broaden to a representative seller or retrieve deeper evidence until the user selects a scope.\n- Require exactly one account for Adhoc. Require a watchlist, owner, territory, portfolio, or sufficiently detailed account list for Monitor.\n- 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.\n- 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.\n- 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.\n- 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.\n\n### 2. Bound and resolve the account universe\n\n- For Adhoc, resolve one account by stable CRM id, exact name/domain, or sufficiently detailed user-provided account context.\n- 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.\n- For Monitor, use an explicit watchlist as the full scope. Otherwise use the requested owner/territory/portfolio in ~~CRM with a bounded first pass.\n- For owner-scoped Monitor, prefer primary-owner scope; paginate only while the provider indicates more results and until 50 accounts are collected.\n- 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.\n- If the broader retry times out or fails, continue with primary-owner results when present; otherwise ask for a watchlist or narrower owner scope.\n- 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.\n- Prefer exact name/domain matches and do not trust the top resolver result blindly when several plausible accounts remain.\n\n### 3. Collect bounded recent evidence\n\n- 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.\n- 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.\n- 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.\n- For Adhoc, or when primary evidence is thin, deepen selectively in this order when relevant: ~~Email, ~~Knowledge & Files, ~~Meeting Transcripts, ~~Internal Messaging, then ~~Calendar.\n- 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.\n- 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.\n- 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.\n\n### 4. Normalize, score, and interpret signals\n\n- Normalize evidence into the fixed taxonomy in `references/signal-taxonomy.md`; do not invent new signal labels unless the user explicitly extends the workflow.\n- For every signal preserve type, summary, source, recency, confidence, evidence, citation, and suggested action.\n- Deduplicate several sources describing the same event. Corroboration raises confidence; weak, stale, contradictory, or unsupported evidence lowers confidence and often becomes an Evidence gap.\n- 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.\n- For Adhoc, order signals by importance to the account story: risk/opportunity first, then dependencies, then supporting context.\n- 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.\n- 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.\n\n### 5. Separate evidence from interpretation\n\n- 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.\n- Keep raw evidence and strategic interpretation visibly separate. Every recommended action must trace to a signal or evidence item.\n- If CRM and manual account truth are both unavailable, state that the recency anchor is unavailable and do not imply the result is current.\n\n### Next Step Options\n\nAfter 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:\n- Deepen one account or close the smallest material evidence gap.\n- Draft a concise internal account-team update grounded in the signals.\n- Hand the selected account to deal strategy or meeting prep when the evidence points to an active motion or upcoming conversation.\n- 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.\n- Draft CRM-ready updates for review when missing or stale fields are affecting confidence.\n\nNext steps to avoid:\n- Creating tasks, posting updates, or writing CRM changes automatically.\n\n### Automation Offer Guard\n\nFor `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.\n\nThe 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:\n\n```text\nUse the Sales `analyze-account-signals` skill in `Monitor Summary` mode.\nRerun it for the same seller account scope: [watchlist, owner, territory, portfolio, or CRM filter].\nReturn the standard Monitor Summary output.\n\nmode: \"monitor\"\nowner_id: \"[owner id when used]\"\nowner_email: \"[owner email when used]\"\nwatchlist_accounts: [same watchlist when used]\ntime_window: \"[same or agreed recency window, default 14d]\"\nfocus_areas: [same focus areas such as expansion, churn, rollout blockers, stakeholder movement]\noutput_style: \"inbox_summary\"\n```\n\nFor 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.\n\nThe 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.\n\nBefore 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.\n\n- If a matching automation exists, do not suggest creating another one. Continue with the next most relevant non-automation follow-up.\n- 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.\n- If the automation surface is unavailable, do not mention tool details; offer to help set up a recurring check when automations are available.\n\n## Modes\n\n- `Adhoc Account Brief` — one account, default brief output.\n- `Monitor Summary` — bounded watchlist/owner/portfolio view, default inbox-style output.\n\n## Output Format\n\n### Adhoc Account Brief\n\n```md\n# Account Snapshot\n\n- **Account:** [Linked account when available]\n- **Time Window:** [Window]\n- **Current Posture:** [1-2 grounded lines]\n\n## Key Recent Signals\n\n- **[Plain-English signal label]** — [What changed] · [Fresh/Recent/Stale] · [High/Medium/Low confidence] · [Source link/label]\n\n## Strategic Interpretation\n\n- [What the signals likely mean for land, expand, retention, or execution risk; label inference]\n\n## Recommended Actions\n\n1. [Action] — [Evidence or signal link] — [Expected outcome]\n\n## Open Questions / Missing Evidence\n\n- [Unknown or gap] — [smallest follow-up evidence that would reduce uncertainty]\n\n---\n\n{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}\n\n{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}\n```\n\n### Monitor Summary\n\n```md\n# Ranked Accounts Requiring Attention\n\n| Account | What Changed | Why It Matters | Attention | Posture | Suggested Action | Confidence / Evidence |\n| --- | --- | --- | --- | --- | --- | --- |\n| [Linked account] | [Delta] | [Impact] | [High/Medium/Low] | [Posture] | [Action] | [Link/label] |\n\n## Material Deltas\n\n| Date | Account | Signal | Status | Delta Summary | Impact | Next Step | Confidence |\n| --- | --- | --- | --- | --- | --- | --- | --- |\n| [Date] | [Account] | [Label] | [New/Updated/Worsened/Resolved] | [Delta] | [Impact] | [Action] | [Confidence] |\n\n## Run Metadata\n\n- **Time Window:** [Window]\n- **Data Freshness Cutoff:** [Cutoff or limitation]\n- **Scope:** [Universe, checked count, ranked count]\n- **Delta Since Last Run:** [Only when prior-run context exists]\n\n## No Major Delta\n\n[Include only when useful.]\n\n---\n\n{Follow the instructions and output format/conditions in [Limitations and Improvements](../../shared_skill_instructions.md#limitations-and-improvements)}\n\n{Follow the instructions and output format/conditions in [Next Steps](../../shared_skill_instructions.md#4-offer-one-next-step)}\n```\n\n## Rules\n\n- Do not fabricate accounts, owners, opportunities, metrics, signals, dates, links, or recommended actions.\n- Do not use public web/news research, external enrichment, or task trackers unless the user explicitly extends the workflow and supplies a relevant source.\n- Do not create tasks, posts, digests, CRM updates, or other writebacks in this workflow.\n- Use plain-English display labels rather than raw taxonomy tokens in user-facing output.\n- Rewrite unsupported claims as questions, risks, or evidence gaps rather than assertions.\n- If a monitor run has no material delta, say so concisely instead of padding the ranking.\n\n## Failure Handling\n\nIf 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.\n"
}