revops-kickoff

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

...