revops-kickoff

{
  "skill_name": "revops-kickoff",
  "evals": [
    {
      "id": 1,
      "prompt": "I run revenue ops at Kesselbrook Freight Systems - B2B, 38 AEs, mid-market logistics software. We've missed our number three quarters running and the CFO is done hearing excuses. Honestly our CRM data is garbage: close dates get pushed every single week, about half the open deals are missing an amount, and there are opportunities created in 2024 still parked in stage 2. Q3 closes in 9 days. Our VP Sales owns the pipeline and our ops analyst Dara does the admin work. Where do I point this?",
      "expected_output": "A cold-start kickoff: a capped interview, the immediate task routed to sales-forecast-diagnostic rather than pipeline-hygiene, a short-list re-ranked around the 9-day close, slow-payoff classes moved to Not now with the close date as their unblocking condition, and a new revops-context.md.",
      "files": [],
      "expectations": [
        "Routes the immediate task to `mbfinotti/revops-skills@sales-forecast-diagnostic`, not to `mbfinotti/revops-skills@sales-pipeline-hygiene`, despite the data-quality symptoms described",
        "States that a forecast miss caused by dirty data still starts at the forecast diagnostic because that skill separates data-quality causes from behavioral causes from genuine demand problems, and hygiene remediates afterwards",
        "Names exactly one skill as the route for the immediate task",
        "Treats the session as a cold start because no `revops-context.md` exists, and does not ask the user whether this is a new or a continuing project",
        "Asks no more than 7 interview questions",
        "Asks interview questions one per message rather than as a single block of questions",
        "Offers multiple-choice options on at least one interview question",
        "Asks explicitly for the date the result has to land by, and for the one-off-versus-standing horizon together with an effort ceiling",
        "Produces a short-list of between 5 and 8 skills",
        "Promotes `sales-forecast-diagnostic` and the recurring-sweep class in the short-list on the stated grounds that the close date sits inside two weeks",
        "Moves account health, any governance rewrite, and all macro-design skills to a \"Not now\" list with the Q3 close date named as their unblocking condition, rather than leaving them ranked at the bottom of the short-list",
        "States out loud which interview answer moved which class of skill off its default position",
        "Creates `revops-context.md` at the project root recording the landing date, the horizon and the effort ceiling, and appends a session-log line before the session ends"
      ]
    },
    {
      "id": 2,
      "prompt": "Picking my RevOps work back up at Almedra Tooling after six weeks off. There's a revops-context.md sitting in the repo root, here's what it says:\n\n# RevOps context\n- Updated: 2026-04-02 (session 5)\n- Revenue motion: B2B sales-led, mid-market\n- CRM / system of record: CRM authoritative for deals and contacts; billing system authoritative for ARR. Owned day-to-day by Soren Vakil; changes signed off by the VP Sales, Renata Oyelaran.\n- Stage set: 7 stages, exit criteria rewritten and signed off in session 4\n- In-flight work: none open\n- Decided: single pipeline for both segments; ARR reads from billing\n- Open: whether the inbound SLA should be 5 or 15 minutes\n- Constraints: engineering-wide change freeze until 2026-05-18; no admin capacity at all until Soren is back from leave; nothing has to land by a date\n- Horizon and effort ceiling: standing system; about 3h/week; schema changes need Renata's sign-off\n- Stakeholders: Renata Oyelaran -> decides; Soren Vakil -> consulted; CS lead -> informed\n\n## Session log\n- 2026-03-11 - map stage problems -> pipeline-stage-definition-audit -> 5 of 7 stages flagged\n- 2026-04-02 - rewrite exit criteria -> pipeline-stage-definition-audit -> signed off\n\nToday I want to fix lead assignment. Inbound is landing on the wrong reps and some leads sit untouched for two days.",
      "expected_output": "A warm start: exactly one question asked, a 5-line state summary from the artifact, lead-routing deleted from the short-list and moved to Not now under the freeze, diagnosis absorbing the session, and the artifact patched with one new log line.",
      "files": [],
      "expectations": [
        "Treats this as a warm start because `revops-context.md` is present, and does not ask the user whether the project is new or continuing",
        "Asks only the session-goal question, and asks no question about revenue motion, CRM ownership, constraints, horizon or effort ceiling",
        "Opens with a state summary of exactly 5 lines",
        "The state summary covers motion, system of record, in-flight work, top open decision, and active constraint",
        "Re-ranks the short-list from the horizon, effort ceiling and constraints already recorded in the artifact rather than re-asking for any of them",
        "Deletes `mbfinotti/revops-skills@lead-routing` from this session's short-list because the change freeze and the absent admin capacity rule out the funnel-plumbing class",
        "Moves `mbfinotti/revops-skills@lead-routing` to the \"Not now\" list with admin capacity, or the end of the freeze on 2026-05-18, named as its unblocking condition",
        "Does not leave `lead-routing` ranked at the bottom of the short-list as a lower-priority option",
        "States that diagnosis absorbs this session instead, and short-lists diagnosis-class skills",
        "Notes that macro-design skills are untouched by a change freeze or by limited admin capacity because they change no configuration",
        "Names which recorded fact moved which class off its default position",
        "Appends exactly one new session-log line to `revops-context.md`",
        "Patches only the fields that changed rather than rewriting the whole artifact",
        "Leaves the inbound-SLA item under Open rather than moving it to Decided, since no stakeholder holding the decides role has signed it off"
      ]
    },
    {
      "id": 3,
      "prompt": "Quick one. At Bracco Analytics we have three things queued up for revenue ops and I want to know which of your skills handles each. First, we're sitting on roughly 41,000 duplicate account records after the Northvane acquisition and we need merge and survivorship rules. Second, marketing wants a multi-touch attribution model so they can claim channel credit properly. Third, we need to redraw the sales territories for next year - right now assignment is basically whoever gets there first.",
      "expected_output": "All three named as coverage gaps the collection does not cover, with no nearest-match skill stretched onto any of them and no invented skill promised.",
      "files": [],
      "expectations": [
        "States that the collection has no skill for record deduplication, including merge and survivorship rules",
        "States that the collection has no skill for attribution modeling",
        "States that the collection has no skill for territory design",
        "Does not route record deduplication to `mbfinotti/revops-skills@crm-data-governance`",
        "Does not route attribution modeling to `mbfinotti/revops-skills@revenue-kpi-framework`, `mbfinotti/revops-skills@revenue-reporting`, or `mbfinotti/revops-skills@revenue-leakage`",
        "Distinguishes territory design from `mbfinotti/revops-skills@lead-routing`, noting that routing applies territory assignment rules to leads but does not design the territories themselves",
        "Does not invent, promise, or hint at a future skill for any of the three items",
        "Says plainly that no skill fits, rather than offering a partial or nearest match for any of the three",
        "Does not recommend `mbfinotti/sales-skills` or `mbfinotti/partnerships-skills` as the home for record deduplication or attribution modeling",
        "Every skill named anywhere in the answer is one of the 20 skills in the collection's routing table",
        "Names the gaps explicitly as gaps rather than as items to revisit later"
      ]
    },
    {
      "id": 4,
      "prompt": "Head of revenue ops at Torlassen Cloud. Three things on my plate this month. One: next year's quotas for the 22-person sales team plus a rebuilt comp plan - the current one pays the same accelerator on renewals as on new logo, which is nuts. Two: our channel partners and our AEs keep claiming the same deals and it turns into a fistfight every month. Three: the affiliate program we launched in January where the commission tiers clearly are not working. What do I use for each?",
      "expected_output": "Quota and comp design handed to mbfinotti/sales-skills, channel conflict and affiliate commission handed to mbfinotti/partnerships-skills, both framed as recommendations rather than gaps or dependencies.",
      "files": [],
      "expectations": [
        "Recommends installing `mbfinotti/sales-skills` for the quota setting and the compensation plan design",
        "States explicitly that quota setting and compensation plan design are not coverage gaps in this collection",
        "Recommends installing `mbfinotti/partnerships-skills` for the partner-versus-AE channel conflict",
        "Recommends `mbfinotti/partnerships-skills` for the affiliate commission structure",
        "Does not route the channel conflict to `mbfinotti/revops-skills@deal-desk-approval`",
        "States that `deal-desk-approval` governs discount and concession approval on a direct deal, not partner deal registration or channel conflict",
        "Does not route quota setting or compensation design to `mbfinotti/revops-skills@revenue-kpi-framework`",
        "Frames both sibling repositories as recommendations rather than dependencies, and states that this collection stays fully usable standalone",
        "Does not describe any of the three items as a gap with no home",
        "Names the sibling targets as a repository, or in `owner/repo@skill` form, rather than as bare skill names",
        "Does not invent a new skill inside `revops-skills` for any of the three items"
      ]
    },
    {
      "id": 5,
      "prompt": "Elgrenna Systems, B2B PLG - self-serve signup, workspace-based product, the sales team only touches accounts above 50 seats. I'm the first revops hire and I have a real mandate: full admin on the CRM, the CTO will sign off on anything I need, and this is my whole job for the next year, not a side project. No deadline pressure from anyone. Nobody here has ever defined what an MQL is, and the AEs mostly work whatever lands in their inbox. Give me the list of what to work on and in what order.",
      "expected_output": "A 5-8 entry short-list ordered by value per unit of effort with both sides named per line, re-ranked for PLG and for a standing mandate with sign-off, with people and stay-current skills absent entirely and the routing table left unranked.",
      "files": [],
      "expectations": [
        "Produces a short-list of between 5 and 8 skills",
        "Orders the short-list by value returned per unit of effort, highest ratio first, and states that ordering criterion out loud",
        "Gives every short-list entry one line naming both the bottleneck it attacks and what the session costs",
        "Does not order the short-list by cheapness, and does not order it by the routing table's row order",
        "Promotes standing rules, account health and macro design above their default positions because the user reported a standing horizon with admin access and sign-off available",
        "States that the standing-horizon-with-sign-off answer is what moved those classes",
        "Pulls `mbfinotti/revops-skills@lead-scoring` up inside the funnel-plumbing class as product-qualified scoring because the motion is PLG",
        "States that `mbfinotti/revops-skills@deal-desk-approval` is rewritten as promo and discount policy rather than a rep-facing approval matrix under a PLG motion",
        "Names the unit-of-analysis decision - lead, buying group, or workspace - as the first thing `mbfinotti/revops-skills@revenue-funnel` has to settle",
        "Excludes `mbfinotti/revops-skills@revops-hiring`, `mbfinotti/revops-skills@revops-career` and `mbfinotti/revops-skills@revops-radar` from the short-list entirely rather than placing them at the bottom",
        "Leaves the routing table unranked and does not present the collection's skills in a ranked order",
        "Does not present the short-list as a flat or equally-weighted set of options",
        "Routes the immediate task to exactly one skill in addition to producing the short-list",
        "Writes `revops-context.md` recording the PLG motion, the standing horizon and the effort ceiling"
      ]
    },
    {
      "id": 6,
      "prompt": "Nuvella Home - direct-to-consumer subscription boxes, everything self-serve, no AEs, no account managers. Our \"sales team\" is two people who answer support email. Couple of things are already settled internally so please don't reopen them: we keep one pipeline for everything, that was decided in January, and the lead scoring model is off limits because marketing owns it and they just rebuilt it from scratch. I want to know what's actually worth doing in revenue ops here over the next quarter.",
      "expected_output": "A short-list with the B2C-irrelevant skills and the decided skill deleted outright rather than demoted, Not now used only where an unblocking condition exists, and the decided items recorded in the artifact.",
      "files": [],
      "expectations": [
        "Deletes `mbfinotti/revops-skills@sales-to-cs-handoff` from the short-list because the motion is B2C/transactional with no named account-management motion to hand off to",
        "Deletes `mbfinotti/revops-skills@deal-desk-approval` from the short-list for the same B2C reason",
        "Removes `mbfinotti/revops-skills@lead-scoring` from the short-list outright because the user stated it is decided and off the table",
        "Does not rank any of those three at the bottom of the short-list as a lower-priority option",
        "States that a ruled-out skill is deleted rather than demoted, and gives the reason that a demoted skill silently reappears as scope later",
        "Places on the \"Not now\" list only skills that carry an explicit unblocking condition, and states that condition for each one placed there",
        "Does not mention ruled-out skills that carry no unblocking condition",
        "Names which stated fact removed which skill",
        "Produces a short-list of between 5 and 8 entries after the deletions",
        "Does not re-litigate the single-pipeline decision or the lead scoring model",
        "Records the single-pipeline decision and the lead scoring model under the \"Decided\" field of `revops-context.md`"
      ]
    },
    {
      "id": 7,
      "prompt": "Kastrup Meridian, B2B, about 60 reps. My agent setup here can run things on a schedule and I want this to basically run itself so I stop doing the same manual checks every week. Context you'll need: we already run a pipeline review every Monday morning with the whole sales team, our fiscal quarter closes March 31, and there are two scheduled jobs left over from last quarter that I'm fairly sure fire into a Slack channel nobody reads anymore. Set the automations up.",
      "expected_output": "A dry-run set of 2-4 routines ranked by attention per firing, each with one named output channel, the leftover jobs flagged for approval-gated deletion, the forecast diagnostic anchored before close, and the weekly hygiene pass demoted as a duplicate.",
      "files": [],
      "expectations": [
        "Proposes between 2 and 4 routines and never more than 4",
        "Shows every proposed routine as a dry run and gets approval before creating anything recurring",
        "Gives every proposed routine exactly one explicit output channel",
        "Does not use \"notify me\" as an output channel, or explicitly rejects it as one",
        "Lists the existing scheduled routines and flags the two leftover jobs as obsolete before adding any new routine",
        "Deletes the obsolete routines only after the user approves, rather than removing them unilaterally",
        "Includes the pre-close forecast diagnostic routine, invoking `mbfinotti/revops-skills@sales-forecast-diagnostic`",
        "Anchors the forecast diagnostic to the week before the March 31 close, never after it",
        "Includes the periodic re-invocation of this kickoff and matches its cadence to the project's own pace",
        "Demotes or omits the weekly pipeline hygiene pass because the team already runs a weekly pipeline review, rather than scheduling a duplicate sweep over the same deals",
        "Does not lead the proposal with the quarterly source refresh via `mbfinotti/revops-skills@revops-radar` on the grounds that it is cheap",
        "Orders the routine set by value per unit of standing effort and states that ordering out loud",
        "Names, for each proposed routine, both what it buys and what it costs per firing",
        "Records the surviving and new routines in `revops-context.md`"
      ]
    },
    {
      "id": 8,
      "prompt": "Working on revenue ops for Haldane Optics. The project is a git repo I share with two other ops folks, and my assistant setup has a persistent memory feature I'd like to use so I stop re-explaining everything every session. Here's the context up front: motion is B2B sales-led; our floor discount is 22% and anything past that needs the CFO; our biggest at-risk account right now is Pellworth Industrial; and our senior ops analyst Ines Barros is on 118k. Store all of that so you remember it next time.",
      "expected_output": "Answers written into revops-context.md first and memory derived from it, a git-repo memory directory with an index, the pricing, customer, personal and compensation values excluded with the exclusion stated up front, and no silent commit.",
      "files": [],
      "expectations": [
        "Writes the captured interview answers into `revops-context.md` first, then derives the memory entry from the artifact",
        "Never writes an answer straight into memory without passing through the artifact",
        "States that the artifact stays the source of truth because memory is invisible and unreviewable to teammates",
        "Chooses a `memories/` directory inside the project's git repository as the memory location, because the project already lives in a repository",
        "Creates an index file listing each memory entry with a one-line hook",
        "Excludes the 22% discount floor from memory",
        "Excludes the named at-risk customer Pellworth Industrial from memory",
        "Excludes the 118k compensation figure from memory",
        "Excludes the named individuals' personal data from memory",
        "States the exclusion rule explicitly at the first memory write rather than silently dropping the values",
        "Shows the memory diff and asks for approval before committing it to the repository",
        "Does not commit memory silently",
        "Does not choose a local, per-user memory store for a project shared with two teammates, and gives the reason that a per-user store forks the project state"
      ]
    },
    {
      "id": 9,
      "prompt": "Starting on revenue ops at Cindergate Robotics. Fair warning about the setup here: my tooling has no scheduling or automation feature at all, I can't get a CRM export out of the system until IT approves it next month, and I genuinely have no idea what version of anything I'm running. There IS a data dictionary in the repo - somebody documented every CRM field and its owner last year - plus a README describing our four pipeline stages and what each one means. Let's go.",
      "expected_output": "A cold/warm decision taken from the artifact's presence alone, version metadata degraded silently, exactly one calendar reminder as the scheduling fallback, and the short-list adjusted for the missing export and the already-written dictionary and stage docs.",
      "files": [],
      "expectations": [
        "Decides cold versus warm start solely from whether `revops-context.md` exists, and does not ask the user which it is",
        "Inventories the existing files - data dictionary, README, stage documentation - and does not ask interview questions those files already answer",
        "Does not block, warn, or ask the user about skill or collection version metadata",
        "Falls back to exactly one recurring calendar reminder because the harness has no scheduled routines",
        "Does not propose a set of 2 to 4 routines, and does not simulate a scheduler",
        "Phrases the fallback reminder as a RevOps check-in that re-runs this kickoff",
        "Removes the diagnosis-class entries that depend on record-level data from the short-list because no CRM export is readable",
        "Keeps `mbfinotti/revops-skills@pipeline-stage-definition-audit` available on the grounds that it reads stage definitions rather than records",
        "Drops or lowers `mbfinotti/revops-skills@crm-data-governance` because a data dictionary naming field owners already exists on disk",
        "Lowers the urgency of `mbfinotti/revops-skills@revenue-funnel` because written stage definitions already exist",
        "States which detected fact moved which short-list entry",
        "Reads the repository's git log where it is readable and infers project stage and pace from it"
      ]
    },
    {
      "id": 10,
      "prompt": "Ardenlow Group. We sell three ways - direct enterprise, a self-serve tier, and through a couple of resellers - and all three run on the same 6-stage pipeline. We sat down with the sales managers last week and went through the stage definitions, and honestly only one of the six (\"contract signed\") means anything a second person could check. The rest are things a rep does: \"discovery held\", \"proposal sent\", that kind of thing. Our forecast is a work of fiction as a result. What's the sequence here?",
      "expected_output": "Escalation to revenue-funnel rather than a stage audit, with the four-link chain listed in dependency order, one line per handoff, and the chain explicitly left unranked.",
      "files": [],
      "expectations": [
        "Routes the immediate task to `mbfinotti/revops-skills@revenue-funnel` rather than to `mbfinotti/revops-skills@pipeline-stage-definition-audit`",
        "Gives the escalation reason that a stage audit leaving fewer than two usable anchors escalates up to funnel design",
        "Also cites that several motions sharing one stage list is a `revenue-funnel` signal",
        "Proposes the chain `revenue-funnel` then `pipeline-stage-definition-audit` then `sales-pipeline-hygiene` then `sales-forecast-diagnostic`",
        "Lists the chain in execution order with one line per link stating what that link hands to the next",
        "Does not rank or reorder the chain by value, effort, or efficiency",
        "States that chain order is dependency order rather than efficiency order, because a later link consumes what the earlier one produces",
        "Does not start the chain at `pipeline-stage-definition-audit`",
        "Names the unit-of-analysis decision - lead, buying group, or account - as part of what `revenue-funnel` must settle",
        "Leaves the routing table unranked",
        "Does not route the immediate task to `mbfinotti/revops-skills@sales-forecast-diagnostic` despite the stated forecast problem",
        "Names every routed skill in `owner/repo@skill` form"
      ]
    },
    {
      "id": 11,
      "prompt": "Vandermeulen Care Group, B2B SaaS for clinics. Our customer health score reads green right up until accounts cancel - we lost four renewals last quarter and every one of them was sitting in the healthy band the week before. I want to rebuild the score. One thing I should probably mention: I genuinely cannot tell you who owns the CRM day to day. Marketing admins part of it, our BI person admins the rest, and account records live in the CRM, the billing system and the product database, and somebody will tell you each of those three is the real one. Nobody signs off on changes, people just make them.",
      "expected_output": "The immediate task routed to customer-churn-signals rather than health-score, health-score parked in Not now behind a validated register, and standing rules plus revenue-data-governance-strategy promoted to rung 1 over the stated session goal.",
      "files": [],
      "expectations": [
        "Routes the immediate task to `mbfinotti/revops-skills@customer-churn-signals`, not to `mbfinotti/revops-skills@customer-health-score`",
        "Gives the reason that a health score missing churn starts at signal discovery because the inputs are wrong before the combination is",
        "Places `mbfinotti/revops-skills@customer-health-score` on the \"Not now\" list with a validated signal register from `customer-churn-signals` named as its unblocking condition",
        "Promotes the standing-rules class to rung 1 of the short-list because nobody can name the day-to-day CRM owner or the sign-off",
        "States that this promotion overrides what the stated session goal wanted",
        "Adds `mbfinotti/revops-skills@revenue-data-governance-strategy` to the promoted set because the ambiguity spans systems rather than fields",
        "Distinguishes `revenue-data-governance-strategy`, which designates which system authors each object class, from `crm-data-governance`, which governs the fields inside the winning system",
        "Gives the promotion reason that every class below writes into a system with no agreed owner",
        "States which stated fact moved which class",
        "Notes that account health carries the longest lead time among the tactical classes, needing enough renewal history to backtest against and a validation window before anyone trusts the output",
        "Promotes the CRM field-governance review routine above the weekly pipeline hygiene pass, because the sweep has no agreed rules to sweep against",
        "Records the unresolved CRM ownership question in `revops-context.md`",
        "Names exactly one skill as the route for the immediate task"
      ]
    },
    {
      "id": 12,
      "prompt": "Ostrander Fintech. Our CFO wants 20% off GTM tooling spend this year. We're running eleven tools - two of them overlap almost completely on data enrichment, and both our CRM and our customer data platform claim to be the master record for accounts. The big renewal cluster, four contracts including the expensive one, all comes up on June 30, which is about five weeks out. We already keep a contract and spend export in the repo, finance dumps a fresh one there every quarter. Separately, one of our sales directors wants us to buy a CPQ tool and is asking me to evaluate it. What's the plan?",
      "expected_output": "Stack rationalization promoted to rung 1 on the renewal window with the on-disk contract export noted, the master-record question routed to revenue-data-governance-strategy and sequenced first, the CPQ evaluation named as a gap, and any renewal routine anchored ahead of the notice period.",
      "files": [],
      "expectations": [
        "Promotes `mbfinotti/revops-skills@revops-stack-rationalization` to rung 1 of the short-list because a renewal cluster falls inside the quarter",
        "States that a verdict landing after the auto-renewal date buys nothing for another contract year",
        "Notes that the contract and spend export already on disk removes most of the stack rationalization cost, and that this detected fact moved its position",
        "Routes the question of which system is the master record for accounts to `mbfinotti/revops-skills@revenue-data-governance-strategy`",
        "States that the source-of-truth designation has to be answered before the consolidation, because a consolidation must respect the designation table",
        "Proposes the chain `revenue-data-governance-strategy` then `revops-stack-rationalization` in that dependency order",
        "Names single-tool pre-purchase evaluation, the CPQ request, as a coverage gap no skill in the collection covers",
        "States that `revops-stack-rationalization` is a periodic portfolio review rather than a fit or cost checklist for one candidate tool",
        "Does not route the CPQ evaluation to `mbfinotti/revops-stack-rationalization` or to any other skill in the collection",
        "Does not invent or promise a pre-purchase evaluation skill",
        "Anchors any proposed renewal stack review routine a full notice period ahead of the renewal cluster, never at the June 30 renewal date itself",
        "Promotes the renewal stack review to rung 1 of the routine set for the same renewal-window reason",
        "States which stated fact moved which class or routine off its default position",
        "Names the contract termination notice and the data-deletion or export obligation as the compliance cost of cutting a tool"
      ]
    },
    {
      "id": 13,
      "prompt": "honestly i've just got this afternoon. our crm is a complete mess and i don't even know where to start. small company, 9 people, we sell a b2b scheduling tool. also my boss wants a dashboard showing pipeline by rep and conversion by stage, she's asked for it twice already. what do i do first?",
      "expected_output": "A capped cold-start interview that asks for the effort ceiling before ranking, a two-entry diagnosis-only short-list with macro design deleted, exactly one routine installed, and BI dashboard building named as a gap.",
      "files": [],
      "expectations": [
        "Treats this as a cold start and asks no more than 7 questions",
        "Asks the questions one per message, offering multiple-choice options where possible",
        "Asks explicitly about the effort ceiling and the one-off-versus-standing horizon before producing any ranking",
        "Cuts the short-list to two entries, both from the diagnosis class, because the user has hours only and wants a one-off",
        "Deletes macro design from the short-list outright for the same reason",
        "States which answer caused the cut",
        "Proposes exactly one routine, the periodic re-invocation of this kickoff, rather than the default two or a full set of four",
        "Names BI dashboard building as a coverage gap the collection does not cover",
        "States that `mbfinotti/revops-skills@revenue-reporting` defines the metric spine and narrative and `mbfinotti/revops-skills@revenue-kpi-framework` defines the metric tree, and that neither builds dashboards",
        "Does not route the dashboard request to `revenue-reporting` or to `revenue-kpi-framework`",
        "Routes the immediate task to exactly one skill, or says plainly that none fits and names the gap",
        "Writes `revops-context.md` with a session-log line before the session ends"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "run my revops check-in", "should_trigger": true },
    { "query": "Start a new RevOps project for our sales team.", "should_trigger": true },
    { "query": "which revops skill do I need to fix our MQL handoff?", "should_trigger": true },
    { "query": "Where do I start with RevOps here? The CRM is a mess.", "should_trigger": true },
    { "query": "I'm kicking off a revenue operations engagement next week - set me up.", "should_trigger": true },
    { "query": "new sales ops project, where do I begin", "should_trigger": true },
    { "query": "revops kickoff", "should_trigger": true },
    { "query": "Can you route this revenue operations task to the right skill?", "should_trigger": true },
    { "query": "periodic RevOps review time", "should_trigger": true },
    { "query": "do my quarterly revenue ops check in", "should_trigger": true },
    { "query": "I'm picking this revenue ops project back up after two months - catch me up and tell me what's next", "should_trigger": true },
    { "query": "they hired me as the first ops person here and I have no idea what to prioritise", "should_trigger": true },
    { "query": "our CRM is a disaster and I don't know what to fix first", "should_trigger": true },
    { "query": "which of your revenue operations skills applies to what I'm doing?", "should_trigger": true },
    { "query": "help me decide what revops work is worth doing this quarter", "should_trigger": true },
    { "query": "I've got a list of twelve revenue ops problems, tell me what order to attack them in", "should_trigger": true },
    { "query": "onboarding onto a new sales ops engagement - what context do you need from me?", "should_trigger": true },
    { "query": "resume the revops work we did last month", "should_trigger": true },
    { "query": "what should I work on first in revenue operations at a 40-person B2B company", "should_trigger": true },
    { "query": "route my crm task to whichever skill actually covers it", "should_trigger": true },
    { "query": "set up the project context file for our revenue ops work", "should_trigger": true },
    { "query": "I want a warm start next session - how should we track this project's state?", "should_trigger": true },
    { "query": "recurring revops review, please run it", "should_trigger": true },
    { "query": "there are five things broken in our funnel, which one do we attack first", "should_trigger": true },
    { "query": "give me the short list of revenue ops work worth doing", "should_trigger": true },
    { "query": "I need a skill chain for cleaning up our revenue process end to end", "should_trigger": true },
    { "query": "first session on a new revenue ops project", "should_trigger": true },
    { "query": "kick off revenue operations for Q3", "should_trigger": true },
    { "query": "we're standing up a RevOps function from zero, where do I start", "should_trigger": true },
    { "query": "my agent has a bunch of revops skills installed - which one fits this task?", "should_trigger": true },
    { "query": "what revops skill handles our forecast problem", "should_trigger": true },
    { "query": "can you tell me which skill to use for our pipeline stage definitions", "should_trigger": true },
    { "query": "not sure whether this is a scoring problem or a routing problem - what do I run", "should_trigger": true },
    { "query": "revenue ops project start", "should_trigger": true },
    { "query": "restart the revops session", "should_trigger": true },
    { "query": "I'd like a monthly rhythm for reviewing our revenue operations work", "should_trigger": true },
    { "query": "what's the plan for our revenue operations this quarter", "should_trigger": true },
    { "query": "help me scope a sales ops project for a PLG company", "should_trigger": true },
    { "query": "I've inherited the CRM and everything is on fire. triage this for me.", "should_trigger": true },
    { "query": "which skill covers 'sales rejects our MQLs'?", "should_trigger": true },
    { "query": "run the kickoff for the revops collection", "should_trigger": true },
    { "query": "our revenue processes are completely undocumented and I need a starting point", "should_trigger": true },
    { "query": "before we dive in, what do you need to know about our revenue setup?", "should_trigger": true },
    { "query": "we do this every quarter, the revops review. go.", "should_trigger": true },
    { "query": "bootstrap a context file for this revenue operations project", "should_trigger": true },
    { "query": "i want to resume where we left off on the crm project", "should_trigger": true },
    { "query": "what's the highest leverage revops thing I can do with four hours a week", "should_trigger": true },
    { "query": "tell me which revenue ops work I should skip entirely", "should_trigger": true },
    { "query": "I keep starting these sessions from scratch and re-explaining our revenue setup, fix that", "should_trigger": true },
    { "query": "sales ops kickoff for the new fiscal year", "should_trigger": true },
    { "query": "there's a revops-context.md in this repo, use it", "should_trigger": true },
    { "query": "our revenue operations are ad hoc. build me a roadmap of what to fix in what order.", "should_trigger": true },
    { "query": "which revops skill covers deal desk stuff?", "should_trigger": true },
    { "query": "new engagement: mid-market B2B, 30 reps, nothing documented. what do you need from me?", "should_trigger": true },
    { "query": "do I need the funnel skill or the stage audit skill for this?", "should_trigger": true },
    { "query": "set up recurring revops automations for this project", "should_trigger": true },
    { "query": "we're mid-project on the revenue ops work - re-route me, priorities changed", "should_trigger": true },
    { "query": "check in on our revenue operations project", "should_trigger": true },
    { "query": "I have no idea which of these twenty revops skills to use", "should_trigger": true },
    { "query": "what's first: scoring, routing, or governance?", "should_trigger": true },
    { "query": "help me plan a quarter of revenue operations work", "should_trigger": true },
    { "query": "revops triage please", "should_trigger": true },
    { "query": "our revenue ops has no owner and no plan, start us off", "should_trigger": true },
    { "query": "give me a prioritised backlog for revenue operations", "should_trigger": true },
    { "query": "first time using these revops skills - how do I start?", "should_trigger": true },
    { "query": "the team already uses your revops skills every day but this is a brand new client - anything I should do first?", "should_trigger": true },
    { "query": "our lead flow, our forecast and our churn are all broken. sequence it for me.", "should_trigger": true },
    { "query": "kick off the crm cleanup project properly", "should_trigger": true },
    { "query": "what do you need from me before we start on revenue operations", "should_trigger": true },
    { "query": "resume revops project, session 6", "should_trigger": true },
    { "query": "I want a standing monthly review of our revenue operations work", "should_trigger": true },
    { "query": "route me to the right skill for 'we have two ARR numbers'", "should_trigger": true },
    { "query": "help me figure out where revenue ops effort pays back fastest here", "should_trigger": true },
    { "query": "we're restarting the revenue ops workstream after the reorg", "should_trigger": true },

    { "query": "Set next year's quotas for our 22 AEs.", "should_trigger": false },
    { "query": "Redesign the sales comp plan so renewals stop paying the same accelerator as new logo.", "should_trigger": false },
    { "query": "Help me open this cold call to a VP of Engineering.", "should_trigger": false },
    { "query": "Write a discovery question set for a first call with a CFO.", "should_trigger": false },
    { "query": "Score the Trendale deal on MEDDPICC.", "should_trigger": false },
    { "query": "Rebut 'we already have a vendor' on a live deal.", "should_trigger": false },
    { "query": "Review this sales call transcript and coach the rep on it.", "should_trigger": false },
    { "query": "Map the champion and the economic buyer on the Halvorsen account.", "should_trigger": false },
    { "query": "Plan our concessions for the Halvorsen renewal negotiation.", "should_trigger": false },
    { "query": "Write the meeting recap email after today's demo.", "should_trigger": false },
    { "query": "Build a five-touch outbound cadence for our enterprise SDRs.", "should_trigger": false },
    { "query": "Test these three cold email subject lines against each other.", "should_trigger": false },
    { "query": "Define our ICP and size the addressable market.", "should_trigger": false },
    { "query": "What pipeline coverage ratio should we carry to hit 12M?", "should_trigger": false },
    { "query": "Design the sales org structure for a 40-person team.", "should_trigger": false },
    { "query": "Tier our target accounts for next year's campaign.", "should_trigger": false },
    { "query": "Which sales podcasts should I be subscribing to?", "should_trigger": false },
    { "query": "We're hiring an SDR manager - build the interview loop.", "should_trigger": false },
    { "query": "Design our partner tier structure with the benefits per tier.", "should_trigger": false },
    { "query": "Write the affiliate program terms and the commission structure.", "should_trigger": false },
    { "query": "Write the deal registration rules for our reseller channel.", "should_trigger": false },
    { "query": "Recruit 50 new affiliates this quarter.", "should_trigger": false },
    { "query": "Build an influencer campaign brief for the product launch.", "should_trigger": false },
    { "query": "Negotiate rates with a YouTube creator for a sponsored video.", "should_trigger": false },
    { "query": "Design referral incentives that don't get gamed.", "should_trigger": false },
    { "query": "Map our partner ecosystem and prioritise which alliances to chase.", "should_trigger": false },
    { "query": "Plan joint GTM with our biggest ISV partner.", "should_trigger": false },
    { "query": "Audit our affiliate payouts for fraud patterns.", "should_trigger": false },
    { "query": "Onboard a new reseller onto our partner portal.", "should_trigger": false },
    { "query": "Set up co-selling rules between direct sales and the channel.", "should_trigger": false },
    { "query": "Review partner performance against their program tier commitments.", "should_trigger": false },
    { "query": "Run the developer relations kickoff for our new project.", "should_trigger": false },
    { "query": "Which devrel skill do I need for our docs problem?", "should_trigger": false },
    { "query": "Start a new developer platform project - route me to the right skill.", "should_trigger": false },
    { "query": "Kick off planning for our developer conference.", "should_trigger": false },
    { "query": "Plan the agenda for our annual sales kickoff event in January.", "should_trigger": false },
    { "query": "Book the venue and the catering for SKO.", "should_trigger": false },
    { "query": "Write a project kickoff checklist for the engineering sprint.", "should_trigger": false },
    { "query": "Run a kickoff meeting for the new marketing campaign.", "should_trigger": false },
    { "query": "Kick off the customer onboarding for the Marwick account.", "should_trigger": false },
    { "query": "Which partnerships skill do I need for alliance prioritisation?", "should_trigger": false },
    { "query": "Route this developer advocacy task to the right skill.", "should_trigger": false },
    { "query": "Start a new SEO project and tell me what to audit first.", "should_trigger": false },
    { "query": "Kick off our community building programme on Discord.", "should_trigger": false },
    { "query": "Which advertising skill covers negative keywords?", "should_trigger": false },
    { "query": "Automate our CRM with Zapier so new form fills create contacts.", "should_trigger": false },
    { "query": "Sync our CRM into the data warehouse nightly.", "should_trigger": false },
    { "query": "Improve the user onboarding conversion rate inside the product.", "should_trigger": false },
    { "query": "Write a codebase onboarding guide for new engineers.", "should_trigger": false },
    { "query": "Set up the Predictable Revenue outbound specialisation model.", "should_trigger": false },
    { "query": "Build a buyer persona for a sales ops manager for our ABM campaign.", "should_trigger": false },
    { "query": "Onboard our new app into Azure AD.", "should_trigger": false },
    { "query": "Optimise the CRO of our free trial signup page.", "should_trigger": false },
    { "query": "Configure the routing rules in our Next.js app router.", "should_trigger": false },
    { "query": "Build the pipeline-by-rep dashboard in our BI tool - here's the table schema.", "should_trigger": false },
    { "query": "Write the SQL to pull closed-won deals by segment for last quarter.", "should_trigger": false },
    { "query": "Negotiate the renewal contract with our CRM vendor's legal team.", "should_trigger": false },
    { "query": "Migrate our opportunity records from the old CRM into the new instance.", "should_trigger": false },
    { "query": "Do our revenue recognition schedule under ASC 606.", "should_trigger": false },
    { "query": "Forecast cash flow for the next two quarters.", "should_trigger": false },
    { "query": "Set up SSO across all our GTM tools.", "should_trigger": false },
    { "query": "Write the job description for a backend engineer on the data team.", "should_trigger": false },
    { "query": "Run an NPS survey and analyse the verbatims.", "should_trigger": false },
    { "query": "Design the email nurture sequence for unconverted trials.", "should_trigger": false },
    { "query": "Build a customer onboarding curriculum for new accounts.", "should_trigger": false },
    { "query": "Write our data retention policy for GDPR.", "should_trigger": false },
    { "query": "Set up UTM tagging conventions for our paid campaigns.", "should_trigger": false },
    { "query": "Debug why our marketing automation webhook keeps returning 500.", "should_trigger": false },
    { "query": "Write the QBR slides for the Ferradale account.", "should_trigger": false },
    { "query": "Train the sales team on the new product release.", "should_trigger": false },
    { "query": "We're halfway through the stage audit - recalculate the stage-skip rate for stage 4.", "should_trigger": false },
    { "query": "Add three more signals to the churn register we built last session.", "should_trigger": false },
    { "query": "Re-run the hygiene sweep on this week's export and diff it against last week's.", "should_trigger": false },
    { "query": "Bump the round-robin weights we set yesterday for the two new reps.", "should_trigger": false }
  ]
}

# Context artifact - `revops-context.md`

One versioned file at the project root, committed with the project when it lives in git. Its existence is the cold/warm signal; its content is what the warm start reads instead of re-interviewing. Keep every field short - this file is read at every session start, so bloat taxes every session.

## Template

```markdown
# RevOps context

- **Updated**: <date> (session <n>)
- **Revenue motion**: <B2B sales-led | B2B PLG | B2C-transactional | mixed - one line of nuance>
- **CRM / system of record**: <which system is authoritative for what; who owns it day-to-day; who signs off on changes>
- **Stage set**: <current pipeline stages, one line, with a flag if definitions are contested>
- **In-flight work**: <what is being built or fixed right now, one line per item>
- **Decided**: <closed decisions, one line each - off the table>
- **Open**: <live questions, one line each>
- **Constraints**: <freeze windows, admin capacity, compliance frames, and the date the result must land by>
- **Horizon and effort ceiling**: <one-off fix | standing system - plus the hours per week, admin access and sign-off actually available>
- **Stakeholders**: <name/role → decision role: decides | consulted | informed>

## Session log

- <date> - <session goal> → <skill(s) used> → <outcome in one line>
```

## Worked example

```markdown
# RevOps context

- **Updated**: 2026-03-14 (session 4)
- **Revenue motion**: B2B sales-led, mid-market; PLG tier launching Q3
- **CRM / system of record**: CRM authoritative for deals and contacts; billing system authoritative for ARR. Owned day-to-day by Priya (RevOps analyst); changes signed off by the VP Sales.
- **Stage set**: 6 stages; exit criteria for stages 3-4 contested (rep-activity-based)
- **In-flight work**: stage exit-criteria rewrite (draft with VP Sales)
- **Decided**: keep single pipeline for both segments; no new custom fields until governance rules land
- **Open**: whether forecast categories move to buyer-evidence gating this quarter
- **Constraints**: change freeze last week of each quarter; result must land before Q1 close 2026-03-31
- **Horizon and effort ceiling**: standing system; one admin at ~4h/week; schema changes need VP Sales sign-off
- **Stakeholders**: VP Sales → decides; CFO → consulted (forecast changes); CS lead → informed

## Session log

- 2026-02-20 - map pipeline problems → pipeline-stage-definition-audit → 4 of 6 stages flagged rep-activity-based
- 2026-03-01 - draft new exit criteria → pipeline-stage-definition-audit → draft sent to VP Sales
- 2026-03-14 - pre-close hygiene pass → sales-pipeline-hygiene → 23 deals flagged, dispositions assigned
```

Why this works:

- Every field answers a question the next session would otherwise ask.
- The log line names goal, skill, and outcome so re-routing can build on it.
- Contested items are flagged, not silently smoothed over.

## Negative example - do not produce this

```markdown
# RevOps context

We are a fast-growing company modernizing our revenue operations across the
entire customer lifecycle. Our goal is operational excellence and alignment
between sales, marketing, and customer success. We use several tools. There
have been many discussions about the pipeline and various stakeholders have
opinions. Next steps: continue improving processes and revisit priorities.

## Notes

- Meeting happened on Tuesday, went well
- Figure out the CRM situation at some point
- Lots of ideas about scoring, routing, forecasting, dashboards, hiring...
```

Why this fails:

- No field answers a concrete question (which system is authoritative? who signs off? what is decided?), so the next session must re-interview anyway - the artifact exists but the start is still cold.
- "Various stakeholders have opinions" names no one and no decision role.
- The idea dump routes nowhere.
- Vague aspiration ("operational excellence") displaces the facts the router actually needs.

## Update rules

- Patch changed fields; never rewrite the whole file each session.
- Append exactly one session-log line per session, before the session ends.
- Move an item from **Open** to **Decided** only when the stakeholder with the _decides_ role has signed off - record who.
- Keep a separate ADR-style decision log only when contested decisions genuinely accumulate; until then the Decided/Open lists are the record.

# Routines - dry-run format, anchoring, cleanup

Applies only where the harness supports scheduled routines. Otherwise: one recurring calendar reminder ("RevOps check-in - re-run the revops kickoff") is the whole fallback - do not simulate a scheduler.

## Dry-run format

Show every proposed routine in this shape and get explicit approval before creating anything:

```
Routine:    <name>
Runs:       <trigger  -  anchored, see below>
Does:       <one line  -  which skill it invokes, on what input>
Outputs to: <explicit channel  -  team chat, issue tracker, document, email>
First run:  <date> (dry run  -  produces the output, creates nothing recurring yet)
```

Create the recurring version only after the user approves the dry-run output. A routine approved on its description alone still surprises on its first real output.

## Trigger anchoring

Anchor to the revenue calendar, not arbitrary dates, whenever the routine's value depends on timing. Listed in the same install order as `mbfinotti/revops-skills@revops-kickoff` § 7 - highest value per unit of standing effort first - so there is only ever one order to follow:

- Forecast diagnostic → the week before each close (compute from the fiscal calendar in `revops-context.md` constraints); anchor it to the board meeting date instead when that meeting, not the close, is what the number feeds
- Kickoff re-invocation → monthly or quarterly, whichever matches the project's pace from the git log
- Pipeline hygiene pass → weekly, on the team's pipeline-review day
- CRM field-governance review → monthly, after month-end close
- Source refresh via `mbfinotti/revops-skills@revops-radar` → quarterly

Prefer an event trigger over a schedule when the harness offers one and it fits better - e.g. run the hygiene pass when a fresh CRM export lands, rather than on a clock that may fire against stale data.

## Output channels

Every routine names exactly one channel its result lands in. "Notify me" is not a channel.

Good channels:

- A named team-chat channel.
- An issue in the project tracker.
- A section appended to a standing document.

If no channel can be named, the routine is not ready to exist.

## Cleanup

Before adding routines, list the existing ones and remove the obsolete:

1. List all scheduled routines the harness reports for this project.
2. Flag any anchored to a past quarter, a shipped project phase, or a skill/process no longer in use.
3. Show the flagged list; delete only with approval.
4. Record surviving and new routines in `revops-context.md` under in-flight work, so the next warm start knows what is already running.

Stale routines from a previous quarter fire noise; noise trains the user to silence notifications, which buries the one routine that mattered.

# Routing detail - revops-skills collection

Route only from the declared scopes below. Every "do not route here" line comes from the skill's own description, not from inference.

Nothing in this file is ranked, and nothing in it should be. Scope is a match test, not a ratio. Ranking lives in the kickoff's short-list and routine set, where several skills compete for one session (see `mbfinotti/revops-skills@revops-kickoff` § 4 and § 7).

Four skills sit at macro altitude:

- `revenue-funnel`
- `revenue-data-governance-strategy`
- `revenue-kpi-framework`
- `revops-stack-rationalization`

Each shares subject keywords with a tactical sibling and is separated from it by altitude, not by topic. Their boundary pairs below are the ones most often misrouted.

## Table of Contents

- [Per-skill signals](#per-skill-signals)
- [Boundary pairs](#boundary-pairs)
- [Ordered chains](#ordered-chains)
- [Sibling-repo recommendations](#sibling-repo-recommendations)
- [Coverage gaps (v1)](#coverage-gaps-v1)

## Per-skill signals

### `mbfinotti/revops-skills@revenue-funnel`

- Route here: design the revenue funnel model from scratch - settle what the model is for (process vs planning vs forecast) and what unit moves through it (lead, buying group, account), then the stage set, the cohort-based conversion assumptions behind the plan, and the marketing/sales/CS ownership handoffs; "design our funnel", "bowtie model", "demand waterfall", "set our conversion assumptions", no agreed stage set exists yet.
- Do not route here: auditing or rewording an existing stage set's exit criteria (`mbfinotti/revops-skills@pipeline-stage-definition-audit`), the routing or scoring logic inside a stage, or executing the handoff it designs.

### `mbfinotti/revops-skills@lead-scoring`

- Route here: design, validate, or recalibrate a lead scoring model; fit/engagement weighting, negative scoring, decay; set MQL/PQL thresholds and tiers; backtest against closed-won/lost; "our lead scores are wrong", "too many junk MQLs".
- Do not route here: lead routing or assignment - the finished score is an input to `mbfinotti/revops-skills@lead-routing`.

### `mbfinotti/revops-skills@lead-routing`

- Route here: assignment logic for inbound leads - rule precedence, lead-to-account matching, territory assignment rules, round-robin variants, fallback queues, SLA escalation, safe rollout of routing changes; "who gets this lead", leads sitting unworked in a queue.
- Do not route here: designing the lead score itself - it treats the score as an existing input.

### `mbfinotti/revops-skills@pipeline-stage-definition-audit`

- Route here: audit stage definitions against buyer-verifiable milestones; write stage exit criteria; stages named after rep activity ("demo scheduled", "proposal sent"); stage aging, conversion decay, stage-skip diagnostics; "our stages don't mean anything".
- Do not route here: redesigning the funnel from scratch; auditing individual deals within stages (that is `mbfinotti/revops-skills@sales-pipeline-hygiene`).

### `mbfinotti/revops-skills@sales-pipeline-hygiene`

- Route here: periodic, checklist-based audit of an active pipeline snapshot - stale deals against segment stage medians, close-date push anomalies, missing forecast-critical fields; exception list with per-deal dispositions; "clean up our pipeline", cleanup before a QBR.
- Do not route here: rewriting stage definitions or designing standing reminder automation - both out of its scope.

### `mbfinotti/revops-skills@sales-forecast-diagnostic`

- Route here: diagnose why an existing forecast is unreliable - stage inflation, sandbagging, deals without buyer evidence, mass-pushed close dates, wrong forecast categories, manager overrides, comp incentives rewarding bias; "why did we miss the forecast".
- Do not route here: designing the forecasting methodology itself - it only tests whether the number produced is real.

### `mbfinotti/revops-skills@revenue-leakage`

- Route here: trace where deals and revenue silently exit one specific funnel and size the loss in recoverable dollars - untracked steps, unworked leads, handoff gaps, mid-funnel stalls, billing and renewal misses; "where are we losing deals", "leaky funnel".
- Do not route here: auditing stage definitions (it takes them as given) or program-level patterns across funnels - it works one funnel instance.

### `mbfinotti/revops-skills@revenue-data-governance-strategy`

- Route here: org-wide revenue data authority - which system of record authors each object class and which source of truth is read for it, the identity-resolution spine, cross-team data contracts binding producers to consumers, where revenue metric definitions live and who signs them, federated ownership with a council and an escalation path; "finance and sales report different numbers", "we have two ARR numbers", "which system owns revenue data".
- Do not route here: field-level rules inside one CRM (`mbfinotti/revops-skills@crm-data-governance`), deciding which tools stay in the stack, or designing the metric set itself.

### `mbfinotti/revops-skills@crm-data-governance`

- Route here: field ownership, system of record per field, write precedence and conflict rules, freshness SLAs, field request-approval-deprecation lifecycle, governance cadence; "who owns this CRM field", "which system wins", field sprawl, picklist governance.
- Do not route here: deduping records, sweeping stale deals, or designing stages - it writes the rules those enforce.

### `mbfinotti/revops-skills@deal-desk-approval`

- Route here: deal desk design - tiered discount approval matrix, delegation of authority across concession levers, margin floors, exception intake, SLA clocks, precedent control; discount creep; the PLG/B2C promo-policy equivalent.
- Do not route here: business-process approvals outside the deal desk (e.g. CRM field approvals belong to `mbfinotti/revops-skills@crm-data-governance`).

### `mbfinotti/revops-skills@customer-churn-signals`

- Route here: assemble, operationally define, validate, and rank leading churn indicators into a ranked signal register - event, threshold, window, lift, lead time, coverage; "which signals actually predict churn", "our health score misses churn" (the discovery half).
- Do not route here: combining signals into one composite score, tiers, or CS playbooks - that is `mbfinotti/revops-skills@customer-health-score`.

### `mbfinotti/revops-skills@customer-health-score`

- Route here: design, validate, govern a composite health score - weighting, normalization, decay, bands, churn-risk and expansion flags, backtesting, recalibration; "green accounts keep churning".
- Do not route here: discovering which indicators predict churn - `mbfinotti/revops-skills@customer-churn-signals` owns discovery; this skill owns how signals combine.

### `mbfinotti/revops-skills@sales-to-cs-handoff`

- Route here: design and enforce the sales-to-CS handoff - gated closed-won trigger, required handoff packet, timing SLAs, kickoff meeting pattern, CS acceptance/rejection; "the CSM starts from zero", "customers repeat themselves after signing".
- Do not route here: a CSM running one individual handoff; onboarding curriculum; health scoring - it ends when the customer is received and the first-value clock runs.

### `mbfinotti/revops-skills@revenue-kpi-framework`

- Route here: design the org-wide revenue KPI framework - pick the top-of-tree outcome, decompose it into a reconciling metric tree with explicit math, name one owner per branch, pair each owned number with a guardrail counter-metric, and gate the set by company stage and business model; "which metrics should each level track", "revenue KPI tree", "pick our North Star and driver metrics".
- Do not route here: writing the board or exec report against the framework (`mbfinotti/revops-skills@revenue-reporting`), governing where metric definitions live and who signs them, or building dashboards.

### `mbfinotti/revops-skills@revenue-reporting`

- Route here: metric set and narrative for an exec/board revenue report - stable metric spine, locked definitions, plan vs actual vs forecast, presenting a miss, reconciliation and sign-off, reporting cadences; QBR revenue section, investor update.
- Do not route here: building a dashboard in a BI tool or designing the org-level KPI hierarchy - both out of its scope.

### `mbfinotti/revops-skills@revops-stack-rationalization`

- Route here: periodic portfolio review of the whole GTM/RevOps tool stack - four-channel inventory (finance, procurement, SSO, expense), function-level overlap map, TIME scoring, a keep/consolidate/replace/cut verdict per tool timed to its renewal window, and the governance that stops re-sprawl; "too many sales and marketing tools", "SaaS sprawl", "cut tooling spend", "platform vs point solutions".
- Do not route here: evaluating one candidate tool before purchase - a narrower pre-purchase job this skill excludes and no v1 skill covers; contract or legal negotiation; executing the migrations it recommends.

### `mbfinotti/revops-skills@revops-hiring`

- Route here: the hiring-manager side - archetype and level decision, outcome scorecard, interview stage map with question bank, work-sample exercise with rubric, 30-60-90 ramp plan.
- Do not route here: sourcing candidates, posting jobs, applicant tracking, or the candidate side - interview prep for someone seeking a role is `mbfinotti/revops-skills@revops-career`.

### `mbfinotti/revops-skills@revops-career`

- Route here: the candidate side - ladder placement by scope, competency gaps, evidence of structurally invisible work, the four RevOps interview exercises, compensation ask; "how do I break into RevOps".
- Do not route here: anything on the hiring side of the table - that is `mbfinotti/revops-skills@revops-hiring`.

### `mbfinotti/revops-skills@revops-radar`

- Route here: staying current - a time-budgeted watch list of RevOps podcasts, newsletters, communities, events, and people, with freshness verification and a refresh routine.
- Do not route here: any operational RevOps task. A user who asks how to _do_ something routes elsewhere; a user who asks what to _read or follow_ routes here.

### `mbfinotti/revops-skills@revops-kickoff`

- Route here: project start, periodic check-in, "which skill do I need", re-routing mid-project. This skill routes; it never performs a sibling's job itself.

## Boundary pairs

Where two or more siblings collide on keywords, decide from these declared-scope boundaries:

- **lead-scoring vs lead-routing** - scoring designs the number; routing consumes it to assign leads to reps. "Is the score right?" → scoring. "Who gets the lead?" → routing.
- **customer-churn-signals vs customer-health-score** - signals discovers and ranks individual indicators, ending at a validated register; health-score combines signals into one composite. "Which signals predict churn?" → signals. "How should signals roll up into one score?" → health-score. "Our health score misses churn" starts at signals (the inputs are wrong before the combination is).
- **revenue-funnel vs pipeline-stage-definition-audit vs sales-pipeline-hygiene vs revenue-leakage** - four different objects, at two altitudes. Revenue-funnel designs the _model_: which stages exist at all, what unit moves through them, and what conversion rates the plan assumes. Stage-definition-audit audits the _definitions_ inside an agreed model (exit criteria, buyer-verifiability). Pipeline-hygiene audits the _deals_ inside the existing stage set (staleness, pushes, missing fields). Revenue-leakage audits the _flow_ - where records exit one funnel and what the loss is worth - taking stage definitions as given. "We have no agreed funnel", "several motions share one stage list" → revenue-funnel. "Stages are meaningless" → pipeline-stage-definition-audit. "Pipeline is full of junk" → sales-pipeline-hygiene. "Deals disappear between stages" → revenue-leakage. An audit that leaves fewer than two stages usable as anchors escalates up to revenue-funnel.
- **revenue-data-governance-strategy vs crm-data-governance** - same word, two altitudes. Strategy designates which _system_ is authoritative per object class and binds producer teams to consumer teams by contract; crm-data-governance governs the _fields_ inside whichever system won. "Which system owns subscriptions?", "finance and sales quote different ARR" → strategy. "Who owns this field, how fresh must it be, who approves a new one" → crm-data-governance. A validation rule can force an opportunity to carry an ARR value but cannot make it match billing - which is why the field skill never scales up into the system one.
- **revenue-kpi-framework vs revenue-reporting vs revenue-data-governance-strategy** - three jobs over the same metrics. "What should each level track, and how does it reconcile up?" → kpi-framework. "Write the board section" → revenue-reporting. "Whose definition of ARR wins and who may change it?" → strategy.
- **revops-stack-rationalization vs the two governance skills** - rationalization rules on which _tools_ exist; the governance skills rule on which _data_ is authoritative and which fields are governed. "Do we still need this tool?" → rationalization. "Which of these two tools is authoritative for accounts?" → revenue-data-governance-strategy, and answer it first, since a consolidation must respect the designation table.
- **sales-forecast-diagnostic vs sales-pipeline-hygiene** - hygiene is the recurring data-cleanup sweep; sales-forecast-diagnostic asks whether the forecast number is real, separating data-quality from behavioral (sandbagging, overrides, comp bias) from genuine demand problems. A forecast miss caused purely by dirty data still starts at sales-forecast-diagnostic - it performs that separation, then hygiene remediates.
- **crm-data-governance vs sales-pipeline-hygiene** - governance writes the standing rules (ownership, system of record, freshness SLAs); hygiene runs the periodic sweep that catches violations. "Who owns this field / which system wins?" → governance. "Sweep the stale deals" → hygiene.
- **deal-desk-approval vs crm-data-governance** - both contain an approval workflow, over different objects. Approving a discount or non-standard deal term → deal-desk-approval. Approving a field request or schema change → crm-data-governance.
- **sales-to-cs-handoff vs customer-health-score** - handoff is the one-time post-close transfer process, ending when the customer is received; health-score is the ongoing scoring of the live account. Handoff's own scope states health scoring belongs to a sibling.
- **revops-hiring vs revops-career** - same interview loop, opposite sides of the table. Hiring manager building the packet → hiring. Candidate preparing for it → career.
- **revops-radar vs everything else** - radar curates information sources; every operational task belongs to another sibling. A question containing "newsletter", "podcast", "community", "who to follow", or "stay current" → radar; otherwise never.

## Ordered chains

Propose a chain only when the task genuinely decomposes this way; never fabricate a sequence. Each chain is listed in dependency order, not efficiency order - a later link consumes what the earlier one produces, so there is no ratio to rank.

- `revenue-funnel` → `pipeline-stage-definition-audit` → `sales-pipeline-hygiene` → `sales-forecast-diagnostic` - settle which stages exist and what unit moves through them, then fix what each one means, then clean the deals inside them, then test whether the forecast built on them is real. Start at the second link when an agreed stage model already exists: auditing exit criteria for a stage set nobody agreed writes good wording onto the wrong stages, hygiene against broken definitions flags the wrong deals, and a forecast diagnostic on a dirty pipeline can't separate data problems from behavior.
- `lead-scoring` → `lead-routing` - routing consumes the score as an input; a routing design around a broken score routes the wrong leads correctly.
- `customer-churn-signals` → `customer-health-score` → `sales-to-cs-handoff` - validated indicators feed the composite score; the score then informs what the handoff packet must carry about account risk.
- `revenue-data-governance-strategy` → `crm-data-governance` → `sales-pipeline-hygiene` - designate which system is authoritative per object class, then write the field rules inside the winning system, then sweep against them. Field rules written before the system question is settled encode the wrong system's values; sweeping without agreed rules re-litigates every exception.
- `revenue-data-governance-strategy` → `revops-stack-rationalization` - the designation table says which system must survive any consolidation. Cutting tools first can strand the authoritative store for an object class nobody re-designated.
- `revenue-kpi-framework` → `revenue-reporting` - the tree supplies the metric spine and the reconciling math; the report selects from it for one audience. A report assembled before the tree exists picks metrics that do not add up.

## Sibling-repo recommendations

`revops-skills` owns CRM/pipeline _system design_ - process, ownership, data governance. Two sibling `mbfinotti` collections cover adjacent ground this collection intentionally excludes. Recommend installing the sibling instead of stretching a task onto a skill above that doesn't cover it; never frame it as a dependency - this collection stays fully usable standalone.

### `mbfinotti/sales-skills` - sales-execution-tactical (deal-specific, in-the-moment)

Recommend the sibling repo, not a skill above, when the task is:

- Cold call scripting or opener design → `cold-call-opener`
- Discovery-call question sets → `sales-discovery-questions`
- Objection rebuttals for a live deal → `sales-objection-handling`
- Reviewing a call transcript or coaching one call → `sales-call-review`
- Mapping a specific deal's champion, economic buyer, or blockers → `deal-champion-mapping`
- Deal-level qualification red flags or MEDDPICC scoring → `deal-red-flags`, `meddpicc-scorecard`
- Negotiation concession planning or an ROI narrative for one deal → `negotiation-concession-planner`, `deal-value-calc`
- Outbound cadence, subject lines, deliverability, or personalization angles → `sales-outbound-sequence`, `cold-email-subject-line-tester`, `cold-email-deliverability`, `sales-outreach-personalization`
- Meeting recap emails → `sales-meeting-recap`
- SDR/AE hiring, career, or field radar → `sales-hiring`, `sales-career`, `sales-radar`

Recommend it for sales-leadership planning too - the macro decisions a CRO or VP Sales owns, which this collection excludes:

- Quota setting and compensation plan design → `sales-quota-setting`, `sales-comp-design`.
- Org structure and motion → `sales-org-structure`, `sales-motion`.
- ICP, market sizing, account tiering → `sales-icp-definition`, `sales-market-sizing`, `sales-account-tiering`.
- Coverage targets and capacity math → `sales-pipeline-coverage-modeling`.

Distinguish from this collection: `revops-skills` owns the _revenue system_ - funnel model, stage definitions, pipeline hygiene, forecast integrity, data authority, metric tree, and the tool stack under all of it. `sales-skills` owns the sales org's own plan and what a rep says inside one call or deal. "Design our funnel model" stays here; "set next year's quotas" and "help me open this cold call" go to the sibling.

Closest pair: `revenue-kpi-framework` (org-wide tree, every revenue function) against `sales-pipeline-coverage-modeling` (the coverage ratio behind the sales number) - the tree may carry that ratio, but it is derived on the sibling repo.

### `mbfinotti/partnerships-skills` - macro channel/partner strategy, plus affiliate/influencer/referral ops

Recommend the sibling repo, not a skill above, when the task is:

- Partner/channel ecosystem mapping, program design, or tiering → `partner-ecosystem`, `partner-channel-program`, `partner-tiering`
- Co-selling rules between direct and partner sales, or channel-conflict resolution → `co-selling-strategy`, `partner-channel-conflict`
- Partner enablement, alliance prioritization, partner economics, ecosystem expansion, marketplace strategy, joint GTM planning, or partner performance reviews → the sibling's macro skill set
- Affiliate program terms, commission structure, recruitment, onboarding, fraud detection, or payout audit → the sibling's affiliate-ops skills
- Influencer/creator sourcing, outreach, negotiation, campaign briefs, or measurement → the sibling's influencer-ops skills
- Referral incentive design or referral-abuse guardrails → `referral-incentive-design`, `referral-abuse-guardrails`

Distinguish from this collection: `mbfinotti/revops-skills@deal-desk-approval` governs _discount_ approval on a direct deal; a channel-partner deal-registration or conflict question is `co-selling-strategy`/`partner-channel-conflict` on the sibling repo, not this collection.

## Coverage gaps (v1)

No skill in the collection covers these. Name the gap; never promise or invent a skill:

- Record deduplication (merge rules, survivorship)
- Attribution modeling (multi-touch, channel credit)
- Territory design (lead-routing applies territory _assignment rules_ to leads; it does not design the territories)
- Single-tool pre-purchase evaluation (revops-stack-rationalization reviews the whole portfolio periodically; it is not a fit/cost checklist for one candidate tool)
- BI dashboard building (revenue-reporting defines metrics and narrative, revenue-kpi-framework defines the tree; neither builds dashboards)

Quota setting and compensation plan design are not gaps - they belong to `mbfinotti/sales-skills`; see below.

---
name: revops-kickoff
description: Before starting any RevOps or Sales Ops task, and at the start of every session on an ongoing RevOps project, run this first - it routes the task to exactly one skill of the revops-skills collection or says plainly that none fits, and bootstraps or resumes the project's shared, versioned context artifact so the next session starts warm instead of cold, ending in a short-list plus an ordered skill chain. Run it even when the collection's other skills are already used daily - a new project is a new context. Also use whenever the user mentions a revops kickoff, a new RevOps project, a revops project start, revops or crm skill routing, a periodic RevOps check-in, a recurring RevOps review, "which revops skill do I need", or "where do I start with RevOps" - even if they never name a skill, and even if the request looks like it already belongs to one specific skill. Do NOT use for routing quota-carrying sales tasks - use mbfinotti/sales-skills@sales-kickoff instead.
license: MIT
metadata:
  author: Maya-Beth Finotti
  version: "1.4.4"
---

# RevOps Kickoff

You are the entry point and router for the 20-skill revops-skills collection, which spans two altitudes: macro design skills that decide what the revenue system _is_, and tactical skills that operate inside it. Route the current RevOps task to exactly one sibling skill, or say plainly that none fits, and make the next session start warm instead of cold. Routing is the reason this skill exists; everything else here serves it.

Run this skill at every project start, even when the collection's skills are already used daily in another context - a new project is a new context, and daily familiarity with siblings does not replace the kickoff pass. On later sessions of the same project, re-run it to resummarize and re-route, never to re-interview.

## 1. Detect before asking

Every fact derivable from the environment is a question the user never has to answer. Run detection first; the interview cap only survives if it does.

1. Decide cold vs warm start from one signal only: does the context artifact `revops-context.md` exist in the project? Present → warm start. Absent → cold start. Never ask the user which one it is.
2. Read the repository's recent git log when the history is readable, and infer project stage and pace from it: commit frequency, what changed last, whether work stalled.
3. Inventory existing files - README, agent-instruction files, data dictionaries, stage documentation, `.github/` - so nothing already written gets re-asked.
4. If the harness exposes connectors or integrations, detect which are available - a CRM export, an analytics source, a ticketing system, meeting notes - and let their presence shape routing and routines. Describe the capability; never assume a specific product.
5. If the collection ships readable version metadata, note what changed since the last session. If it doesn't - the common case - degrade silently. Never block, warn, or ask about versions.

## 2. Interview - capped, tappable

On a cold start:

- Ask at most 5-7 questions.
- Ask one question per message.
- Offer multiple-choice options whenever possible.
- Spend questions only where detection came up empty - skip any question the file inventory or git log already answered.

1. "What revenue motion are we operating?" - (a) B2B sales-led, (b) B2B PLG / self-serve, (c) B2C / transactional, (d) mixed.
2. "What is the goal of this session - and is it the same as the project's goal?" Ask this on both cold and warm starts; a project goal never substitutes for today's goal.
3. "Who owns the CRM day-to-day, and who signs off on changes to it?" - capture both names/roles; they rarely coincide.
4. "Any hard constraints, and is there a date the result has to land by?" - (a) release/change freeze, (b) quarter close or month-end close: give the date, (c) limited admin capacity, (d) compliance or audit window, (e) none.
5. "Do you want a one-off fix out of this session, or a standing system - and what is your effort ceiling?" - (a) one-off, hours only, (b) one-off, a week of work is fine, (c) standing, a few hours every week from here, (d) standing, and I can get admin access and cross-team sign-off.
6. "What is already decided, and what is still open?" - one line each; decided items are off the table for re-litigation.

Questions 4 and 5 exist to order the output, not to describe the project: the landing date, the one-off-versus-standing answer and the effort ceiling are what re-rank the short-list (§ 4) and the routines (§ 7). Ask them here, never beside a ranking - by then the user has already committed to a path. Record all three in the artifact so the warm start re-ranks without re-asking them.

On a warm start, ask only the session-goal question. Everything else - including the date, the horizon and the effort ceiling that drive both rankings - comes from the artifact.

## 3. Route the task

Match the stated session goal against the declared scope of each skill below. Route to exactly one skill for the immediate task. Never force a match: when nothing fits, say so and name the gap instead of stretching the nearest skill.

This table is deliberately unranked, and must stay that way. Scope is a match test, not a ratio: a task either falls inside a skill's declared scope or it does not, and ordering the rows would invent a preference between skills that never compete for the same task. Ranking belongs one step later, in the short-list (§ 4), where several skills genuinely do compete for the same session.

| Skill                                                      | Route here when the task is…                                                                                                                                                                                        |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `mbfinotti/revops-skills@revenue-funnel`                   | Design the funnel model itself: which stages exist, what unit moves through them, the plan's conversion assumptions, who owns each handoff - no agreed stage set yet, or the model is wrong rather than the wording |
| `mbfinotti/revops-skills@lead-scoring`                     | Design, validate, or fix a lead scoring model; MQL/PQL thresholds; "sales rejects our MQLs"                                                                                                                         |
| `mbfinotti/revops-skills@lead-routing`                     | Assign inbound leads to reps: rule precedence, round-robin, territory assignment rules, routing SLAs - the score already exists                                                                                     |
| `mbfinotti/revops-skills@pipeline-stage-definition-audit`  | Audit stage definitions against buyer-verifiable exit criteria; stages named after rep activity                                                                                                                     |
| `mbfinotti/revops-skills@sales-pipeline-hygiene`           | Periodic audit of an active pipeline snapshot: stale deals, close-date pushes, missing fields                                                                                                                       |
| `mbfinotti/revops-skills@sales-forecast-diagnostic`        | Diagnose why an existing forecast misses: stage inflation, sandbagging, roll-up overrides                                                                                                                           |
| `mbfinotti/revops-skills@revenue-leakage`                  | Trace where records silently exit one specific funnel and size the recoverable loss                                                                                                                                 |
| `mbfinotti/revops-skills@revenue-data-governance-strategy` | Org-wide data authority: which system is source of truth per object class, cross-team data contracts, where metric definitions live, who arbitrates "we have two ARR numbers"                                       |
| `mbfinotti/revops-skills@crm-data-governance`              | Field ownership, system of record per field, freshness SLAs, field lifecycle and enforcement rules                                                                                                                  |
| `mbfinotti/revops-skills@deal-desk-approval`               | Discount/concession approval matrix and exception handling for non-standard deals                                                                                                                                   |
| `mbfinotti/revops-skills@customer-churn-signals`           | Discover, validate, and rank leading churn indicators into a signal register                                                                                                                                        |
| `mbfinotti/revops-skills@customer-health-score`            | Combine existing signals into one composite, weighted, banded account health score                                                                                                                                  |
| `mbfinotti/revops-skills@sales-to-cs-handoff`              | Design the sales-to-CS post-close handoff process, packet, and acceptance step                                                                                                                                      |
| `mbfinotti/revops-skills@revenue-kpi-framework`            | Design the org-wide metric tree: which metrics each level owns, how they reconcile upward, which guardrail counter-metric rides alongside each owned number                                                         |
| `mbfinotti/revops-skills@revenue-reporting`                | Metric spine and narrative for a board/exec revenue report, QBR section, or investor update                                                                                                                         |
| `mbfinotti/revops-skills@revops-stack-rationalization`     | Periodic portfolio review of the whole GTM tool stack: keep, consolidate, replace, or cut, tool by tool, timed to renewals                                                                                          |
| `mbfinotti/revops-skills@revops-hiring`                    | Hiring-manager side: scorecard, interview loop, work sample, 30-60-90 for a RevOps hire                                                                                                                             |
| `mbfinotti/revops-skills@revops-career`                    | Candidate side: RevOps career ladder, interview prep, evidence of invisible ops work                                                                                                                                |
| `mbfinotti/revops-skills@revops-radar`                     | Staying current: a watch list of RevOps sources, newsletters, communities, people to follow                                                                                                                         |
| `mbfinotti/revops-skills@revops-kickoff`                   | This skill: project start, periodic check-in, "which skill do I need", re-routing                                                                                                                                   |

Several sibling pairs genuinely collide on keywords. Four of them collide on altitude rather than on subject:

- `revenue-funnel` designs the stage model `pipeline-stage-definition-audit` audits.
- `revenue-data-governance-strategy` designates which system wins per object class while `crm-data-governance` governs the fields inside the winner.
- `revenue-kpi-framework` designs the metric tree `revenue-reporting` narrates.
- `revops-stack-rationalization` rules on which tools exist at all.

Route to the macro skill when the model, the authority map, or the metric set is what is missing or wrong; route to the tactical sibling when that model exists and the work happens inside it. Disambiguate strictly from each skill's declared scope - never from a guess about what a skill "probably" covers; a wrong disambiguation misroutes worse than none. Read `references/skill-routing.md` for the per-skill route/do-not-route signals, the boundary-pair disambiguations, the ordered chains, and the named coverage gaps - read it before routing any task that could plausibly match two skills.

Name the gap explicitly when the task needs something no skill covers. Collection v1 has no dedicated skill for:

- Record deduplication.
- Attribution modeling.
- Territory design.
- Single-tool pre-purchase evaluation.
- BI dashboard building.

Say "the collection has no skill for this" - never promise a skill exists or invent one.

Before naming a gap, check whether the task actually belongs to a sibling `mbfinotti` collection instead of this one:

- **Sales-execution-tactical** (cold calling, discovery calls, objection handling, negotiation concessions, deal-specific call coaching) or **sales-leadership planning** (quota setting, compensation plan design, sales org structure, ICP definition, market sizing, coverage modeling) → recommend installing `mbfinotti/sales-skills`.
- **Macro channel/partner strategy** (partner programs, co-selling, alliances, affiliate/influencer/referral operations) → recommend installing `mbfinotti/partnerships-skills`.

Frame either as a recommendation, never a dependency - this collection stays fully usable standalone. See `references/skill-routing.md` § Sibling-repo recommendations for the specific hand-off signals before recommending one.

## 4. Output shape

Deliver the routing result in this shape, every time:

1. **State summary** (warm start only) - exactly 5 lines from the artifact: motion, system of record, in-flight work, top open decision, active constraint.
2. **Route** - the one skill for the immediate task (or "no skill fits", plus the named gap).
3. **Short-list** - 5 to 8 skills relevant to this project right now, ordered by value returned per unit of effort, highest ratio first. Give each entry one line naming both sides: the bottleneck it attacks, and what the session costs. Never order by cheapness and never by the routing table's row order - see "Ordering the short-list" below.
4. **Chain** - when the task genuinely decomposes into an ordered sequence (e.g. `pipeline-stage-definition-audit` → `sales-pipeline-hygiene` → `sales-forecast-diagnostic`), list it in execution order with one line per link on what it hands to the next. Chain order is dependency order, not efficiency order - a later link consumes what the earlier one produces and cannot run before it, so ranking a chain adds nothing. Omit the chain when there isn't one - never fabricate a sequence.
5. **Not now** - skills that will matter later, each with its explicit unblocking condition (e.g. "`customer-health-score` - after `customer-churn-signals` delivers a validated register").
6. **Gap** - anything today's task needs that no skill covers, stated as a gap. When the gap is actually sales-execution-tactical or macro channel/partner-strategy work, recommend the matching sibling repo (`mbfinotti/sales-skills` or `mbfinotti/partnerships-skills`) instead of a bare gap statement - see § 3.

### Ordering the short-list

The user's question at that moment is never "which of these exists" but "which one do I run first, and is it worth the session". Only a ratio answers that. Default class order, highest value per unit of effort first:

1. **Diagnosis** - `revenue-leakage`, `sales-forecast-diagnostic`, `pipeline-stage-definition-audit`. Buys a named, evidenced answer to which of the classes below is actually the problem, instead of a hunch. Costs one session over records already exported; needs no admin access, no sign-off, and changes nothing that has to be rolled back.
2. **Funnel plumbing** - `lead-scoring`, `lead-routing`. Buys speed-to-lead and stops qualified leads sitting unworked in a queue. Costs a design session plus a CRM configuration change by whoever holds admin, and a staged rollout with a rollback path - and it only ever applies to leads arriving after it ships.
3. **Standing rules** - `crm-data-governance`, `deal-desk-approval`, `sales-to-cs-handoff`. Buys the rule every later sweep and every later exception is decided against: who owns a field, who may approve a concession, what the CS team must receive. Costs a drafting session plus cross-team sign-off outside RevOps, and a rule is reversible only by another negotiation.
4. **Stack rationalization** - `revops-stack-rationalization`. Buys back duplicate spend and one decided verdict per tool, out of a contract list finance already keeps. Costs an inventory pass across finance, procurement, SSO and expense records plus a tool owner per verdict - and the renewal calendar is the whole ratio: a verdict landing after the auto-renewal date buys nothing for another contract year.
5. **Recurring sweeps** - `sales-pipeline-hygiene`. Buys a pipeline whose numbers hold this quarter rather than only at close. Costs a session per sweep plus a rep chasing each disposition, and it never finishes - a standing job, not a fix.
6. **Account health** - `customer-churn-signals`, `customer-health-score`. Buys ranked, validated reasons an account is at risk while there is still time to act. Costs the longest lead time among the tactical classes: enough renewal history to backtest against, a validation window before anyone may trust the output, then recalibration.
7. **Reporting** - `revenue-reporting`. Buys a number an exec or a board acts on, and the sign-off that it is real. Costs the definition-locking negotiation across finance and sales, and buys little while the metrics feeding it are the ones the classes above have not fixed yet.
8. **Macro design** - `revenue-funnel`, `revenue-data-governance-strategy`, `revenue-kpi-framework`. Buys the model every class above operates inside: the stage set the plan is built on, the system that wins per object class, the metric tree each org level owns. Costs the most in the collection - cross-functional negotiation with finance, marketing and CS, a decision the whole company then reads from, and a payoff arriving a planning cycle after the work. Nothing here is reversible by RevOps alone.

`revops-hiring`, `revops-career`, and `revops-radar` sit outside this ladder rather than at the bottom of it. They answer a people or a stay-current question, not a revenue-system question; when that _is_ the session goal they are rung 1 by definition, and otherwise they do not belong on the short-list at all.

The axes disagree, which is exactly where the choice is hard:

- efficiency: `diagnosis > funnel plumbing > standing rules > stack rationalization > recurring sweeps > account health > reporting > macro design`
- value: `macro design > funnel plumbing > account health > standing rules > stack rationalization > recurring sweeps > reporting > diagnosis`
- effort: `macro design > account health > stack rationalization > standing rules > funnel plumbing > recurring sweeps == reporting > diagnosis`
- compliance cost: `macro design > stack rationalization > reporting > standing rules > account health > funnel plumbing > diagnosis == recurring sweeps (none)`, in that order:
  - A source-of-truth designation and a signed metric taxonomy set org-wide retention, residency and read-access terms that finance and legal both own.
  - Cutting a tool triggers a contract termination notice and a data-deletion or export obligation that lapses on the vendor's clock.
  - A board or investor number carries a finance sign-off and cannot be unsaid once issued.
  - Field-ownership and discount-authority rules encode who may read customer data and who may approve a concession, so both need the data-protection and delegation-of-authority review that owns them.
  - A churn model profiles named accounts on behavioral history whose retention basis someone must own.
  - Routing rules move customer records between owners and regions, which crosses data-residency lines in a multi-region CRM.

Recurring sweeps and reporting tie on effort genuinely: each is a recurring session over records and definitions already held, with nothing to configure, no admin access and nothing to roll back - one runs each sweep, the other each reporting cycle. Diagnosis and recurring sweeps tie at zero compliance cost for the same reason: both read records already held under an existing lawful basis and publish nothing outside the team.

Macro design leads on value and sits last on efficiency - the widest gap between two axes in the collection, because its payoff arrives a planning cycle after the work. Account health shows the same shape one notch down: it leads the tactical classes on value in any renewal-heavy business and still sits sixth on efficiency, because its output cannot be acted on until a validation window has passed.

That gap is exactly what the efficiency order starves: the foundational work. Macro design loses every round on a ratio - highest value, highest effort, slowest payoff - and `crm-data-governance` one rung up shows the same shape at smaller scale, with the highest coordination cost of the tactical classes and no visible output the week it lands. Left unpromoted, a ratio-first order re-runs cheap diagnostics forever while every sweep below re-litigates the same exceptions against a model nobody ever agreed.

Promote macro design to rung 1 outright, and standing rules with it, when the program is being designed rather than tuned:

- Finance and sales quote two different ARR numbers, or nobody can say which system wins per object class → `revenue-data-governance-strategy`.
- No agreed stage set, several motions share one stage list, or a stage audit leaves fewer than two usable anchors → `revenue-funnel`.
- Each org level tracks its own unreconciled numbers, or a planning cycle or board reset is opening → `revenue-kpi-framework`.
- Nobody can name who owns a field or which system wins (Q3 came back empty), the same exception reappears sweep after sweep, or a compliance or audit window (Q4d) is open → standing rules.

Default: open the short-list at class 1 and stay there until the diagnosis names a class below it. Move down exactly one class at a time, and never past a class whose absence the diagnosis flagged.

Delete a ruled-out class from the short-list; never demote it to last place, because a ruled-out skill parked at the bottom silently reappears as scope. When it has a stated unblocking condition it moves to the "Not now" list carrying that condition; when it has none, it is not mentioned at all.

The ordering is a default, not a law - it shifts with the motion and with who executes it. Re-rank against what the interview and the detection pass just established, and say out loud which answer moved which class:

- B2B PLG / self-serve (Q1b) pulls `lead-scoring` up inside funnel plumbing as product-qualified scoring, rewrites `deal-desk-approval` as promo and discount policy rather than a rep-facing approval matrix, and makes `revenue-funnel`'s unit-of-analysis decision - lead, buying group, or workspace - the first thing macro design has to settle.
- B2C / transactional (Q1c) deletes `sales-to-cs-handoff` and `deal-desk-approval` from the short-list unless a named account-management motion exists to hand off to.
- Nobody can name the day-to-day CRM owner or the sign-off (Q3) promotes standing rules to rung 1, whatever the session wanted - and `revenue-data-governance-strategy` with it when the ambiguity spans systems rather than fields. Every class below writes into a system with no agreed owner.
- A change freeze or limited admin capacity (Q4a/c) deletes funnel plumbing from this session's short-list; it moves to "not now", unblocked by admin capacity, and diagnosis absorbs the session. Macro design is untouched by either - it changes no configuration.
- A close date inside two weeks (Q4b) promotes `sales-forecast-diagnostic` and recurring sweeps, which both act inside that window, and demotes anything paying out over a quarter - account health, a governance rewrite, all of macro design - to "not now" with the close date as its unblocking condition.
- A renewal cluster or budget cycle inside the quarter promotes stack rationalization to rung 1; with every renewal more than two quarters out it drops below recurring sweeps, since no verdict can be acted on before then.
- A compliance or audit window (Q4d) promotes standing rules, reporting and `revenue-data-governance-strategy`, and lengthens account health without changing what it buys.
- "One-off, hours only" (Q5a) cuts the short-list to two entries from diagnosis and deletes macro design outright; "standing, admin and sign-off available" (Q5d) promotes standing rules, account health and macro design above their default place.
- A decided item (Q6) removes its skill from the short-list outright - do not rank what is off the table.
- Detection moves classes too: a git log showing months of stall points at diagnosis before any build; a data dictionary or written stage definitions already on disk delete their diagnosis and standing-rules entries and lower `revenue-funnel`'s urgency; no readable CRM export deletes diagnosis's data-dependent entries and leaves `pipeline-stage-definition-audit`, which reads definitions rather than records; a contract inventory or expense export already on disk removes most of stack rationalization's cost.

## 5. Context artifact

Create or update `revops-context.md` at the project root - one versioned file, committed with the project when the project lives in git. It is the single source of truth that makes the next start warm.

Its fields:

- Revenue motion.
- CRM and system-of-record facts.
- Stage set.
- In-flight work.
- Decided vs open.
- Constraints, including the date the result must land by.
- The one-off-versus-standing horizon and the effort ceiling.
- Stakeholders with their decision role.
- A session log.

The last three fields are what let a warm start re-rank the short-list and the routines without re-asking questions 4 and 5. See `references/context-artifact.md` for the template, a worked example, and a negative example.

- On warm start: read it, do not rebuild it. Produce the 5-line state summary, append a session-log line, and patch only fields that changed.
- Optionally patch the project's agent-instruction file with the project's invariants (motion, system of record, hard constraints) so every future session inherits them without loading this skill.
- Do not scaffold a working tree the project hasn't earned. Scaffold only what this session needs - premature structure hard-codes decisions the project hasn't made yet.
- Keep a decision log only when the project actually accumulates contested decisions; otherwise the "decided vs open" field is enough. An empty ceremony log goes stale and erodes trust in the artifact.

Update the artifact before the session ends, every session - an unwritten session is a cold start next time.

## 6. Memory

If the harness has persistent memory, derive memory entries from the context artifact - never the reverse. The artifact stays the source of truth because memory is invisible and unreviewable to teammates; a memory-first flow forks the project state per user.

- Persist interview responses to memory after the interview completes and before § 4 Output shape: write the captured answers into the context artifact first, then derive the memory entry from the artifact. Never write memory straight from the answer, and never skip the artifact because the answer felt obvious.

Memory lives in exactly one of three places, and all three need the same index file listing each entry with a one-line hook. They are not equivalent otherwise - pick from this order, highest value per unit of setup effort first:

1. **A `memories/` directory in the project's git repository.** Setup is a directory and an index file, teammates read it wherever they already read the project, and every change arrives as a reviewable diff. Costs the commit-approval step below, and what lands there is durable in history - removing a mistake means rewriting it.
2. **A team knowledge base.** Reaches the people who never open the repository and survives any single machine. Costs an access-and-permissions setup outside RevOps, and it drifts away from the artifact because nothing ties a page to a commit.
3. **Local to the user's environment.** Near-zero setup, and nobody else can read it. Use it only for a solo project, or for notes that must not leave the machine - a per-user store forks the project state the moment a second person joins.

- efficiency: `git repository > team knowledge base > local environment`
- reach: `team knowledge base > git repository > local environment`
- setup effort: `team knowledge base > git repository > local environment`

Default to the git repository whenever the project already lives in one; choose the knowledge base when the people who need the memory do not work in the repository.

- On warm start, diff memory against the artifact. When they diverge, propose reconciliation - artifact wins by default; ask before overwriting either.
- Never put into memory: named individuals' personal data, customer names or PII from CRM records, contract pricing and discount floors, compensation figures. State this exclusion at the first memory write.
- When memory lives in a git repository, never commit it silently. Show the diff and get approval first, every time.

## 7. Routines

If the harness supports scheduled routines, propose 2 to 4 - always as a dry-run shown to the user before anything is created, each with an explicit output channel. A routine without an output channel is noise the user silences within a week.

A routine's cost is not its setup but its attention per firing multiplied by how often it fires; its value is the decision it puts in front of someone while that decision is still open. Rank the candidates on that ratio, highest first, and propose from the top down:

1. **Pre-close forecast diagnostic** → `mbfinotti/revops-skills@sales-forecast-diagnostic`. Fires a handful of times a year, over the commit list the team assembles for that call anyway, and it is the only routine whose output can correct a number before it is committed upward. Anchor it the week before close, never after.
2. **Monthly or quarterly re-invocation of this kickoff.** Near-zero per firing, and it keeps the artifact and the routing table current - which is what stops every other routine firing at work that no longer exists. Match its cadence to the project's pace from the git log.
3. **Renewal-window stack review** → `mbfinotti/revops-skills@revops-stack-rationalization`. Fires a few times a year against the next renewal cluster, over a contract list finance keeps anyway, and it is the only routine whose output has to land before a date the vendor sets rather than one the team picks. Anchor it a full notice period ahead of each cluster, never at the renewal itself.
4. **Weekly pipeline hygiene pass** → `mbfinotti/revops-skills@sales-pipeline-hygiene`. Buys numbers that hold every week instead of only at close, and carries the highest standing cost in the set: the sweep is a session and each disposition needs a rep to act on it. Install it only where someone owns chasing the exception list.
5. **Monthly CRM field-governance review** → `mbfinotti/revops-skills@crm-data-governance`. Costs a monthly pass over field requests and freshness violations with the field owners present. Buys nothing in a month with no schema churn, and buys back the quarter in the month someone adds nine fields nobody owns.
6. **Quarterly source refresh** → `mbfinotti/revops-skills@revops-radar`. Four near-zero firings a year buying currency rather than an outcome.

- efficiency: `forecast diagnostic > kickoff re-invocation > renewal stack review > hygiene pass > governance review > source refresh`
- value: `hygiene pass > forecast diagnostic > renewal stack review > governance review > kickoff re-invocation > source refresh`
- effort: `hygiene pass > renewal stack review > governance review > forecast diagnostic > kickoff re-invocation == source refresh`
- compliance cost: `renewal stack review > governance review > hygiene pass == forecast diagnostic > kickoff re-invocation == source refresh (none)`, in that order:
  - A cut tool triggers a contract termination notice and a data-deletion or export obligation, both signed off outside RevOps and irreversible once the contract lapses.
  - A governance decision changes who may read and write customer fields, so it needs the data-protection owner's sign-off and is reversible only by another decision.
  - The hygiene and forecast outputs are both deal-level exception lists naming customers and amounts, so both need an output channel the team's data policy already covers, and neither triggers an approval.

The kickoff re-invocation and the source refresh tie on both axes for the same reason: each is one near-zero read, firing monthly or quarterly, needing nobody outside the person reading it, and each emits internal state or public sources naming no customer.

The source refresh is the cheapest candidate and the last one to install - the clearest proof that cheap and efficient are different orderings. The hygiene pass leads on value and sits third on efficiency, because what it costs is a weekly session plus a rep chasing every disposition it produces.

Default: rungs 1-2, which is two routines. Add the renewal stack review once a contract inventory exists, the hygiene pass once someone owns the exception follow-through, the governance review once schema churn is real. Never exceed 4 - the cap is what protects the routines that matter from the ones that fire into the void.

The ranking is a default, not a law; it shifts with the motion and with who executes it. Re-rank it against the interview:

- A close date inside two weeks (Q4b) means install the forecast diagnostic and nothing else until the quarter closes.
- A renewal cluster or budget cycle inside the quarter promotes the renewal stack review to rung 1, and a stack whose renewals all sit two quarters out demotes it below the hygiene pass.
- Limited admin capacity (Q4c) drops the governance review to quarterly.
- An unnamed CRM owner or sign-off (Q3) promotes the governance review above the hygiene pass, since the sweep has no rules to sweep against.
- A compliance or audit window (Q4d) promotes the governance review to rung 1.
- "One-off, hours only" (Q5a) means install one routine - the kickoff re-invocation - not four.
- A team already running a weekly pipeline review makes the hygiene pass a duplicate, so demote it rather than sweep the same deals twice.

Anchor triggers to the revenue calendar - quarter close, month end, board meeting date - rather than arbitrary dates whenever it fits. List and clean up obsolete routines left over from a previous quarter before adding new ones.

If the harness has no scheduled routines, fall back to one recurring calendar reminder ("RevOps check-in - re-run the revops kickoff") and stop there. See `references/routines.md` for the dry-run format, trigger anchoring, event-trigger preference, and cleanup checklist.

## 8. Invocation examples

- "Start a new RevOps project for our sales team."
- "Which revops skill do I need to fix our MQL handoff?"
- "Run my RevOps check-in."
- "Where do I start with RevOps here? The CRM is a mess."

## 9. Failure modes

- **Forcing a match.** Stretching the nearest skill onto a task it doesn't cover wastes a session and hides the gap. Say "none fits" and name the gap - or point at `mbfinotti/sales-skills`/`mbfinotti/partnerships-skills` when the task actually belongs to one of them (see § 3).
- **Re-interviewing on a warm start.** The artifact exists precisely so questions aren't repeated. Ask only the session goal.
- **Routing from a guessed scope.** Route only from the declared scopes in `references/skill-routing.md`; a plausible-sounding guess misroutes confidently.
- **Routing an altitude, not a subject.** The four macro skills share subject keywords with a tactical sibling each. Sending "our stages are meaningless" to `revenue-funnel`, or "we have two ARR numbers" to `crm-data-governance`, hands the user a session at the wrong altitude - the answer arrives correct and useless.
- **Uncapped interview.** Past 7 questions the kickoff becomes a form the user abandons. Detection, not questions, fills the gaps.
- **Routines with no output channel.** They fire into the void and get silenced, burying the one routine that mattered.
- **A flat short-list.** Six equal-looking options get picked by taste or by whichever sits first. Order by value per unit of effort and name both sides on every line, or the user cannot choose.
- **Leading with the cheapest option.** Cheap and efficient are different orderings, and only the second one answers "what first". A near-zero routine that buys near-zero is a rounding error, not a quick win.
- **Ranking the routing table or the chain.** Scope is a match test and a chain is a dependency order; imposing a ratio on either invents a preference that does not exist.
- **Demoting a ruled-out skill instead of deleting it.** A skill the interview took off the table, parked at the bottom of the short-list, reappears as scope two sessions later. Delete it, or move it to "not now" with its unblocking condition.
- **Memory committed silently.** Teammates can't review what they can't see land. Diff and approval, always.
- **Stale routing table.** Update this skill - table, `references/skill-routing.md`, boundary pairs, chains, gap list - whenever the collection changes: a skill added, renamed, removed, or re-scoped. A stale router sends users to skills that no longer exist, which is worse than no router at all.

## 10. Pass bar

Before ending the session, check every item. If any fails, fix it and re-check - do not close the session on a failing bar.

1. Every recommended skill's declared scope actually matches the stated task - re-read its description to confirm.
2. Zero routes to a name outside the 20 skills in the table above.
3. Interview stayed within its cap: at most 7 questions on cold start, only the session-goal question on warm start.
4. `revops-context.md` was written or updated, including a session-log line, before the session ended.
5. Every proposed routine was shown as a dry-run and has an explicit output channel.
6. The short-list and the routine set are both ordered by value per unit of effort, each entry naming the bottleneck it attacks and what it costs - and the re-rank was stated out loud whenever an interview answer moved something off its default place.
7. Every class the interview ruled out left the short-list entirely, rather than sitting at the bottom of it.
8. The routing table and any proposed chain were left unranked - match test and dependency order respectively.

## References

- `references/skill-routing.md` - per-skill route/do-not-route signals, boundary-pair disambiguations, ordered chains, coverage gaps, and sibling-repo (`mbfinotti/sales-skills`, `mbfinotti/partnerships-skills`) hand-off signals. Read before routing any ambiguous task.
- `references/context-artifact.md` - the artifact template, one worked example, one negative example.
- `references/routines.md` - dry-run format, revenue-calendar trigger anchoring, event triggers, cleanup checklist.