--- name: cse-case-study description: Turn closed CSE engagements into internally publishable case-study drafts. Use when the user asks to mine closed CSE tickets for testimonials, customer quotes, success stories, validation summaries, or case-study candidates. Scans Closed - Complete Jira tickets, enriches with Gong/Kepler, Slack, linked docs, and Granola when available, then prepares a sourced internal case study plus source notes. argument-hint: "[--days 30] [--max N] [--customer NAME] [--jql JQL] [--execute]" --- # CSE Case Study Drafts ## 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`, justification, and the returned `preview_digest`. Call `context_assemble` and `cse_session_info` directly when needed. Create internal, approval-gated case studies from completed CSE work. The output is a page that can be published internally verbatim after review. Avoid template previews, Jira recaps, and evidence dumps. The narrative must answer four questions: 1. What did the customer say, in their own words? 2. What did CSE specifically deliver? 3. What changed for the customer? 4. What wider reusable model does this unlock for Postman? ## Hard boundaries - Default mode is dry-run. Do not write Confluence until the user asks for execution or passes `--execute`. - Never fabricate quotes, metrics, customer titles, outcomes, source links, or approval status. - Keep exact quotes verbatim. Do not clean grammar, casing, or wording inside quotation marks. - Do not turn internal summaries, CSE opinions, or AI-generated Jira updates into customer quotes. - Do not imply external publication rights. Customer, PMM, and legal approval remain open unless a source explicitly confirms them. - Redact tokens, secrets, private repo credentials, sensitive logs, unnecessary PII, and architecture details that are not needed for the story. - Emails come from Kepler communications only. Do not search Gmail or any Google mailbox. Google Docs/Drive are allowed only for linked documents, not mailbox mining. - Slack/Jira/Kepler identifiers are evidence inputs. Internal case studies should use human-readable sources such as `Gong transcript, 2026-04-16, "7/11 x Postman Next Steps"` or `Gong email capture, 2026-04-28, "Postman x 7/11 - Next Steps"`. - Opaque Kepler IDs belong in the run log or private evidence inventory. ## CSE ownership rule This is a CSE case-study skill. The center of gravity must be what CSE delivered. Product, FDE, SE, Support, and customer work can appear only as context. Before drafting, classify every major workstream: | Workstream type | Handling | |---|---| | CSE-built or CSE-led delivery | Can be the headline if customer evidence supports it. | | CSE automation around another team's work | Can be central only if the story makes the workflow layer clear and shows how it connects to the broader customer path. Do not frame it as competing with the adjacent team's work. | | FDE/Product-owned integration or feature | Use as team-delivered context or downstream destination. Do not make it the case-study headline or imply CSE built it. | | Customer-owned implementation detail | Use only when it clarifies adoption, rollout, or expansion. | Example: if FDE built an X-Ray connector and CSE automated the repo-to-Postman workflow around it, the case study should center on the reusable workflow pattern while still treating the connector as part of the Postman team story. X-Ray can appear as the customer's reporting destination, but not as the thing CSE claims to have built. In reader-facing prose, infer the CSE contribution through the work itself. Avoid phrases like `the reusable CSE artifact` when `the reusable pattern` or `the automation layer` carries the point more naturally. ## Banned reader-facing artifacts The case study will be published internally verbatim. Do not leak scaffolding into it. Never include: - Literal template headings such as `Opener`, `Board-ready narrative`, `Leadership narrative`, `Exact quote bank`, `Quote bank (verbatim, verified)`, `Claim ledger`, or `Externally citable`. - Redundant labels like `(verbatim, verified)`. Quotes in a case study are presumed verified. - Opaque Kepler call IDs, email IDs, or internal identifiers in reader-facing prose. - A hard `---` divider that implies only the top half is the case study. Source notes can live at the end under a normal heading. - Pilot bug lists, token/permission troubleshooting, path-length failures, duplicate-resource debugging, or other implementation noise. - Defensive project-management rationalization: why a delay was not a delay, how patiently we handled timing, or what we proved while waiting on the customer. - Pre-scripted seller menus or discovery-question lists. `What Sales can use` should be short prose with the actual customer proof. - Self-scores, critic-rubric references, readiness labels in headings, or AI/tool provenance. ## Voice rules - Use contractions in narrative prose: `it's`, `don't`, `we've`, `can't`, `won't`, `isn't`, `there's`, `that's`. - Never use the Unicode em dash. Use commas, semicolons, or `--`. - Lead with a named customer voice or concrete customer stake. Do not lead with a category label. - Use declarative language when direct evidence supports a claim. Hedge only weak or inferred claims, and put the hedge in source notes. - Narrative register is Postman-to-Postman. Use `we` for Postman/CSE work; avoid third-person `CSE` as the grammatical subject. - Keep prose specific enough that it could not describe any customer. - Avoid `first of its kind`, `first meaningful proof point`, and `proved it on a small scale` framing unless the source explicitly makes that the customer value. Most good patterns become commonplace; frame the operating model the work unlocks instead. ## Writing pattern to follow The strongest drafts read like a single internal story. Use this pattern: 1. Open with a customer quote in a real business setting. Explain why the setting matters. 2. State the CSE story in one sentence: the workflow, automation layer, rollout model, or operating model we delivered. 3. In `What CSE delivered`, describe the delivered pattern first, then use bullets for the concrete mechanics. 4. Add a leave-behind paragraph that connects repo, spec, generated assets, validation, reporting, governance, or rollout into one operating model. 5. In `What changed`, use adoption signals, rollout intent, or estimated before-state pain. Estimates are fine in internal case studies, including CSE estimates, as long as they're labeled as estimates and tied to the delivered workflow. 6. In `Why this matters to Postman`, use short prose paragraphs. Avoid a generic list of "proof points"; explain the reusable model and the objection it answers. 7. In `What Sales can use`, give the seller one clean story to carry. Pair the strongest quote with the before/after or rollout signal. No menus. ## Product terminology guardrail Treat these as legacy/deprecated surfaces unless the source is explicitly historical: - `API Builder`, `APIs` as a product-surface name, `Private API Network`. Current surfaces in this workflow: - `V12`, `Spec Hub`, `specs`, `API Catalog`, `repo sync`, `Postman CLI`, `workspace`, `monitors`, `mocks`, `environments`, `collections`, `Agent Mode`, `MCP`. If a customer is migrating off a legacy surface, say so as historical context. Do not frame legacy names as the current product story. ## Setup From the repo root, load the shared bootstrap so `CSE_TOOLD_BIN` resolves: ```sh 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. Required surfaces: - Read strategy: Follow [`.agents/shared/read-strategy.md`](../../shared/read-strategy.md), with a stricter rule here: **do not use `context_assemble` to obtain quotes or quote candidates**. Every reproduced verbatim passage must come directly from `get_communications`, `jira_get_issue`, or `confluence_get_page`, with its human-readable provenance. Never quote a summary, reranked context pack, or `cse-sweep` output. `cse-sweep` isn't an evidence source for this skill. - Confluence: local `cse-tools` MCP (`confluence_search`, `confluence_get_page`, `confluence_markdown_to_storage`, gated writes when enabled). - Kepler primary: Kepler tools inside local `cse-tools` MCP (`list_customers`, `semantic_context_search`, `list_communications`, `get_communications`). - Slack reads: direct `slack_search`, `slack_read_thread`, and `slack_read_channel` calls when needed for internal corroboration; don't reproduce Slack text as verbatim evidence in the case study. - Granola: optional supplemental transcript source. If Kepler returns `401`, request `cse_session_info({"force_refresh": true})` once and retry. A `403` means access is blocked or revoked: surface the named operator action and stop without retrying. If auth recovery still fails or the source stays unavailable, mark Kepler unavailable and stop using Kepler-dependent claims; do not add API-key env headers. ## Inputs Accept any combination of: - Lookback window, default `--days 30`. - Max tickets, default `--max 10`. - Customer filter. - JQL override. - Pattern mode, for example `--pattern spec-driven-automation`. - `--execute` to create or update Confluence after dry-run preview. Default JQL: ```jql project = CSE AND status = "Closed - Complete" AND statusCategoryChangedDate >= -30d ORDER BY statusCategoryChangedDate DESC ``` Do not include `Declined`, `Redirected`, or `Closed - Abandoned` in the default scan. ## Phase 1: Pull CSE tickets Use `jira_search` and `jira_get_issue` with semantic field names (the daemon maps to customfield ids): - `summary`, `status`, `assignee`, `reporter`, `labels`, `updated`, `statuscategorychangeddate`, `comment` - Customer Name: `customer_name` - Team ID: `team_id` - Problem Statement: `problem_statement` - Executive Sponsor: `executive_sponsor` - Technical Counterpart: `technical_counterpart` - Impact Metrics: `impact_metrics` - Postman Demonstration: `postman_demonstration` - Customer Assets: `customer_assets` Preserve Jira comments and linked artifacts, but treat Jira-written summaries as internal until verified against customer-spoken or customer-authored evidence. ## Phase 2: Enrich with Kepler and Granola For each candidate: 1. Resolve the account in Kepler. If account-name lookup fails, search by participant email from Jira or meeting invites. 2. Run `semantic_context_search` for the account and story query to locate likely communications. Treat results as discovery hints only, never as quote text. 3. Pull communications from 30 days before ticket creation through 21 days after closure, or the user-supplied window. 4. Fetch likely evidence-bearing calls and emails with `get_communications(ids=[id], include_content="full", include_participants=true, content_max_chars=10000, content_page=1)`. When the response reports more pages, increment `content_page` and fetch every page needed; never treat the first 10,000-character page as the complete source. 5. Use Granola only to discover that a relevant meeting exists when Kepler coverage is incomplete. Don't reproduce Granola text; hydrate the matching communication through `get_communications`, or omit the quote if no allowed verbatim source is available. Prioritize communications that mention: - validation, success criteria, production, rollout, adoption, procurement, renewal, reporting, approval, next steps - the executive sponsor or technical counterpart - the exact CSE delivery pattern, such as GitHub/GitLab Actions, repo sync, branch protection, API Gateway discovery, Postman CLI, contract tests, smoke tests, monitors, workspace automation, Spec Hub, API Catalog, Agent Mode - expansion language, such as roll out, rest of team, internal showcase, enterprise, other teams, working session, onsite, champion Every time new transcript/email material is found, record: - strongest exact quote - speaker and title - human-readable source (`Gong transcript/email capture, date, meeting/thread title`) - why it matters - which claim it supports - whether the work described is CSE-owned, CSE-adjacent, or owned by another team ## Phase 3: Build the story spine Before writing prose, fill this planning object: ```json { "customer_voice": "strongest customer quote and why it matters", "cse_delivered": ["specific CSE-owned deliverables"], "adjacent_work_not_to_claim": ["FDE/Product/SE/customer work that can be context only"], "what_changed_for_customer": ["customer-confirmed outcomes"], "reusable_model_unlocked": "what operating model, objection answer, or repeatable path this unlocks beyond the account", "sales_use": "one plain-language way a seller can use the story", "source_risks": ["approval, metric, architecture, or source caveats"] } ``` If the CSE-owned deliverable is weak or invisible, do not publish a full CSE case study. Keep it as an evidence note or route it to the owning function. ## Phase 4: Draft the page Before drafting longform prose, load the [`writing` skill](../writing/SKILL.md) and [`prose-voice.md`](../../shared/prose-voice.md), or run the draft through the [`cse-prose-rewrite` skill](../cse-prose-rewrite/SKILL.md). Apply the voice pass only to authored narrative. Keep every verified quotation byte-for-byte unchanged, then compare the finished draft against the evidence ledger so the voice pass can't add, drop, or reattribute a claim. Use this structure. Headings may vary slightly, but do not include scaffolding labels. 1. `# : ` 2. One italic status line: `_Internal case study draft. Named-customer external use requires , PMM, and legal approval._` 3. Opening scene: named customer voice or concrete customer stake, with one killer quote. 4. One framing paragraph that explains why the quote matters and what CSE actually delivered. 5. `## What CSE delivered` 6. `## What changed for ` 7. `## Why this matters to Postman` 8. `## What Sales can use` 9. `## Source notes for internal reuse` Source notes can include: - `### Customer lines used` - `### Technical notes` - `### Additional customer-written validation` when useful - `### Claim notes` - `### Approval checklist` Use human-readable sources in source notes. Prefer Gong transcript/email links when available. Do not show opaque Kepler IDs unless the user explicitly asks for a private evidence inventory. Do not title or frame the draft as "CSE proved X works on Y" if the better story is the operating model that now scales across customers. Prefer "turned X into a rollout-ready workflow", "made X part of the customer's release system", or "unlocked a reusable path for Y". ### Draft-file workflow (required for the Confluence write) Confluence sends are file-only: inline `body_storage` is rejected. Author the body once in a `/tmp` file and pass `body_storage_path`; never re-emit a long body inline. 1. Write the storage XHTML body to a `/tmp` file (e.g. `confluence_markdown_to_storage` output saved to `/tmp/.md`). Editing the draft there also draws non-blocking line guidance from the voice guard. 2. Submit with `confluence_create_page` / `confluence_update_page` using `body_storage_path` pointing at that `/tmp` file. These are dual-mode operations through `cse_apply`. Preview first (outer `execute: true` and justification; omit underlying `arguments.execute` so the named write dry-runs); require the dry-run's snapshot and retain its `preview_digest`. Execute only after explicit approval, carrying that digest into the otherwise identical arguments with underlying `arguments.execute: true`: ```js cse_apply({ capability: "confluence_create_page", arguments: { title: "", space_key: "CSE", parent_id: "<case-studies-page-id>", body_storage_path: "/tmp/<page>.storage.html" }, execute: true, justification: "Preview the approved internal case study create" }) ``` ```js cse_apply({ capability: "confluence_create_page", arguments: { title: "<title>", space_key: "CSE", parent_id: "<case-studies-page-id>", body_storage_path: "/tmp/<page>.storage.html", execute: true, preview_digest: "<digest-from-preview>" }, execute: true, justification: "Publish the approved internal case study" }) ``` Use the created page id from the apply response to GET the page back: ```js cse_read({ capability: "confluence_get_page", arguments: { page_id: "<created-page-id>", body_format: "storage" } }) ``` Assert the returned title, storage body, and parent exactly match the previewed create, and that the returned version is the expected initial version. A successful apply response without these assertions isn't verification. For updates, fetch the current page first, then preview `confluence_update_page` with `page_id` plus its current `expected_version`. Require the raw pre-write snapshot and digest from the preview, and carry the digest into apply: ```js cse_apply({ capability: "confluence_update_page", arguments: { page_id: "<page-id>", expected_version: 7, title: "<title>", body_storage_path: "/tmp/<page>.storage.html" }, execute: true, justification: "Preview the approved internal case study update" }) ``` ```js cse_apply({ capability: "confluence_update_page", arguments: { page_id: "<page-id>", expected_version: 7, title: "<title>", body_storage_path: "/tmp/<page>.storage.html", execute: true, preview_digest: "<digest-from-preview>" }, execute: true, justification: "Publish the approved internal case study update" }) ``` Then GET the updated page: ```js cse_read({ capability: "confluence_get_page", arguments: { page_id: "<page-id>", body_format: "storage" } }) ``` Assert the exact title, body, unchanged parent, and version `8`. Check the tool's inputSchema in `tools/list` if any field is uncertain. If the send is blocked, the block reason names the `/tmp` file and the exact lines to fix; edit those lines in the same file and re-call with the same `body_storage_path`. The voice guard applies its deterministic autofixes to the payload first, so a corrected resubmit usually clears on the next try. ## Phase 5: Critic gate Reject or revise the draft if any of these is true: - The first section has a literal `Opener` heading. - The title centers an adjacent team artifact, a "first of its kind" claim, or a small-scale proof. - The narrative claims CSE built something owned by FDE, Product, SE, Support, or the customer. - Opaque Kepler IDs appear in the publishable page. - A section says `Quote bank`, `verbatim, verified`, `Claim ledger`, or `Externally citable`. - The page has a hard `---` reader/appendix divider. - The main narrative centers a technical integration when the actual CSE deliverable was automation, rollout, workflow design, or reuse. - The case study contains a multi-step technical walkthrough before the source notes. - The case study includes defensive timing/project-management rationalization. - The case study includes implementation debugging noise. - The case study turns estimates into hard ROI claims, or uses metrics that aren't tied to the customer story. - The case study says `first of its kind`, `first meaningful proof point`, `sandbox demo`, or `proved it on a small scale` when the stronger framing is the wider model it unlocks. - The case study includes a pre-scripted seller menu or discovery-question list. - The prose uses a Unicode em dash. - The prose uses deprecated product names as current surfaces. - Exact quotes lack a human-readable source in the source notes. - Emails are sourced from Gmail/mailbox search. ## Output style and claim calibration - Lead with customer voice and the reusable model. - Prefer customer-spoken or customer-written evidence over internal summaries. - Make the CSE deliverable impossible to miss, but don't over-label it as CSE in every sentence. - Keep technical detail in service of the business story. - State strong claims plainly when sourced. - Move caveats to source notes, but keep useful estimated metrics in the narrative when they make the before/after clearer. - Cut any sentence that could describe any customer. ## Pattern mode When multiple customers share a pattern, produce one platform thesis page with: - the shared CSE delivery pattern - the three strongest customer proof points - what varied by customer - what became more reusable with each engagement - what Sales, Product, and leadership should do with the pattern Do not force weak customers into the pattern. Customers without strong customer voice or clear CSE-owned deliverables stay in source notes. ## Success criteria - Only `Closed - Complete` CSE tickets are scanned by default. - Every exact quote has human-readable provenance. - Kepler email is used for customer emails; Gmail/mailbox search is not used. - Every full case study names what CSE specifically delivered. - Adjacent FDE/Product/SE work is not claimed as CSE work. - The publishable page contains no scaffolding headings, opaque Kepler IDs, quote-bank labels, hard reader/appendix divider, self-score, or critic rubric text. - Dry-run produces a Confluence-ready preview with no write. - Execute mode creates or updates only in the CSE space under `Case Studies`, through the Confluence safety gate.