--- name: cse-engagement-finder description: Find and qualify potential CSE engagement targets by scanning Jira, Slack, and call transcripts against readiness criteria, then draft owner follow-ups without sending them. Use when the user asks to find CSE engagements, qualify CSE targets, CSE pipeline, CSE engagement discovery, or prospect CSE accounts. argument-hint: "[optional: focus area or account filter]" --- # CSE Engagement Finder & Qualifier ## Compact MCP routing Follow the shared [compact MCP routing contract](../../shared/compact-mcp-routing.md). Interactive facade tools are `cse_capabilities`, `cse_read`, `cse_apply`, `context_assemble`, and `cse_session_info`; named operations are capability ids. Call reads through `cse_read` with the capability id. Every mutation goes through `cse_apply` twice: dry-run first, then the identical capability and arguments with `execute:true`, a justification of at least 16 trimmed characters, and the returned `preview_digest`. Call `context_assemble` and `cse_session_info` directly when needed. Check `cse_capabilities` when a capability id or schema is genuinely unknown. Worked read example: ```jsonc jira_search({ named_query: "all_open", fields: ["summary", "status", "assignee", "labels", "created"], maxResults: 50 }) ``` Slack follow-ups are output artifacts only. Draft them in the report; never apply them. Discover potential Customer Success Engineering engagement targets by cross-referencing the CSE Jira board, Slack signals, and call transcripts, then classify each account by readiness. ## Domain Configuration Use the `cse_domain_info` capability for field/stage discovery and pass semantic names to Jira capabilities. Never use raw field or transition ids. ## Message voice Bucket B Slack drafts use the direct operator voice below, not the terse lowercase `thread-register` style: - Start in sentence case with an ownership statement: "Picking this up.", "Yep, let's pull CSE in.", or "I took a look at ." - State what changed or what the evidence establishes before asking for anything. - Name continuity when it matters: the existing ticket, owner, stage, or prior work. - Separate the immediate scope from broader blocked or commercial work. - Close with one concrete next step or one direct question. - Use contractions, short declarative sentences, and compact paragraphs. Do not compress a nuanced qualification into a lowercase two-sentence verdict. - Include the evidence permalink in the draft, but keep it out of the opening sentence. Voice references: ```text Yep, let's pull CSE in. I repurposed CSE-56 around API Catalog activation, moved it back into Technical Discovery, and kept Andrew on it for continuity. We'll pull today's recording from Kepler once it lands and tighten the scope from there. For this pass, we'll focus on standing up Catalog on their current tenant and proving a repeatable Enterprise Automation Suite workflow. The broader Service Registry expansion stays separate while FedRAMP and licensing are blocked. Can you connect Andrew with the Lockheed technical lead who'll own the setup so we can schedule the first working session? ``` ```text Picking this up. I reopened CSE-56 as API Catalog Activation, kept Andrew on it for continuity, and moved it into Technical Discovery. We'll review today's call, confirm the Lockheed counterpart and first-use-case scope, then get the working session scheduled. ``` Before drafting any Bucket B DM or handoff comment, follow `.agents/shared/prose-voice.md` (and the `writing` skill) for operator voice. ## Prerequisites & MCP Setup Before running, source the bootstrap so `CSE_TOOLD_BIN` and `CSE_OPERATOR` resolve: ```bash source "${PLUGIN_ROOT:-${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-$PWD/plugins/cse-tools}}}/.agents/shared/skill-bootstrap.sh" ``` The daemon keeps daemon keychain auth fresh on its own; no mint step is needed. On a 401, call `cse_session_info({"force_refresh": true})` once, retry once, then stop and report the exact failing surface. A 403 means blocked or revoked access: surface the returned operator action without retry. If `127.0.0.1:9901/mcp` refuses the connection, follow `cse-mcp-setup` daemon recovery, re-probe once, and stop if that single retry still refuses the connection. Prefer MCP tools for normal work; shared scripts are fallback/diagnostic helpers. Required surfaces: - **Read strategy:** Follow [`.agents/shared/read-strategy.md`](../../shared/read-strategy.md). The Phase 1 board pull and Phase 2 Slack discovery stay direct; Phase 3 per-candidate qualification goes through `context_assemble(kind:account)`. For a broad, entity-unknown thematic scan ("which strategic accounts show migration pain this quarter"), `cse-sweep` is an optional pre-Phase-2 aid; it never sets readiness or drives a write. - **Direct-tool guardrails for this skill:** Follow [`.agents/shared/tool-frugality.md`](../../shared/tool-frugality.md). Owned tools (`jira_search`, `google_calendar_events`, `confluence_*`) return compact by default; pass `verbosity:"full"` only when you need the raw payload. Hydrate Kepler/Granola only for what you'll actually cite. - **Jira** — local `cse-tools` MCP capabilities (`jira_search`, `jira_get_issue`, `jira_create_issue`, `jira_edit_issue`, `jira_transition_issue`, comments/properties). - **Slack reads** — local `cse-tools` MCP (`slack_search`, `slack_channels`, `slack_users`, `slack_read_channel`, `slack_read_thread`). - **Slack follow-ups (draft only)** — produce ready-to-send text in the report. Never call `slack_open_dm`, `slack_post_message`, `slack_update_message`, `slack_delete_message`, or a reaction capability from this skill. The skill may still create qualified Bucket A Jira intake tickets and append the local ruled-out log. - **Granola (recommended, optional)** — use `granola_list_meetings` for active-workspace attendee discovery and `granola_get_meetings` for selected details when Kepler-side Gong coverage is thin. Use `granola_get_meeting_transcript` only for exact wording and REST only for an explicit cross-workspace gap. Skip silently when Granola is not enrolled; Kepler transcripts remain the primary qualification input. - **Kepler primary**: Kepler tools inside local `cse-tools` MCP (`list_customers`, `get_salesforce_account`, `semantic_context_search`, `list_communications`, `get_communications`). If a surface is unavailable after preflight, record it as `DATA UNAVAILABLE — not connected` and continue. If Kepler is unavailable, continue without backend enrichment. Full MCP install docs live in `README.md`. ## CSE Engagement Criteria (All Three Required) 1. **Strategic account** -- Tier 0/1, typically $250K+ ARR 2. **Engineering or platform leadership sponsorship** -- Named champion with authority 3. **Defined technical initiative** -- hands-on integration, automation, or devops co-execution that the CSE builds alongside a named customer engineer. Every CSE engagement is implementation work that embeds Postman as infrastructure, tied to one of: - API Catalog / Spec-Driven Automation - Git Sync / v12 Migration architecture - CI/CD Pipeline design (Newman, Postman CLI) - Governance Maturation (rulesets, linting, standards) - Provisioning / Dev Systems Integration - Agent Mode / AI Adoption - Asset Ingestion (SwaggerHub migration, etc.) ## Not CSE-shaped (route elsewhere) CSE work is building, not advising. If the ask is satisfied by guidance, a best-practices writeup, a policy recommendation, or a config walkthrough, it is not a CSE engagement, even at a strategic account. Common non-CSE asks and where they go: - **Best-practices or governance-policy questions** (how to stop free users sharing collections publicly, how to structure workspaces, what other customers do for X) -> SE or Solutions guidance, docs, or a lightweight CSE consult at most. - **Security or admin configuration** (SSO, SCIM, Domain Capture, BYOK, audit log) -> Support or Professional Services. - **Break/fix, version unlocks, license moves** -> Support (help@postman.com). - **Onboarding, training, or "help us use Postman more"** -> SE or CSM. - **Commercial, renewal, or usage-justification work** -> AE, CSM, or TAM. The bright line: no implementation to build, no acceptance criteria, and no customer engineer to co-work with means it is not a CSE engagement. An advisory question can become a consult; a consult becomes an engagement only once a build with a named technical counterpart is scoped. ## Workflow ### Phase 1: Baseline -- Understand Current CSE Work **Goal:** Build a mental model of what CSE engagements look like so you can pattern-match. 1. Query the CSE Engagement Tracker Jira project directly with capability `jira_search`. Use `named_query: "all_open"`, `maxResults: 50`, and bounded fields: `summary, status, issuetype, priority, created, labels, assignee, reporter, description, customer_name, team_id, account_arr_tier, primary_timezone`. 2. For each distinct canonical customer that needs team size, renewal, or account-roster context, use one bounded `list_customers` call and one `get_salesforce_account` call using the returned account ID. Use its ARR, `teams[]`, renewal detail, and `roster`; do not infer those values from Jira prose. 3. Extract from each ticket: - Customer name and account context (ARR, team size, renewal timeline) - Engagement category (from labels or summary brackets) - Workflow stage - Account team roster (AE, CSM, SE, Field CTO) - Technical initiative description 4. Build a summary table of: - Issue distribution by status/stage - Common engagement categories (count and examples) - Active CSE assignments (who owns what) - **Customer list** (used as exclusion list in Phase 2) ### Phase 2: Signal Hunting -- Scan Slack **Goal:** Find accounts NOT on the CSE board that show engagement-ready signals. Before searching Slack, load the append-only `.agents/logs/engagement-finder-ruled-out.md` file when it exists. Add its account identities to the Phase 1 exclusion set unless newer evidence explicitly invalidates the logged reason. Run parallel `slack_search` calls across these signal categories: **Direct CSE requests:** ``` "need CSE" OR "CSE help" OR "technical resources" OR "dedicated customer" ``` **Technical initiative signals:** ``` "API catalog" OR "spec-driven" OR "customer struggling" "v12 migration" OR "git sync" OR "customer help needed" "governance" OR "CI/CD pipeline" OR "postman enterprise" "proof of value" OR "POV" OR "pilot" OR "enterprise expansion" ``` **Risk/urgency signals:** ``` "renewal risk" OR "churn" OR "evaluating alternatives" OR "competitor" ``` **Workshop/onsite signals:** ``` "customer onsite" OR "workshop" OR "API-first" OR "platform integration" ``` **Channel-specific searches:** Resolve the current supported roster from Slack's directory with bounded `slack_channels` searches before scanning; do not hardcode stale intake surfaces. Include visible channels matching current gold-account, migration-help, account-specific `customer-*`, `fde-*`, regional SE-coverage, revenue-announcement, and success-team purposes. Use only channel IDs returned by that directory lookup. For each hit, extract: - Account name - Who is asking (AE, SE, CSM, Field CTO, leadership) - What they need (migration help, governance, catalog, CI/CD, etc.) - ARR if mentioned - Whether a champion/sponsor is named - Whether a specific technical initiative is described **Cross-reference against the Phase 1 exclusion list.** Remove any accounts already on the CSE board. ### Phase 3: Deep Qualification -- Call Transcripts & Comms **Goal:** For each candidate account, determine if the three CSE criteria are met. For each account from Phase 2, assemble the qualification context in one call instead of walking the per-source ladder by hand: 1. **Assemble the account context** (one `context_assemble` call per candidate, batched): ```jsonc context_assemble({ entity: { kind: "account", ref: "" }, facets: ["blockers", "ownership", "recent_activity", "open_loops"], window: { since: "<30-60 days back>" } }) ``` The daemon resolves the canonical account (SFDC id), fans out across Kepler comms, semantic search, KG, Salesforce, Slack, and Granola, hydrates the top hits, reranks, and returns a ranked `working_set` plus a per-source `coverage` line. Read `identity` to confirm the canonical name matches (watch for false matches on common names); read `coverage` honestly (`slack=empty` is often a rate-limit, not silence; `kepler_comms=error` means lean on the remaining cards). This replaces the hand-run `list_customers -> get_salesforce_account -> semantic_context_search -> list_communications` ladder. 2. **Hydrate the readiness evidence you'll cite.** For a call whose card mentions `governance`, `catalog`, `CI/CD`, or `migration` and that you intend to quote, use `get_communications` and arguments `ids=["call:"]`, `include_content="full"`, `content_max_chars=10000`, and `content_page=1`. Follow the returned page count by incrementing `content_page` when full text is required. `body` and `transcript` are identical strings -- read one, never both. Use `get_salesforce_account` if you need an exact ARR/team field the cards did not surface. 3. Score each account against the three criteria: | Criterion | Met | Partially Met | Not Met | |---|---|---|---| | Strategic ($250K+) | ARR confirmed above threshold | ARR near threshold or combined pipeline qualifies | Below threshold, no expansion path | | Sponsorship | Named engineering/platform leader committed | Champion identified but not yet committed | No technical stakeholder identified | | Technical initiative | Defined project with scope and timeline | Pain identified but not yet scoped into a project | No technical need surfaced | ### Phase 4: Classification Sort accounts into two buckets: **Bucket A -- Ready to Engage CSE:** - All three criteria met - Discovery calls have happened with the right stakeholders in the room - Technical initiative is defined with specific scope - Pattern matches an existing CSE engagement on the board - A CSE could start work within 1-2 weeks **Bucket B -- Needs Legwork from SE/AE First:** - One or two criteria met, but gaps remain - For each account, specify: - What's missing (sponsor? initiative? discovery?) - Who needs to do what (AE run discovery, SE probe for use case, etc.) - What the potential CSE engagement would look like IF the gaps are closed - Priority ranking within this bucket (by ARR at risk, strategic importance, or proximity to readiness) ### Phase 5: Output Deliver a structured report: 1. **Current board summary** -- snapshot of active CSE engagements (count, categories, team load) 2. **Bucket A accounts** -- ready to engage, with: - Account name, ARR, key contacts - Technical initiative summary - Evidence trail (Slack permalinks, Gong links, Jira tickets) - Recommended CSE assignment 3. **Bucket B accounts** -- needs work, with: - Account name, ARR, what's missing - Recommended next action and owner - Priority ranking 4. **Accounts ruled out** -- and why (too small, already served by FDE, reactive support need, etc.) ### Phase 6: Action Execution and Drafting After Phase 5 produces the report, execute qualified Jira intake and local ruled-out logging automatically. Prepare Slack follow-ups as drafts only. Never send or modify a live Slack message. Include an ACTIONS EXECUTED / DRAFTS PREPARED block after the report. **A. Bucket A accounts -- auto-intake to Jira** For every Bucket A account (all three criteria met), invoke the `cse-intake` flow without a per-account prompt. For each account: 1. Compose a synthetic intake brief from the canonical identity returned by Phase 3, named sponsor, defined initiative, and strongest evidence link (Slack permalink or Gong call ID). 2. Use the Phase 3 evidence and all-three-criteria score as the pre-create readiness gate. Do not invoke `.agents/shared/resolve-or-escalate.md` before a ticket exists; that policy requires an issue key, status, and Team ID. `cse-intake` invokes it post-create. 3. Call the `cse-intake` skill with `customer=`, `category=`, and the evidence link. 4. If `cse-intake` is not directly invokable as a subskill, follow its workflow inline without shortening it: resolve Team ID, run its canonical-customer-plus-source duplicate search, populate all 10 required `semantic_fields`, and dry-run every write followed by an execute call with the returned digest: ```js cse_apply({ capability: "jira_create_issue", arguments: { fields: { summary: " []" }, semantic_fields: { customer_name: "", team_id: "", primary_timezone: "", account_arr_tier: "", problem_statement: "", executive_sponsor: "", technical_counterpart: "", impact_metrics: "", postman_demonstration: "", customer_assets: "" } }, execute: true, justification: "Preview the evidence-qualified CSE engagement create" }) cse_apply({ capability: "jira_create_issue", arguments: { fields: { summary: " []" }, semantic_fields: { customer_name: "", team_id: "", primary_timezone: "", account_arr_tier: "", problem_statement: "", executive_sponsor: "", technical_counterpart: "", impact_metrics: "", postman_demonstration: "", customer_assets: "" }, execute: true, preview_digest: "" }, execute: true, justification: "Create the evidence-qualified CSE engagement" }) ``` Then perform the reachable two-hop sequence, previewing each hop separately. Hop 1 is Submitted to Qualification Review and sets `stage_complete`; hop 2 is Qualification Review to Technical Discovery: ```js cse_apply({ capability: "jira_transition_issue", arguments: { key: "CSE-XX", stage: "Qualification Review", semantic_fields: { stage_complete: "" } }, execute: true, justification: "Preview hop 1 into Qualification Review" }) cse_apply({ capability: "jira_transition_issue", arguments: { key: "CSE-XX", stage: "Qualification Review", semantic_fields: { stage_complete: "" }, execute: true, preview_digest: "" }, execute: true, justification: "Advance the intake into Qualification Review" }) cse_apply({ capability: "jira_transition_issue", arguments: { key: "CSE-XX", stage: "Technical Discovery" }, execute: true, justification: "Preview hop 2 into Technical Discovery" }) cse_apply({ capability: "jira_transition_issue", arguments: { key: "CSE-XX", stage: "Technical Discovery", execute: true, preview_digest: "" }, execute: true, justification: "Advance the qualified intake into Technical Discovery" }) ``` Also perform the intake-confirm `/tmp` `body_path` comment and post-create shared-policy steps defined by `cse-intake`; do not invent a reduced parallel flow. 5. Record the resulting CSE-XX key in the ACTIONS EXECUTED block. Skip intake only if: (a) the account already has a non-closed CSE ticket (re-run the Phase 1 exclusion check), (b) the named sponsor declined in a recent Gong call (search transcripts for "not ready", "hold off", "not now"), (c) research produced no Team ID from Salesforce, or (d) Phase 3 did not evidence the required sponsor or technical counterpart with enough confidence. In skip cases, list the account in HELD with reason. **B. Bucket B accounts -- draft a note to the right Postman owner** For every Bucket B account, prepare a ready-to-send Slack draft for the AE / SE / CSM named in the evidence trail. Follow the Message voice contract above. Include the specific next step and the strongest evidence link. Put each draft in the final report under the owner's name. Do not open a DM, post to a channel, update a message, add a reaction, or otherwise contact anyone. If the owner is not identifiable, draft a channel message for the most relevant account-specific `#customer-*` or `#help-cse` channel and leave the addressee as a clearly reported gap. **C. Accounts ruled out -- record the decision** If any account was explicitly considered and ruled out as noise, add a line to the repo-relative running log at `.agents/logs/engagement-finder-ruled-out.md` with date, account, and reason. Append-only. This prevents re-researching the same dead lead on a subsequent run. ### Phase 7: Reporting Append to the Phase 5 output: ``` ACTIONS EXECUTED ---------------- Intake tickets created ([count]): [CSE-XX Account (category) -- evidence link] Slack notifications sent: 0 (draft-only contract) Ruled out appended ([count]): [Account: reason] DRAFTS PREPARED --------------- Slack drafts ([count]): [@ re: -- ready-to-send draft] HELD ---- [Account: intended action, reason] ``` ## Pitfalls - **If Kepler is unreachable**, fall back to deeper Slack mining -- search `#customer-internal-` and `#customer-int-` channels directly. - **Slack search results are large.** Use parallel searches but extract key fields to avoid context window bloat. - **"CSE request" and "CSE-ready" are different.** People ask for CSE because they want help; always validate all three engagement criteria independently. - **FDE engagements are not CSE gaps.** If an FDE is already embedded, the account is served. Only flag if the FDE engagement is ending and a CSE handoff makes sense. - **EMEA accounts need EMEA SE discovery.** Don't recommend CSE engagement for accounts where no one has even had a discovery call yet. - **Gold Account status updates in `#gold-accounts`** are high-signal. "At risk" or "off track" flags combined with technical pain = strong CSE candidate. ## Success Criteria - Every Bucket A account has all three criteria evidenced with links - Every Bucket B account has a specific, actionable next step with an owner - No accounts already on the CSE board appear in the output - Classification is defensible -- if challenged, each rating can be traced to specific Slack messages, call transcripts, or Jira data - No live Slack message, DM, update, deletion, or reaction is performed; all outbound Slack communication is returned as a draft - Bucket B drafts follow the sentence-case, ownership-first, scope-aware voice references in this skill