[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-80661":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":14,"stars7d":15,"stars30d":15,"stars90d":14,"forks30d":14,"starsTrendScore":14,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":17,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":18,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":14,"starSnapshotCount":14,"syncStatus":15,"lastSyncTime":25,"discoverSource":26},80661,"claude-for-customer-success","t0ddc3by\u002Fclaude-for-customer-success","t0ddc3by","Claude Cowork\u002FCode plugin for Customer Success",null,"Python",51,17,6,0,2,44.97,"Other",false,"main",true,[],"2026-06-12 04:01:29","\u003Cp align=\"center\">\n  \u003Cimg src=\".\u002Fpublic\u002Fclaude-for-cs-hero.png\" alt=\"Claude for Customer Success\" width=\"100%\"\u002F>\n\u003C\u002Fp>\n\n[![License](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-Apache%202.0-34A7D2)](.\u002FLICENSE)\n[![Latest Release](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fv\u002Frelease\u002Ft0ddc3by\u002Fclaude-for-customer-success)](https:\u002F\u002Fgithub.com\u002Ft0ddc3by\u002Fclaude-for-customer-success\u002Freleases)\n[![Last Commit](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Flast-commit\u002Ft0ddc3by\u002Fclaude-for-customer-success)](https:\u002F\u002Fgithub.com\u002Ft0ddc3by\u002Fclaude-for-customer-success\u002Fcommits)\n[![Plugins](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fplugins-6-34A7D2)](.\u002Fdist\u002F)\n[![Skills](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fskills-81-2B89AC)](.\u002Fcsm\u002F)\n[![Built for Claude](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fbuilt%20for-Claude%20Code%20%7C%20Cowork-24718E)](https:\u002F\u002Fclaude.com\u002Fproduct\u002Fcowork)\n[![Changelog](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fchangelog-Keep%20a%20Changelog-90C83D)](.\u002FCHANGELOG.md)\n\nA reference implementation showing what AI-native Customer Success looks like when built on deep domain knowledge — not a deployment-ready product, but a working demonstration of what's possible and what a minimum viable architecture requires.\n\nSix Claude Code\u002FClaude Cowork plugins covering every function in a modern CS organization: CSMs, CS Ops, renewals specialists, onboarding teams, RevOps (for Customer Success), and the infrastructure that connects them. Methodology-opinionated (SuccessCOACHING Customer Success methodologies and frameworks), tool-agnostic.\n\n> New here? Start with **[QUICKSTART.md](.\u002FQUICKSTART.md)** — install in 60 seconds. This README is the full reference.\n\nEverything here is available two ways from one source: install it as a **[Claude Cowork](https:\u002F\u002Fclaude.com\u002Fproduct\u002Fcowork)** or **[Claude Code](https:\u002F\u002Fclaude.com\u002Fproduct\u002Fclaude-code)** plugin, or deploy it through the **[Claude Managed Agents API](https:\u002F\u002Fplatform.claude.com\u002Fdocs\u002Fen\u002Fmanaged-agents\u002Foverview)** behind your own workflow engine. Same system prompt, same skills — you choose where it runs.\n\n---\n\n## Who This Document Is For\n\nThis README serves three audiences. Jump to the section most relevant to you.\n\n**CS leaders and practitioners** using this as a reference for what AI-enabled CS looks like in practice: read [Plugins](#plugins), [Methodology](#methodology), and [Managed Agents](#managed-agents). The plugin and agent breakdown shows what capability coverage across the full lifecycle actually requires — scope, skill count, and architectural decisions most point solutions never reach.\n\n**Operators and developers** building on or adapting the suite: read [Architecture Extensions](#architecture-extensions), [Skill Design](#skill-design), [File Locations](#file-locations), and [Documentation](#documentation). The machine-readable capability model and cross-skill registry are your primary reference artifacts.\n\n**Architects** evaluating the design as a pattern for building multi-plugin suites: the [Methodology](#methodology) section explains why domain knowledge is the real work, and the [Architecture Extensions](#architecture-extensions) section documents the six structural decisions that make an 81-skill coordinated suite maintainable.\n\n---\n\n## Plugins\n\n| Plugin | Who it's for | Core skills |\n|--------|-------------|-------------|\n| [`csm\u002F`](.\u002Fcsm\u002F) | Customer Success Managers on daily account work | Account research, QBR prep, success plans, health review, risk flags, TARO plays, value statements |\n| [`cs-ops\u002F`](.\u002Fcs-ops\u002F) | CS Operations handling portfolio analytics and systems | Health model review, segmentation, capacity planning, playbook audits, data quality |\n| [`renewals\u002F`](.\u002Frenewals\u002F) | Renewals managers and AMs owning GRR\u002FNRR | Renewal forecasting, expansion signals, churn analysis, negotiation prep, contract review |\n| [`onboarding\u002F`](.\u002Fonboarding\u002F) | Onboarding teams and implementation managers | Kickoff prep, onboarding plans, milestone tracking, TtV review, handoff documentation |\n| [`rev-ops\u002F`](.\u002Frev-ops\u002F) | CS revenue operations — the infrastructure CS needs to report and forecast like a revenue center | CRM data quality, expansion and renewal pipeline, forecasting, quota and incentive planning, deal desk governance, outcome-to-value tracking, revenue leakage scanning |\n| [`auq-resilience\u002F`](.\u002Fauq-resilience\u002F) | Infrastructure for all teams using interactive workflows | Fallback protocol when `AskUserQuestion` fails to render; T1\u002FT2\u002FT3 recovery hooks (Claude Code) plus the `\u002Fauq` command for Cowork |\n\nEach plugin installs independently. Install only what your team needs.\n\nThe rev-ops plugin carries the largest footprint (34 of the 81 total skills) and acts as the portfolio intelligence and revenue operations layer for the suite. The auq-resilience plugin is optional infrastructure: it ships no skills (one command, `\u002Fauq`) but makes interactive AUQ prompts resilient to render failures across all five CS plugins — via hooks in Claude Code, and via the `\u002Fauq` command plus per-plugin `CLAUDE.md` rules in Cowork.\n\nAll six plugins are distributed as pre-built `.plugin` files in [`dist\u002F`](.\u002Fdist\u002F).\n\n### A note on rev-ops for CS\n\nThese plugins are organized by function, not by role. Several of them — rev-ops in particular — exist because the capability is missing from most CS organizations, not because there's a dedicated person to own it.\n\nThe core problem: CS teams that want to be treated as a revenue center need to operate like one. That means owning expansion and renewal pipeline visibility, providing forecasting guidance on both, and reporting on revenue outcomes the way sales does. Most CS organizations don't have this infrastructure. Rev-ops for CS is the part of CS Ops that fills that gap.\n\nWithin the rev-ops plugin, four skill clusters are not optional enhancements — they are blockers. A CS organization missing them is running blind on its most important commercial responsibilities:\n\n**CRM Data Quality** (3 skills) — Garbage in, garbage out. Clean CRM data is a prerequisite for every other revenue operation. Health signals, pipeline forecasts, and expansion models all degrade without it.\n\n**Forecasting and Pipeline** (4 skills) — CS needs to visualize and forecast expansion and renewal pipeline the same way sales forecasts new business. Without this, CS leadership cannot make credible revenue commitments or defend budget.\n\n**Planning and Incentive** (5 skills) — Critical for quota-carrying CSM organizations. Compensation design, quota setting, and attainment tracking require the same rigor in CS as in sales.\n\n**Deal Desk and Commercial Terms** (3 skills) — Deal desk serves two functions in CS: bridging the handoff from sales (ensuring commercial terms land correctly with the CS team) and governing expansion sales that originate inside the CS motion. Both are frequently unmanaged.\n\nIf your CS organization is not quota-carrying and has no expansion pipeline accountability, some of these clusters may not apply. If it is, they are the foundation everything else runs on.\n\n---\n\n## Methodology\n\nThe agents and skills in this suite are tools. What makes the solution work is the domain knowledge underneath them.\n\nCustomer Success and SaaS revenue operations are complex systems. Without deep, structured domain knowledge encoding how these systems actually behave — how customers move through a lifecycle, how value is realized, how churn signals accumulate, how renewal motions work — agentic solutions stay point solutions. They make individual tasks faster. They don't change what's possible. They can't deliver the capability addition that is the actual promise of agentic AI: doing things that weren't previously achievable, not just doing existing things more efficiently.\n\nThe reason this domain resists point solutions is structural. The customer lifecycle isn't a sequence of independent tasks. It's a complex adaptive system. Value doesn't arrive at a single stage; it threads through the entire relationship, evolving from theoretical (the outcome promised at sale) to demonstrated (evidence accumulated through adoption) to networked (the expanded value a customer builds on top of your product over time). A tool that optimizes one stage in isolation — faster QBR prep, better renewal forecasting — doesn't touch this progression. It accelerates a piece of work without changing what that work produces.\n\nEffective lifecycle management creates reinforcing feedback loops across CLV, CAC recovery, revenue predictability, and competitive differentiation. Capturing those requires understanding how the stages interlock, not just executing them faster.\n\n### What this suite is not\n\nMost vertical AI plugins are task accelerants. A pitch-deck agent compresses the analyst work inside one stage of a deal process. A contract renewal-watcher screens a document portfolio faster than a paralegal can. Both are genuinely useful. Neither changes what the practitioner does on either side of that moment: the mandate conversation still happens, the negotiation still happens, the close still happens. A human holds the arc. The agent handles one artifact cluster within it.\n\nThat model works for domains where the practitioner workflow is a sequence of largely independent tasks. Legal contract review is a bounded artifact problem. Pitch deck preparation is a bounded research-to-document problem. Automating either changes the speed at which an individual deliverable gets produced.\n\nCustomer Success doesn't decompose that way. The relationship doesn't have discrete deliverables at each stage — it has a progression, and the quality of that progression determines whether the relationship compounds or deteriorates. An agent that makes QBR prep faster doesn't change the arc. An agent that monitors health signals, diagnoses adoption gaps, prescribes the right motion, builds the expansion case, protects advocates, and reconstructs the churn story — across 15 agents spanning every stage from onboarding through non-renewal — changes what's possible for the team running it.\n\nThis suite is built on **SuccessCOACHING** Customer Success Management methodologies because those methodologies are what makes the domain knowledge operational. The **TARO Playbook framework** (Trigger, Action, Resource, Outcome) encodes how CS practitioners should respond to account signals. The **Customer Lifecycle** (Onboarding → Adoption → Value Realization → Renewal\u002FExpansion) encodes how customer relationships actually progress. The **Customer Value Chain** (Product Capabilities → Deliverable Outcomes → Desired Outcomes → Business Goals → Expected Value → Realized Value → Impact) maps how product capabilities transform into business impact — the value transformation mechanism operating within and across those lifecycle stages. The **Two-Layer Outcome\u002FValue Model** separates what the product can deliver at the market level from what it has delivered for a specific account.\n\nThese aren't decorative. They are the guiding intelligence of every skill in the suite. A skill without this structure is a more efficient way to produce a document. A skill built on it can reason about whether the right action is being taken at the right lifecycle stage for the right reason.\n\nThe skills carry that reasoning. You don't need prior experience with the SuccessCOACHING frameworks. They're encoded into the design of the plugins. Cold-start interviews introduce relevant methodology concepts contextually, tied to your actual accounts and tools.\n\n### Why SuccessCOACHING\n\nThe choice isn't arbitrary. Over the past two-plus years, SuccessCOACHING has been building the structural foundations that make deep-domain agentic systems possible for Customer Success.\n\nThe **CSMBOK Knowledge Graph** maps the body of knowledge for Customer Success as a discipline — concepts, competencies, relationships, and the connections between them — in a form that machines can traverse and reason over, not just search. What's encoded in it is the full SuccessCOACHING corpus: 12+ years of CS education and advisory work, every curriculum, research paper, framework, playbook, coaching engagement, and published article the firm has produced. Behind that institutional record sits the founding team's 30+ years each in the field — practitioner experience that predates the Customer Success job title itself. The **CS Skill Graph** maps what CS professionals need to be able to do at each career stage and role type, grounded in observable behaviors rather than job description language. Together they give the agents a shared semantic foundation for the domain that no prompt engineering exercise can replicate.\n\nThe **Agentic Capability Graph** takes that foundation and maps it to the Customer Lifecycle and Value Chain specifically — what capabilities are needed at each stage, how they connect across stages, and where agent intervention changes outcomes rather than just accelerating tasks. This is what made it possible to design 15 agents that cover the full arc rather than 15 agents that each do one thing faster.\n\nThe **Training\u002FFine-tuning Datasets** and **Developer Toolkits** built alongside these graphs provide the technical scaffolding for AI-enabled CS solutions: structured content representations, entity models, intent taxonomies, and query-to-capability mappings that let skills reason about CS work the way a senior practitioner would.\n\nThis suite is one application of that research — a **working reference implementation** and **customizable harness** for building and testing AI-enabled CS solutions and CS-tuned models. The domain knowledge itself is packaged for consumption in multiple forms: MCPs, APIs, Playbooks, and Developer Kits. The suite shows one way to use it. The methodologies aren't a selection from available options — they're the output of a deliberate program to build the domain knowledge layer that makes agent-enabled Customer Success actually work.\n\n### Dual-Track Architecture\n\nThe suite organizes work across two parallel tracks because the customer relationship has two distinct progress dimensions that advance simultaneously. Conflating them produces the most common failure mode in CS practice: measuring activity at the account level while missing value delivery at the outcome level.\n\n**Track 1 — Customer Lifecycle** maps the relational journey. **Track 2 — Value Realization** maps the delivery journey. They are tightly coupled at Stage 3, where demonstrating value is what sustains the relationship. Keeping them as separate tracks means skills can be precise about which dimension they're operating on, and where they interlock.\n\n**Track 1 — Customer Lifecycle** maps the eight stages of the customer relationship from sales handoff through potential churn:\n\n| Stage | Name | Primary Plugin(s) |\n|-------|------|-------------------|\n| Stage 0 | Pre-Onboarding & Handoff | csm, rev-ops |\n| Stage 1 | Onboarding & Initial Setup | onboarding, csm |\n| Stage 2 | Adoption | csm |\n| Stage 3 | Value Realization | csm, cs-ops |\n| Stage 4 | Value Expansion & Growth | renewals, rev-ops, csm |\n| Stage 5 | Renewal | renewals, csm, rev-ops |\n| Stage 6 | Advocacy | csm |\n| Stage 7 | Churn \u002F Non-Renewal | renewals |\n\n**Track 2 — Value Realization** maps the five stages of the value delivery journey: Discovery → Planning → Delivery → Measurement → Expansion. Both tracks advance in parallel; Stage 3 (Value Realization) is where they most tightly interlock.\n\n### Two-Layer Outcome\u002FValue Model\n\nThe suite uses a two-layer model to separate market-level value definitions from account-level value evidence. The distinction matters operationally: market outcomes define what the product *can* deliver; account value statements document what it *has* delivered for a specific customer. Conflating them produces outcome language in account materials that lacks evidence, or account evidence that doesn't connect back to the product's documented value chain.\n\n```\nLayer 1 — Market Outcomes (canonical, portfolio-scoped)\n  └── Produced by: rev-ops:outcome-statement-builder\n      Output: Outcome & Value Catalog (OCV)\n      Consumed by: rev-ops:outcome-to-value-tracking (portfolio scoring)\n\nLayer 2 — Account Value (instantiated, per-account)\n  └── Produced by: csm:value-statement\n      Source: OCV + account business goals + lifecycle stage\n      Lifecycle: evolves through Stages 1–5\n```\n\n**Layer 1 — Market Outcomes (canonical):** `rev-ops:outcome-statement-builder` produces the **Outcome & Value Catalog (OCV)**, a structured set of outcome statements tied to the customer value chain. This is a one-time (or periodic) artifact that codifies the outcomes the company's product can deliver. The OCV is consumed by `rev-ops:outcome-to-value-tracking` to score value evidence at the portfolio level.\n\n**Layer 2 — Account Value (instantiated):** `csm:value-statement` instantiates an account-specific value statement from the canonical OCV, tied to that customer's business goals, success criteria, and lifecycle stage. This is a living artifact that evolves through Stages 1–5.\n\nThe OCV is produced once and referenced by many skills. Account value statements are produced per account and evolve through the customer journey.\n\n---\n\n## Setup\n\n> **Production-grade, not production-ready.** This suite is a reference implementation — built to production standards so the architecture, patterns, and domain knowledge are real, but not designed to drop into your team's workflow without adaptation. Customer Success is practiced differently across organizations. Lifecycle stage definitions, segmentation models, health scoring logic, toolstacks, and team structures vary enough that any honest implementation requires deliberate tailoring. What this suite answers is the harder question: what does a complete, domain-grounded, AI-native CS capability look like, and what does building one actually require? Use it as a working reference and starting point, not a finished product.\n\n### Install from the marketplace\n\nThis repository ships a Claude Code plugin marketplace. Add it once, then install any plugin by name. Users get version pinning and `\u002Fplugin marketplace update` for refreshes.\n\n```bash\n# 1. Add the marketplace (one-time)\n\u002Fplugin marketplace add t0ddc3by\u002Fclaude-for-customer-success\n\n# 2. Install the plugins you need\n\u002Fplugin install csm@claude-for-customer-success\n\u002Fplugin install cs-ops@claude-for-customer-success\n\u002Fplugin install renewals@claude-for-customer-success\n\u002Fplugin install onboarding@claude-for-customer-success\n\u002Fplugin install rev-ops@claude-for-customer-success\n\u002Fplugin install auq-resilience@claude-for-customer-success\n\n# 3. Later, refresh to pick up new versions\n\u002Fplugin marketplace update claude-for-customer-success\n```\n\nEach plugin installs independently — install only what your team needs. The marketplace catalog lives at [`.claude-plugin\u002Fmarketplace.json`](.\u002F.claude-plugin\u002Fmarketplace.json).\n\n**Alternative — install from `dist\u002F` archives.** Pre-built `.plugin` files are also published in [`dist\u002F`](.\u002Fdist\u002F) for users who prefer file-based installation or are working offline. Drop the archive into your Claude plugin directory or use the Cowork plugin install flow.\n\n### First install (any plugin)\n\nRun the cold-start interview in whichever plugin you install first. It will:\n1. Build a **shared company profile** at `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-customer-success\u002Fcompany-profile.md`\n2. Configure that plugin's company profile\n\nSubsequent plugin installs reuse the shared company profile and skip company-level questions (~2 min vs. ~15 min for the full first setup).\n\n```bash\n# CSM plugin (most common first install)\n\u002Fcsm:cold-start-interview\n\n# Or any other plugin\n\u002Fcs-ops:cold-start-interview\n\u002Frenewals:cold-start-interview\n\u002Fonboarding:cold-start-interview\n\u002Frev-ops:cold-start-interview\n```\n\n### Integrations\n\nEach plugin works with whatever you have connected. Cold-start will detect what's available and report which integrations are live. Skills have fallbacks for every integration: no connector is required to get value, but connected tools give significantly richer outputs.\n\n**CSM** — CRM (Salesforce, HubSpot), CS Platform (Gainsight, Totango, ChurnZero, Vitally, Planhat), Call recording (Gong, Chorus, Clari, Krisp)\n\n**CS Ops** — Data warehouse (Snowflake, BigQuery, Redshift), CS Platform, BI (Looker, Tableau, Metabase)\n\n**Renewals** — CRM, CPQ (Salesforce CPQ, DealHub, Conga), Contract storage (DocuSign CLM, Ironclad, Drive\u002FSharePoint)\n\n**Onboarding** — Project management (Asana, Linear, Jira, Monday), CRM\n\n**Rev-Ops** — CRM (Salesforce, HubSpot), Slack, Google Drive, CS Platform, Zapier\n\n**AUQ Resilience** — No MCP connectors required. Operates through Claude Code hooks; in Cowork (no hooks) it operates through the `\u002Fauq` command plus each plugin's `CLAUDE.md` rules.\n\n#### MCP Dependency Matrix\n\nThe table below shows which connectors are required vs. optional per plugin. Skills degrade gracefully without optional connectors, falling back to user-provided context. Required connectors are needed for the plugin's primary skills to function; cold-start will flag missing required connectors.\n\n| Plugin | Required | Optional |\n|--------|----------|----------|\n| csm | None (user-provided context is sufficient for core skills) | CRM, CS Platform, Call recording |\n| cs-ops | CS Platform or Data warehouse (for portfolio analytics) | BI, CRM |\n| renewals | CRM (for renewal date and ARR data) | CPQ, Contract storage |\n| onboarding | None (user-provided context is sufficient) | Project management, CRM |\n| rev-ops | CRM (for pipeline and forecast skills) | CS Platform, Slack, Google Drive, Zapier |\n| auq-resilience | None | None |\n\n---\n\n## Managed Agent Cookbooks\n\nThe [`managed-agent-cookbooks\u002F`](.\u002Fmanaged-agent-cookbooks\u002F) directory contains fifteen agents for teams running Claude as a background workflow engine, plus five rev-ops agents in [`rev-ops\u002Fmanaged-agent-cookbooks\u002F`](.\u002Frev-ops\u002Fmanaged-agent-cookbooks\u002F). Six CS suite agents are scheduled headless agents that run autonomously on a cron cadence; four are on-demand agents; and five form the coordinated value-map-system fleet. All five rev-ops agents support both scheduled and on-demand modes.\n\nEach cookbook agent is a thin orchestration layer over the existing plugin skills. It does not define new capabilities. The scheduled agents call the same skills available interactively; what changes is invocation authority (the agent runs unattended) and output routing (Slack digest, Linear issue, or file write instead of chat response).\n\n### Scheduled agents\n\n| Agent | What it does | Primary plugin |\n|-------|-------------|----------------|\n| [`health-watcher`](.\u002Fmanaged-agent-cookbooks\u002Fhealth-watcher\u002F) | Scans portfolio health daily; routes movement alerts | csm |\n| [`churn-signal-digest`](.\u002Fmanaged-agent-cookbooks\u002Fchurn-signal-digest\u002F) | Aggregates cross-source churn signals; P1\u002FP2\u002FP3 digest | csm |\n| [`qbr-prep-agent`](.\u002Fmanaged-agent-cookbooks\u002Fqbr-prep-agent\u002F) | Researches and drafts QBR packages on a schedule or on-demand | csm |\n| [`renewal-scanner`](.\u002Fmanaged-agent-cookbooks\u002Frenewal-scanner\u002F) | Reviews upcoming renewals; risk classification 90\u002F60\u002F30 days out | renewals |\n| [`onboarding-milestone-tracker`](.\u002Fmanaged-agent-cookbooks\u002Fonboarding-milestone-tracker\u002F) | Tracks M1–M5 milestone completion; flags at-risk accounts | onboarding |\n| [`portfolio-segment-digest`](.\u002Fmanaged-agent-cookbooks\u002Fportfolio-segment-digest\u002F) | Segment-level health roll-up; ARR at risk by band; CS Ops \u002F leadership | cs-ops |\n\n### On-demand agents\n\n| Agent | What it does | Primary plugin |\n|-------|-------------|----------------|\n| [`adoption-motion-agent`](.\u002Fmanaged-agent-cookbooks\u002Fadoption-motion\u002F) | Feature coverage map, gap diagnosis (6-type taxonomy), TARO play prescription | csm |\n| [`expansion-builder-agent`](.\u002Fmanaged-agent-cookbooks\u002Fexpansion-builder\u002F) | Whitespace inventory, business case, AE handoff package | csm |\n| [`advocacy-agent`](.\u002Fmanaged-agent-cookbooks\u002Fadvocacy\u002F) | Burnout-protected advocate qualification, ask script or story structure | csm |\n| [`churn-intelligence-agent`](.\u002Fmanaged-agent-cookbooks\u002Fchurn-intelligence\u002F) | Signal timeline, churn drivers, exit interview guide, postmortem, win-back assessment | renewals |\n\n### Rev-ops agents (scheduled and on-demand)\n\n| Agent | What it does |\n|-------|-------------|\n| [`gtm-pulse-runner`](.\u002Frev-ops\u002Fmanaged-agent-cookbooks\u002Fgtm-pulse-runner\u002F) | Weekly GTM metrics pulse: pipeline, run-rate, velocity, churn signals; five Slack sections with HITL gate |\n| [`capacity-monitor`](.\u002Frev-ops\u002Fmanaged-agent-cookbooks\u002Fcapacity-monitor\u002F) | CS capacity headroom vs. closed-won actuals; NRR-adjusted projections; silent-green Slack pattern |\n| [`churn-signal-scanner`](.\u002Frev-ops\u002Fmanaged-agent-cookbooks\u002Fchurn-signal-scanner\u002F) | Tier 1\u002F2\u002F3 churn signal scan; Tier-3 triggers Linear escalation with human confirmation |\n| [`deal-desk-watcher`](.\u002Frev-ops\u002Fmanaged-agent-cookbooks\u002Fdeal-desk-watcher\u002F) | SLA breach monitor across stage age, approval aging, close date drift, and single-threaded risk |\n| [`planning-cycle-orchestrator`](.\u002Frev-ops\u002Fmanaged-agent-cookbooks\u002Fplanning-cycle-orchestrator\u002F) | Five-phase GTM planning cycle with phase-gate governance and Slack digest after every run |\n\n### Value map system (multi-cookbook fleet)\n\nThe [`value-map-system`](.\u002Fmanaged-agent-cookbooks\u002Fvalue-map-system\u002F) is a coordinated fleet of five cookbooks operating on a shared filesystem control plane — the Customer Value Map. Unlike the single-purpose agents above, this system maintains persistent per-account state across the full customer lifecycle. Agents are classified by write authority: **Blue agents** write to the Value Map; **Green agents** read from it. P1\u002FP2 leakage constrains Green agent output: VCS flags the leakage pattern; QBR still produces the full brief but suppresses the expansion angles section; ERD produces no score or brief at all until leakage is resolved.\n\n| Agent | Color | Trigger | What it does |\n|-------|-------|---------|--------------|\n| [`hie`](.\u002Fmanaged-agent-cookbooks\u002Fvalue-map-system\u002F) — Handoff Integrity Enforcer | 🔵 Blue | CRM `opportunity.won` | Builds the initial Value Map from the sales handoff; enforces seven-stage value chain alignment before kickoff |\n| [`vmb`](.\u002Fmanaged-agent-cookbooks\u002Fvalue-map-system\u002F) — Value Map Builder | 🔵 Blue | CS platform `kickoff_completed` | Populates all four quadrants from kickoff interviews, early usage data, and the success plan |\n| [`vcs`](.\u002Fmanaged-agent-cookbooks\u002Fvalue-map-system\u002F) — Value Chain Position Scanner | 🟢 Green | Weekly, Mon 06:00 | Scores position health (stage alignment, evidence density, active leakage); flags P1\u002FP2 leakage patterns |\n| [`qbr`](.\u002Fmanaged-agent-cookbooks\u002Fvalue-map-system\u002F) — QBR Intelligence Agent | 🟢 Green | Quarterly schedule (`qbr_due` event); CSM manual invocation | Generates QBR brief from full Value Map history; expansion angles section blocked when `signals.hard_block_active` is true or `signals.intervention_priority` is P1\u002FP2 — full brief still produced |\n| [`erd`](.\u002Fmanaged-agent-cookbooks\u002Fvalue-map-system\u002F) — Expansion Readiness Detector | 🟢 Green | Weekly, Mon 06:00 + Growth stage entry | Evaluates expansion signal against leakage state; produces no score or brief when active leakage exists |\n\nSee [`managed-agent-cookbooks\u002Fvalue-map-system\u002FREADME.md`](.\u002Fmanaged-agent-cookbooks\u002Fvalue-map-system\u002FREADME.md) for the full Value Map schema, position health scoring model, and leakage pattern taxonomy.\n\nAgent registration files for the CS plugin agents live in `csm\u002Fagents\u002F` and `renewals\u002Fagents\u002F`; rev-ops agent cookbooks live in `rev-ops\u002Fmanaged-agent-cookbooks\u002F`. See each cookbook's `README.md` for deployment instructions and `steering-examples.json` for prompting patterns. Full architecture documentation is in [`managed-agent-cookbooks\u002FREADME.md`](.\u002Fmanaged-agent-cookbooks\u002FREADME.md).\n\n### Failure Modes\n\nRunning cookbook agents unattended introduces failure scenarios that interactive skill use does not. The most common:\n\n**Connector unavailability** — A scheduled agent calls a CRM connector that returns a timeout or auth failure. Agents log the failure and produce a partial output with an explicit data gap notice rather than silently omitting affected accounts. Check `agent.yaml` MCP server configuration if connectors are consistently unavailable.\n\n**Stale configuration** — An agent reads a company profile (`~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-customer-success\u002F[plugin]\u002FCLAUDE.md`) that was written at cold-start but not updated when the team's segmentation thresholds, escalation matrix, or renewal fields changed. Agents surface a configuration staleness warning when they detect a mismatch between profile values and live CRM data. Run `\u002F[plugin]:customize` to refresh the relevant configuration section.\n\n**HITL gate timeout** — Agents with human-in-the-loop gates (e.g., `gtm-pulse-runner`) wait for an approval before posting final output. If no approval arrives within the configured timeout window, the agent aborts the run and logs the timeout. Set the `hitl_timeout_minutes` field in `agent.yaml` to match your team's response SLA.\n\n**Subagent failure** — Cookbook agents that use subagents (e.g., `health-watcher` spawns `health-reader`, `trend-analyzer`, and `alert-composer`) will produce degraded output if a subagent fails. The parent agent logs which subagent failed and what output is missing. Each subagent's `agent.yaml` includes a `fallback` field specifying behavior when it cannot complete its task.\n\n---\n\n## Claude Managed Agents\n\nDeploy a cookbook agent using the included script:\n\n```bash\nscripts\u002Fdeploy-managed-agent.sh \u003Cslug>\n```\n\nThe script reads `managed-agent-cookbooks\u002F\u003Cslug>\u002Fagent.yaml`, posts to `\u002Fv1\u002Fagents`, and writes the returned `agent_id` to `.env.deploy`. Pass `agent_id` as the `model` parameter in every API call targeting that agent:\n\n```python\nclient.messages.create(\n    model=\"\u003Cagent_id>\",\n    max_tokens=4096,\n    messages=[{\"role\": \"user\", \"content\": \"Run portfolio health scan\"}],\n)\n```\n\n`scripts\u002Forchestrate.py` is a reference event loop that routes `handoff_request` events between agents. Update `AGENT_ROUTING_TABLE` with your deployed agent IDs before running it.\n\nSubagent delegation (`callable_agents`) is a preview capability — it requires a preview-tier API key. Each cookbook `README.md` flags which agents use it and documents the preview constraints.\n\nScheduled agents include a `suggested_cron` field in `agent.yaml`. On-demand agents omit it. Both types deploy through the same script.\n\n---\n\n## Shared Guardrails\n\nAll six plugins enforce these constraints. They are not optional and cannot be overridden by plugin configuration:\n\n1. **Health scores are heuristics, not verdicts.** Never present a health score as a definitive churn prediction. Surface the signal; the CSM owns the judgment.\n2. **Expansion requires qualification.** Flag early-stage expansion signals as leads. Do not present expansion opportunity as confirmed pipeline without sales qualification.\n3. **Renewal forecasts have revenue accounting implications.** Language that could be construed as a revenue commitment requires the reviewer to validate before sharing with finance.\n4. **No triage recommendation without an escalation path and owner.** A risk flag is not complete unless it names who handles it and how.\n5. **Account content is confidential customer data.** Before producing or sending any output containing customer information, check the destination audience.\n6. **TARO plays are leads, not mandates.** The CSM reads the play, validates the trigger, and owns the decision to run it. The agent does not run plays autonomously.\n7. **No silent data freshness.** Every output that draws on CRM or CSP data surfaces the data-as-of timestamp. Stale data that drives a wrong action is worse than no data.\n\n---\n\n## Architecture Extensions\n\nThe 81 skills across these six plugins are built on the standard [Agent Skills](https:\u002F\u002Fagentskills.io\u002F) SKILL.md pattern: frontmatter metadata, trigger blocks, instruction body, and guardrails with some extensions that our research have shown help skills greatly. That baseline is sufficient for a standalone skill. It isn't sufficient for a coordinated suite where 81 skills across 6 plugins need to produce consistent outputs, apply the same domain formulas, enforce the same behavioral constraints, and remain maintainable over time.\n\nA single-skill codebase gets away with embedding domain logic in the skill itself. An 81-skill suite that does that drifts: health score bands defined differently in the CSM health review skill vs. the CS Ops health model review skill, GRR formulas that don't match across renewals and ops, guardrails that exist in some skills but not others. The extensions below solve that problem.\n\n### Shared Domain Model\n\n**File:** [`shared\u002Fcs-domain-model.md`](.\u002Fshared\u002Fcs-domain-model.md)\n\nThe single authoritative source for every domain constant the suite uses. Skills reference this document rather than defining their own versions of shared concepts.\n\nWhat it contains:\n- Health model score bands (0–100) and the 6-component model (product engagement, business outcomes, relationship strength, support health, adoption breadth, contract health), with the 14-day staleness threshold and the interpretation rule that forbids presenting a health score as a churn prediction\n- Customer segmentation labels (Enterprise \u002F Mid-Market \u002F SMB) aligned to ARR thresholds\n- GRR and NRR formulas, exact arithmetic, not approximations\n- Renewal forecast pipeline stage weights and the 3-scenario modeling approach (conservative \u002F base \u002F upside)\n- Time-to-Value definitions, the pace multiplier formula, and the projected TtV calculation\n- Source attribution taxonomy: 8 labels (`[CRM ✓ live]`, `[CS Platform ✓ live]`, `[PM ✓ live]`, `[user provided]`, `[config]`, `[inferred]`, `[stale — N days]`, `[unknown]`) that every skill uses when attributing data in its outputs\n- The 7 shared guardrails (G1–G7) in their canonical form\n\n**Why this matters:** When a CSM asks for a health summary and separately asks for a portfolio health review, the two outputs use identical scoring definitions. When a renewals skill calculates NRR and a CS Ops skill audits NRR, they use the same formula. Domain consistency doesn't happen automatically. It requires a single source and explicit references to it.\n\n### RevOps Domain Model\n\n**File:** [`shared\u002Frevops-domain-model.md`](.\u002Fshared\u002Frevops-domain-model.md)\n\nThe authoritative source for rev-ops-specific operational definitions that fall outside the suite-wide constants in `cs-domain-model.md`. Where `cs-domain-model.md` covers domain concepts shared across all 81 skills, this document covers definitions, formulas, thresholds, and governance rules that the rev-ops plugin's 34 skills use. Skills reference it by section anchor — `[revops-domain-model.md §N]` — rather than embedding definitions in individual SKILL.md files.\n\nWhat it contains:\n- Confidence bands calibrated for rev-ops data (High \u002F Moderate \u002F Low), including the 14-day staleness rule for pipeline and capacity figures\n- Data authority hierarchy: HubSpot as the primary source of record, with Finance Sheets, CS Platform, and Slack\u002FLinear as successively lower-authority fallbacks — skills use this to attribute data and resolve source conflicts\n- Variance classification taxonomy: 5 categories (volume, mix, price, timing, structural) with formulas and a pattern confidence gate that determines when a variance finding is surfaced vs. suppressed\n- CS capacity formulas using the UoG (units-of-growth) model, with a 3-scenario check (conservative \u002F base \u002F upside) and defined thresholds for headroom signals and hiring lead time recommendations\n- OCV (Outcome-Confirmed Value) catalog conventions: entry lifecycle states (Draft \u002F Ratified \u002F Deprecated), the G8 rule governing when OCV entries can be cited in outputs, and the L0–L3 rubric for evidence quality\n- Pipeline coverage signal thresholds: five bands from `\u003C2× CRITICAL` through `>5× INSPECT`, with the interpretation rules skills apply when flagging coverage risk\n- Churn signal tiers: Tier 1 (at close), Tier 2 (30–90 days pre-renewal), Tier 3 (90–120 days pre-renewal) — the canonical timing windows for proactive churn intervention\n- Governance tiers and write protocol: discount approval tiers, deal desk stage definitions, and the Read\u002FWrite protocol controlling which outputs require human approval before action\n- Handoff quality scoring rubric: 5 dimensions at 20 points each, 100-point total, with 80 as the pass threshold — used by skills that generate or evaluate handoff packages\n- Output destination labels: DRAFT labels and the G1–G9 governance tags that skills attach to their outputs to signal confidence and required handling\n- Shared rev-ops guardrails G1–G9: non-overridable governance rules parallel to but distinct from the suite-wide G1–G7 in `cs-domain-model.md`\n\n**Why this matters:** The rev-ops plugin has 34 skills that all need to apply the same confidence bands, churn tier timing, pipeline coverage thresholds, and governance tiers. Without a single source, those definitions drift the same way suite-wide domain constants drift without `cs-domain-model.md` — a pipeline coverage skill and a forecasting skill end up using different thresholds for what counts as adequate coverage. One file, explicit `§N` references from every skill that needs it, no drift.\n\n### Cross-Skill Registry\n\n**File:** [`shared\u002Fcross-skill-registry.md`](.\u002Fshared\u002Fcross-skill-registry.md)\n\nA canonical routing table listing all 81 skills with their command format, available modes, and typical trigger conditions. Skills that reference other skills (e.g., a renewal prep skill that hands off to a negotiation skill) point here instead of hardcoding command strings.\n\n**Why this matters:** Hardcoded command strings in SKILL.md files break when skill names change or plugins are reorganized. The registry is the single place to update routing; every skill that references it picks up the change automatically. It also gives contributors and operators a complete map of the suite at a glance.\n\n### Cross-Stage Composition Patterns\n\nThe suite defines 11 named multi-skill invocation sequences that span stage boundaries. Examples:\n\n- **QBR Preparation Chain** — `csm.account-research` → `csm.health-score-review` → `csm.value-statement` → `csm.qbr-builder`\n- **Renewal Execution Chain** — `renewals.renewal-forecast` → `renewals.risk-assessment` → `renewals.negotiation-prep` → `renewals.executive-summary`\n- **At-Risk Escalation Chain** — `csm.risk-flag` → `csm.escalation-memo` → `csm.taro-play-runner`\n- **Expansion Intelligence Chain** — `renewals.expansion-signal` → `rev-ops.outcome-to-value-tracking` → `rev-ops.next-best-action-recommendation`\n\nFull composition pattern definitions live in [`docs\u002Fclaude-for-cs-agent-capability-model.md`](.\u002Fdocs\u002Fclaude-for-cs-agent-capability-model.md).\n\n### Per-Plugin Config Schemas\n\n**Files:** `[plugin]\u002Freference\u002Fconfig-schema.md` (one per plugin)\n\nStructured schemas defining every configuration field each plugin reads from its company profile: field names, types, valid values, defaults, and required vs. optional status. Skills reference these schemas when reading configuration rather than making assumptions about what fields exist.\n\n**Why this matters:** Cold-start interviews write company profiles that skills then read. Without a schema, skills guess at field names, handle missing fields inconsistently, and break silently when configuration is incomplete. The schema creates a contract between the interview that writes configuration and the skills that consume it.\n\n### Per-Plugin Token Economics\n\n**Files:** `[plugin]\u002Freference\u002Ftoken-economics.md` (one per plugin)\n\nPer-skill token cost estimates covering prompt construction, tool call overhead, connector data volume, and output generation. Estimates are provided for typical (well-configured), minimal (no connectors), and heavy (large account, full connector stack) usage patterns.\n\n**Why this matters:** Token cost is architecture. A skill that pulls 15 CRM records, 30 days of usage data, and a contract PDF in a single pass can consume 40,000+ tokens. Without visibility into that, operators can't decide which skills to run autonomously vs. interactively, or how to scope connector data fetches. Token economics belong in the repository alongside the skills themselves.\n\n### Version Fields\n\nEvery SKILL.md frontmatter carries a `version:` field. Version bumps follow semantic versioning conventions: patch for copy fixes, minor for behavior changes, major for breaking changes to inputs or outputs.\n\n**Why this matters:** Plugin update deployments are opaque without versioning. When a skill produces unexpected output, `version:` tells the operator whether they're running the file they think they are. Version history in commit logs correlates with behavior changes across the fleet.\n\n### Reasoning Protocol Sections\n\nEvery skill body includes a `## Reasoning Protocol` section: a structured 6-step pre-output checklist the skill runs before generating its response:\n\n1. Confirm activation matches trigger conditions\n2. Check connector availability and set fallback path\n3. Confirm an escalation path and owner exist before flagging risk\n4. Apply the guardrails relevant to this skill's output type\n5. Assess output destination (internal CSM use, customer-facing, finance)\n6. Confirm mode selection (e.g., research vs. draft vs. update)\n\nConfig skills (cold-start interviews and customize commands) run a simplified protocol with no guardrail checks, since they don't produce account-level outputs.\n\n**Why this matters:** Guardrail application is the most common failure mode in production CS AI deployments. A skill that \"knows\" the guardrails in its documentation but doesn't have a structured point in its reasoning to apply them will miss them under pressure: when the question is complex, the data is stale, or the output is destined for finance. The Reasoning Protocol makes guardrail application explicit and auditable. When a skill produces an output that violates G3 (revenue commitment language), the question \"did the Reasoning Protocol run step 4?\" has a checkable answer.\n\n### How the Extensions Interact\n\nThe extensions form a stack. The domain model provides constants and guardrail definitions. The Reasoning Protocol enforces guardrails at output time. The cross-skill registry enables composition without coupling. Config schemas make cold-start configuration machine-readable. Token economics make cost visible before deployment decisions are made. Versioning makes change traceable.\n\nA skill that uses all six extensions reads domain constants from `shared\u002Fcs-domain-model.md` rather than defining its own, applies guardrails through its Reasoning Protocol rather than hoping they're remembered, routes to peer skills through the registry rather than hardcoded commands, reads configuration against a known schema, runs within a documented token budget, and carries a version that can be pinned and audited.\n\n---\n\n## Skill Design\n\nEvery skill in this suite is a SKILL.md file: a self-contained specification that Claude reads at invocation time. Understanding the anatomy of a SKILL.md and how skills reference one another explains both how individual skills work and how the suite functions as a coordinated system.\n\n### SKILL.md Anatomy\n\nEach SKILL.md opens with a YAML frontmatter block, followed by a structured Markdown body.\n\n#### Frontmatter\n\n```yaml\n---\nname: risk-flag\ndescription: >\n  Structured risk memo for an at-risk account — signals present, severity\n  assessment, escalation routing from your configured matrix, and recommended\n  intervention.\nargument-hint: \"[account name] [--brief | --escalation-memo]\"\nversion: \"1.0.0\"\ndeployment_target: plugin\n---\n```\n\n**Field explanations:**\n\n| Field | Purpose |\n|-------|---------|\n| `name` | The skill's identifier. Matches the slash command segment after the colon (e.g., `name: risk-flag` → `\u002Fcsm:risk-flag`). Must be unique within the plugin. |\n| `description` | What Claude reads to decide whether to invoke this skill. It must activate on the right inputs (true positives) and stay silent on everything else (true negatives). This is the primary trigger surface — precision here determines whether the right skill fires. |\n| `argument-hint` | Documents the optional arguments the skill accepts, shown in command palettes and documentation. Defines the mode flags available to the user (e.g., `--brief` for a condensed output, `--escalation-memo` to route directly to a memo format). |\n| `version` | Semantic version string. Patch for copy fixes, minor for behavior changes, major for breaking input\u002Foutput changes. Lets operators verify which version of a skill is deployed and correlate behavior changes with code history. |\n| `deployment_target` | Controls which frontmatter rules apply. `plugin` means this skill ships in a Claude Code `.plugin` file; the plugin loader rejects a `security:` block in frontmatter at this target. `catalog` means MCP-delivery deployment; the catalog parser requires a `security:` block with all v5.3 sub-fields. All skills in this suite use `deployment_target: plugin`. |\n\nThe `description` field is the most consequential. It's what Claude's skill routing reads when deciding whether to invoke a skill. A description that's too broad causes false positives (the wrong skill fires). A description that's too narrow causes false negatives (the right skill doesn't fire when it should).\n\n#### Body Sections\n\nThe body follows a consistent section structure across all skills:\n\n| Section | Purpose |\n|---------|---------|\n| `## Use When` | Positive trigger conditions: the situations where this skill should fire. Written as a list of concrete scenarios, not vague capabilities. |\n| `## Do NOT Use For` | Negative trigger conditions and routing table. Situations that look similar but should route elsewhere. Often contains explicit pointers to the correct skill (see [Inter-Skill Referencing](#inter-skill-referencing)). |\n| `## Typical Activation` | Example invocations showing how a user would naturally phrase requests that should trigger this skill. Used during evaluation to test trigger precision. |\n| `## Pre-flight` | Checks Claude runs before generating output: connector availability detection, config validation, fallback path selection. |\n| `## Reasoning Protocol` | A structured checklist Claude applies before generating the final output. Enforces guardrail application, escalation path verification, output destination check, and mode selection. See the [Reasoning Protocol Sections](#reasoning-protocol-sections) note in Architecture Extensions. |\n| `## Mode` | Behavior variations based on the active mode flag. Each mode flag (e.g., `--brief`, `--deep`) produces a different output structure or depth. |\n| `## Data Gathering` | Which connectors to call, in what order, with what fallbacks. Defines what happens when a connector is unavailable vs. what happens when it's live. |\n| `## Output` | The output structure template: headers, required fields, conditional sections, formatting rules. Consuming skills and managed agents expect this structure. |\n| `## Guardrails` | Skill-specific behavioral constraints that layer on top of the shared G1–G7 guardrails. |\n| `## After the Skill` | Post-output guidance: what the user should do next, which skills to run next, and under what conditions. This is where chaining prompts live (see [Next-Step Chaining](#next-step-chaining)). |\n| `## Security & Permissions` | Trust boundary declarations: what external systems this skill can read from, write to, or call. Required for `deployment_target: plugin` skills; placed in the body (not frontmatter) since the plugin loader does not parse security blocks in frontmatter. |\n| `## Trust & Verification` | Config integrity checks: what configuration the skill requires to be present before it proceeds. Defines the halt condition when required config is missing. |\n\nConfig skills (cold-start interviews and `customize` commands) use a simplified section structure. They have no Guardrails, After the Skill, or Trust & Verification sections, since they produce config rather than account-level outputs.\n\n---\n\n### Inter-Skill Referencing\n\nSkills in this suite reference each other through four distinct mechanisms. All of them use command strings drawn from the cross-skill registry (`shared\u002Fcross-skill-registry.md`) rather than hardcoded alternatives.\n\n#### 1. Routing in \"Do NOT Use For\" Blocks\n\nWhen a user invocation is close but wrong (right intent, wrong skill), the `## Do NOT Use For` block names the correct skill explicitly. This is the primary mechanism for routing misfires at invocation time.\n\nFrom `csm\u002Fskills\u002Frisk-flag\u002FSKILL.md`:\n\n```markdown\n## Do NOT Use For\n- Escalation memos for leadership — use `\u002Fcsm:escalation-memo`\n- Routine health reviews without active risk signals — use `\u002Fcsm:health-score-review`\n```\n\nThis pattern keeps the routing logic distributed across skills rather than centralized in a single dispatcher. Each skill owns its own exclusion boundaries and points outward to peers.\n\n#### 2. Next-Step Chaining\n\nAfter generating output, skills suggest the next skill in the workflow, with the exact invocation string and relevant flags. This guides the user through a multi-skill sequence without requiring them to know the full workflow upfront.\n\nFrom `csm\u002Fskills\u002Frisk-flag\u002FSKILL.md`:\n\n```markdown\n## After the Skill\nIf renewal is within 90 days, run `\u002Fcsm:renewal-readiness [account]` to assess renewal exposure alongside the risk posture.\n\nIf executive sponsor access is in question, run `\u002Fcsm:stakeholder-map [account] --sponsor-risk` to map the relationship landscape.\n```\n\nThe chaining is conditional. It fires based on what the current output revealed, not as a rote sequence. Claude can tailor which next step it suggests based on the actual risk profile surfaced.\n\n#### 3. Config Scope Redirect\n\nSome skills depend on configuration that lives in a different plugin's company profile. Rather than duplicating configuration logic, those skills redirect to the owning plugin's `customize` command.\n\nFrom `onboarding\u002Fskills\u002Fhandoff-doc\u002FSKILL.md`:\n\n```markdown\n## Do NOT Use For\n- Changing handoff template structure or required fields — use `\u002Fcs-ops:customize`\n  to configure the handoff template. Then re-run this skill.\n```\n\nThis enforces a single point of configuration ownership. CS Ops owns the handoff template schema; the Onboarding plugin consumes it. When a user tries to configure template structure through the Onboarding skill, the skill redirects to the owning plugin rather than attempting to write config it doesn't own.\n\nFor section-level config changes:\n\n```markdown\n- Updating graduation criteria only — use `\u002Fonboarding:cold-start-interview --section handoff`\n```\n\n#### 4. Downstream Blocking Notation\n\nSome skills explicitly document which downstream skills are unavailable until required configuration exists. This surfaces dependency failures at the earliest possible point rather than when the downstream skill fires.\n\nFrom `onboarding\u002Fskills\u002Fhandoff-doc\u002FSKILL.md`:\n\n```markdown\n## Trust & Verification\nMissing graduation milestone configuration blocks `\u002Fonboarding:handoff-doc`. Run\n`\u002Fcs-ops:customize` to define graduation criteria before using this skill.\n```\n\nThe user learns about the missing config when they try to use the skill that requires it, not when the config-dependent output turns out wrong. The Trust & Verification section is the canonical place to declare blocking conditions.\n\n---\n\n### How the Cross-Skill Registry Enables This\n\nAll four referencing mechanisms use command strings drawn from `shared\u002Fcross-skill-registry.md`. The registry is a flat table of every skill across all six plugins: command format, available mode flags, and the lifecycle stage each skill belongs to.\n\n```\n\u002Fcsm:risk-flag [account] [--brief | --escalation-memo]\n\u002Fcsm:renewal-readiness [account] [--brief | --deep | --exec-summary]\n\u002Fcsm:stakeholder-map [account] [--full | --sponsor-risk | --decision-maker]\n```\n\nWhen a skill author adds a next-step chaining prompt, they copy the command string from the registry. When a skill is renamed or a flag is added, the registry is updated first, and all skills that reference it pick up the change naturally at the next edit pass. No skill hardcodes an alternative command string.\n\nThe registry also documents six cross-plugin workflow sequences: named multi-skill chains that cross plugin boundaries. Example:\n\n| Pattern | Sequence |\n|---------|---------|\n| At-Risk Triage | `csm:risk-flag` → `csm:escalation-memo` → `csm:taro-play-runner` |\n| Renewal Prep | `renewals:renewal-forecast` → `csm:renewal-readiness` → `renewals:negotiation-prep` |\n| Onboarding Handoff | `onboarding:milestone-tracker` → `onboarding:handoff-doc` → `csm:account-research` |\n\nThese cross-plugin sequences are documented in the registry so operators understand the full multi-plugin workflow, not just individual skill capabilities.\n\n**The maintenance rule is strict:** `shared\u002Fcross-skill-registry.md` is the source of truth for all command strings. Individual SKILL.md files must not hardcode alternative command strings. This rule keeps the registry authoritative and prevents routing drift when skills evolve.\n\n#### Machine-Readable Capability Model\n\nFor tooling, integrations, and operators who need structured per-skill metadata, [`docs\u002Fclaude-for-cs-agent-capability-model.yaml`](.\u002Fdocs\u002Fclaude-for-cs-agent-capability-model.yaml) is the authoritative machine-readable representation of all 81 skills. Each entry carries:\n\n| Field | What it captures |\n|-------|-----------------|\n| `id` | Canonical skill identifier, matches the `name:` frontmatter field |\n| `version` | Current deployed version, mirrors SKILL.md frontmatter |\n| `summary` | One-sentence capability description |\n| `intended_tasks` | Structured list of tasks this skill is built to handle |\n| `out_of_scope` | Explicit exclusions: the machine-readable equivalent of `## Do NOT Use For` |\n| `invocation_cues` | Natural-language patterns that should trigger this skill |\n| `anti_cues` | Patterns that look relevant but should not trigger this skill |\n| `constraints` | Behavioral constraints active during this skill's execution |\n| `tools_used` | Connectors and MCP tools the skill may call |\n| `related_skills` | Skills that compose with this one: the machine-readable form of next-step chaining |\n| `success_criteria` | Observable conditions that constitute a correct output |\n\nThe YAML model and the SKILL.md files are parallel representations of the same skills: SKILL.md is what Claude reads at runtime; the YAML is what tooling reads at build time or integration time. When a SKILL.md is updated, the YAML model should be updated to match.\n\n---\n\n## Coverage Notes\n\nThe suite's 81 skills break down as 47 lifecycle skills (Stages 0–6) and 34 cross-cutting ops skills. Coverage is not uniform across lifecycle stages (but will be expanded in subsequent releases and can be augmented by solutions like our skill-enabled TARO playbooks that feature 850+ additional skills see the **taro-play-runner** skill):\n\n- **Stages 0–5** have full or near-full skill coverage with documented workflows and stage gate criteria.\n- **Stage 6 (Advocacy)** has minimal dedicated coverage: two skills, `csm.advocate-identification` and `csm.advocacy-ask`. Broader advocacy program design, community management, and reference program coordination are deliberately out of scope for v1.1.0. These activities require human relationship judgment that doesn't compress well into a skill interaction; the agent cookbook `advocacy-agent` handles the research and qualification work that does.\n- **Stage 7 (Churn \u002F Non-Renewal)** has partial coverage. `renewals.churn-analysis` and the `churn-intelligence-agent` cookbook address post-decision analysis; proactive churn prevention is handled through Stage 5 skills and `rev-ops.early-churn-downgrade-signal-detection`. Win-back motion skills and automated exit interview synthesis are on the backlog for v1.2.0.\n\nThe coverage gaps in Stages 6 and 7 are architectural decisions, not oversights. Our skill development backlog prioritizes win-back motions and expanded advocacy program support for the next minor version.\n\n---\n\n## File Locations\n\n```\n~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-customer-success\u002F\n├── company-profile.md          # Shared — all six plugins read this\n├── csm\u002FCLAUDE.md               # CSM company profile (written at cold-start)\n├── cs-ops\u002FCLAUDE.md            # CS Ops company profile\n├── renewals\u002FCLAUDE.md          # Renewals company profile\n├── onboarding\u002FCLAUDE.md        # Onboarding company profile\n└── rev-ops\u002FCLAUDE.md           # Rev-Ops company profile\n```\n\nPlugin templates (this directory) ship with the plugin and are replaced on update. User data lives only in `~\u002F.claude\u002Fplugins\u002Fconfig\u002F`.\n\nPractitioner deployment guides live in the repository under `deployment-cookbooks\u002F`:\n\n```\ndeployment-cookbooks\u002F\n├── README.md                   # Reference build explanation and tailoring guidance\n└── solo-csm-cookbook.md        # Solo CSM deployment guide — full lifecycle, personal use\n```\n\n### Developer Tooling\n\nThe repository includes build and evaluation tooling for contributors and operators maintaining the suite:\n\n```\nscripts\u002F\n├── build-plugins.sh            # Packages all six plugins into dist\u002F*.plugin files\n├── validate-skills.sh          # Runs frontmatter validation across all SKILL.md files\n└── update-registry.sh          # Syncs cross-skill-registry.md from SKILL.md frontmatter\n\n[plugin]\u002Fskills\u002F[skill-name]\u002F\n└── evals\u002F                      # Per-skill evaluation sets (gitignored — not shipped in plugin)\n    ├── true-positives.md       # Invocation cues that should trigger the skill\n    ├── true-negatives.md       # Inputs that should not trigger it\n    └── output-rubric.md        # Criteria for evaluating output quality\n```\n\nThe `evals\u002F` directories are present during development but excluded from built plugins via `.gitignore`. To run evaluations against a deployed plugin, pull the skill source from the repository rather than the installed plugin file.\n\n---\n\n## Documentation\n\nThe [`docs\u002F`](.\u002Fdocs\u002F) directory contains extended reference documentation:\n\n| Document | Contents |\n|----------|----------|\n| [`claude-for-cs-agent-capability-model.md`](.\u002Fdocs\u002Fclaude-for-cs-agent-capability-model.md) | Complete 81-skill capability catalog organized by lifecycle stage; 11 composition patterns; tier distribution; coverage gap analysis |\n| [`claude-for-cs-agent-capability-model-lifecycle.md`](.\u002Fdocs\u002Fclaude-for-cs-agent-capability-model-lifecycle.md) | Skills organized by lifecycle stage with Two-Layer Outcome\u002FValue Model integration; coverage summary table |\n| [`claude-for-cs-integrated-journey-value-realization-guide.md`](.\u002Fdocs\u002Fclaude-for-cs-integrated-journey-value-realization-guide.md) | Stage-by-stage workflow guide with Mermaid diagrams, value chain focus tables, gap risk tables, and stage gate criteria for all lifecycle stages |\n| [`claude-for-cs-agent-capability-model.yaml`](.\u002Fdocs\u002Fclaude-for-cs-agent-capability-model.yaml) | Machine-readable capability registry for all 81 skills: structured YAML with per-skill `id`, `version`, `summary`, `intended_tasks`, `out_of_scope`, `invocation_cues`, `anti_cues`, `constraints`, `tools_used`, `related_skills`, and `success_criteria`; authoritative source for tooling and integrations |\n\n---\n\n## Deployment Cookbooks\n\nThe [`deployment-cookbooks\u002F`](.\u002Fdeployment-cookbooks\u002F) directory contains operational guides for practitioners deploying the suite. These are role-specific deployment companions — not the same as the automated managed-agent cookbooks in `managed-agent-cookbooks\u002F`.\n\n> **These are reference builds, not plug-and-play deployments.** The plugins and workflows described in the cookbooks are designed around generalizable patterns. Every deployment requires tailoring to the specific tools, data schema, and CS motion of the organization using them. See [`deployment-cookbooks\u002FREADME.md`](.\u002Fdeployment-cookbooks\u002FREADME.md) for the full explanation of what \"reference build\" means and what tailoring is required before going live.\n\n| Cookbook | Audience | Status |\n|----------|----------|--------|\n| [`solo-csm-cookbook.md`](.\u002Fdeployment-cookbooks\u002Fsolo-csm-cookbook.md) | Individual CSMs deploying the full suite for solo use across the customer lifecycle | [PROPOSED] |\n\nTo add a cookbook for a different role, motion, or deployment variant, follow the instructions in [`deployment-cookbooks\u002FREADME.md`](.\u002Fdeployment-cookbooks\u002FREADME.md).\n\n---\n\n## AUQ Resilience\n\n**Package:** [`auq-resilience\u002F`](.\u002Fauq-resilience\u002F) · **Distributed:** [`dist\u002Fauq-resilience-v1.1.0.plugin`](.\u002Fdist\u002F)\n\nThe CS plugins use `AskUserQuestion` (AUQ) extensively for cold-start interviews, skill mode selection, and interactive clarification. When AUQ works, the user gets an interactive multiple-choice widget. When it fails (unsupported client, missed render, tool error), Claude receives an empty response with no recoverable path. Without a fallback, the entire skill interaction stops.\n\nThe `auq-resilience` plugin installs two Claude Code hooks:\n\n- **`PreToolUse` hook** — intercepts AUQ calls and injects prose fallback instructions alongside the widget render request\n- **`PostToolUse` hook** — detects empty or unparseable AUQ responses and injects a structured prose multiple-choice block so Claude can proceed\n\nThe hooks implement a T1\u002FT2\u002FT3 protocol: T1 retries the widget once, T2 injects the prose fallback, T3 logs the failure and continues with a declared default. An AUQ render failure never produces a dead end. Claude always has a recoverable path.\n\nInstalling the plugin is a one-step install. Wiring it into a plugin requires adding two entries to that plugin's `hooks\u002Fhooks.json`. All five CS plugins ship with empty hook slots ready to receive the wiring. The auq-resilience plugin does not change how AUQ works when it succeeds. It only catches failures.\n\n### Enabling in Cowork\n\nClaude Code hooks do not run in Cowork — `PreToolUse`\u002F`PostToolUse`\u002F`UserPromptSubmit` never fire there, so the mechanical fallback above is unavailable. In Cowork the same protocol is delivered two ways, both already in place:\n\n- **Behavioral rules** — every CS plugin's `CLAUDE.md` carries an **AskUserQuestion (AUQ) Resilience** section (single-question, T2 prose fallback, T3 embedded default). These apply automatically whenever that plugin is active. No setup beyond installing the plugin.\n- **The `\u002Fauq` command** (v1.1.0+) — `auq-resilience` ships `commands\u002Fauq.md`, invoked as `\u002Fauq-resilience:auq` with `force-prose`, `status`, or `reset`. Commands are the one plugin surface that runs in Cowork, so the command auto-registers on install — no wiring required.\n\nTo enable: install `auq-resilience` in Cowork (desktop plugin install), then restart Cowork so the command registers. Nothing else is needed — the behavioral rules ship inside each CS plugin.\n\nSee [`auq-resilience\u002FREADME.md`](.\u002Fauq-resilience\u002FREADME.md) for install steps, the `\u002Fauq` command reference, and the full T1\u002FT2\u002FT3 protocol.\n\n---\n\n## Making It Yours\n\nEvery plugin ships with defaults that work out of the box. Four layers of configuration let you tune behavior without modifying plugin source files:\n\n- **Swap connectors** — edit the plugin's `.mcp.json` to point at your CRM, CS platform, Slack workspace, or data warehouse. Skills that use a connector degrade gracefully when the connector is absent; skills that don't need one ignore the file entirely.\n- **Add firm context** — the `cold-start-interview` command in each plugin writes a company profile to `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-customer-success\u002F[plugin]\u002FCLAUDE.md`. Edit that file directly to update segmentation thresholds, renewal risk criteria, escalation matrices, and named contacts. Agents and skills read the profile on every run.\n- **Bring your own templates** — paste your team's QBR template, success plan format, or executive summary structure into the relevant section of the company profile. Skills use your template instead of the built-in one.\n- **Adjust agent scope** — fork a cookbook's `agent.yaml` to change which skills it calls, what output it routes, and which HITL gates it enforces. No changes to the plugin itself are required.\n- **Add your own** — write a `SKILL.md` using the CS plugin skill pattern and bundle it into a new plugin file alongside the stock skills. The [Skill Design](#skill-design) section documents the pattern and required frontmatter.\n\n---\n\n## Claude for Microsoft 365 — Install Tooling\n\n`claude-for-msft-365-install\u002F` is a Claude Code plugin — not a Cowork plugin — for IT administrators provisioning the Claude for Microsoft 365 add-in. It is separate from the six CS suite plugins and does not need to be installed by individual CS team members.\n\nInstall in Claude Code (admin terminal):\n\n```\n\u002Finstall claude-for-msft-365-install\n```\n\nThen run the setup command:\n\n```\n\u002Fclaude-for-msft-365-install:setup\n```\n\nThe setup command provisions the M365 add-in via Microsoft Graph API. It supports Vertex AI, Amazon Bedrock, and internal LLM gateways as the backing model endpoint and writes a deployment summary to `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fmsft-365-install\u002Fdeployment.md` on completion.\n\n---\n\n## Skill & Command Reference\n\nRun `\u002F[plugi","该项目是一个基于Claude Cowork\u002FClaude Code插件的客户成功（Customer Success）解决方案。它通过六个插件覆盖了现代CS组织中的所有职能，包括客户成功经理、运营团队、续约专家、入职团队以及收入运营等，并且这些功能均基于SuccessCOACHING客户成功方法论构建。项目采用Python语言开发，旨在展示AI原生客户成功实践的可能性及所需的基本架构。适用于希望探索如何将AI技术应用于提升客户服务质量和效率的企业或个人。此外，该方案支持多种部署方式，既可以直接作为Claude平台的插件使用，也可以通过API集成到自定义的工作流引擎中。","2026-06-11 04:01:32","CREATED_QUERY"]