@event4u/agent-config 2.7.0 → 2.8.0

package/.agent-src/skills/gtm-launch/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: gtm-launch
+description: "Use when sequencing a launch — alpha / beta / GA waves, audience-by-wave logic, narrative beats per wave, engineering-readiness gates. Triggers on 'plan the launch', 'sequence GA'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, customer-segment, channel-stage]
+---
+
+# gtm-launch
+
+## When to use
+
+- A product, feature, or major capability is approaching ship-readiness and the team needs a wave plan (alpha → beta → GA) keyed to audience and proof, not a date on a calendar.
+- A launch is being planned date-first; the team needs to invert and plan readiness-first so an unmet gate stops a wave instead of leaking past it.
+- A previous launch landed soft and the retro names "no audience-by-wave logic" or "narrative beats unclear per wave" as the cause.
+
+Do NOT use to write announcement copy (route to `release-comms`),
+lock the message stack (route to `messaging-architecture`), or plan
+post-launch retention loops (route to `retention-loops`).
+
+## Cognition cluster
+
+- **Mental model 10 — Reversible vs. irreversible decisions.** A GA
+  wave is largely irreversible: rolling back narrative and audience
+  expectations after public launch costs more than re-shipping the
+  product. Alpha and beta are reversible; treat them as the
+  decision-quality buffer. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 10.
+- **Mental model 29 — Premortem.** Before the wave plan locks, write
+  the post-mortem of the launch as if it failed. The premortem
+  surfaces the gates that need to hold; the wave plan is the inverse
+  of that list. See `mental-models.md` § 29.
+- **Mental model 16 — Leading vs. lagging indicators.** Engineering-
+  readiness signals (error rate, latency, support-load) are leading;
+  pipeline lift is lagging. A wave plan that gates on lagging signals
+  ships into a soft floor. See `mental-models.md` § 16.
+- **Context-spine — product + customer-segment + channel-stage.**
+  Read the **product** slot for shippable scope, the
+  **customer-segment** slot for who hears the launch on which wave,
+  and the **channel-stage** slot for where each wave's audience lives
+  in the awareness → decision arc. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Inherit the message stack
+
+Identify the locked `primary-message.md`, `supporting-proofs.md`, and
+`audience-matrix.md` from [`messaging-architecture`](../messaging-architecture/SKILL.md).
+If the stack is missing or unstable, stop and route back. A launch
+plan without a locked message stack ships three different stories at
+three different surfaces.
+
+### Step 1: Run the premortem
+
+Write the launch post-mortem **as if it has already failed**. Three
+prompts: *"what did the segment hear that we did not say,"* *"what
+broke in the first 48 hours,"* *"what did the alternative say first
+and louder."* The premortem produces the failure-mode list the wave
+plan must neutralise.
+
+### Step 2: Define the gates per wave
+
+For each wave (alpha · beta · GA), define **entry gates** and **exit
+gates**:
+
+- *Alpha entry:* engineering-readiness signal threshold (error rate,
+  latency, instrumentation coverage). *Exit:* < N support tickets
+  per 100 sessions on the load-bearing flow.
+- *Beta entry:* alpha exit + audience-matrix proof exists for the
+  beta audience. *Exit:* leading indicator (activation, time-to-
+  first-value) clears threshold per `mental-models.md § 16`.
+- *GA entry:* beta exit + narrative beats locked for the public
+  segment. *Exit:* not applicable — GA is irreversible; the next
+  wave is *post-launch retention*, handed to `retention-loops`.
+
+### Step 3: Sequence the audience waves
+
+Audience waves are not seniority waves. They are **proof waves**.
+Each wave's audience is whichever segment generates the proof the
+*next* wave needs. Order:
+
+1. *Alpha audience* — the segment where the team can sit next to
+   the user. Proof: load-bearing flow does not break under real use.
+2. *Beta audience* — the segment whose adoption is the credibility
+   anchor for GA. Proof: a quotable reference and an activation
+   curve.
+3. *GA audience* — the full ICP segment from the `customer-segment`
+   slot. Proof: pipeline lift, narrative pickup, retention curve.
+
+### Step 4: Assign narrative beats per wave
+
+Each wave gets a narrative beat — the **one** thing the audience
+remembers. Alpha beat = trust signal (we are not winging it). Beta
+beat = proof signal (it works for someone like you). GA beat = the
+primary message from `messaging-architecture` Step 1. Beats stack;
+they do not contradict.
+
+### Step 5: Validate the plan against the premortem
+
+Validate each premortem failure mode against the wave plan: verify a
+specific gate or beat neutralises it. Any failure mode without an
+explicit neutraliser is a known leak — name it, do not bury it.
+Validation passes only when every premortem item is either
+neutralised or accepted-with-mitigation.
+
+### Step 6: Hand back
+
+Hand the artefacts to [`release-comms`](../release-comms/SKILL.md)
+for announcement-surface drafting, to
+[`editorial-calendar`](../editorial-calendar/SKILL.md) for cadence
+mapping, and to [`launch-readiness`](../launch-readiness/SKILL.md)
+for the merge-day checklist.
+
+## Related Skills
+
+**WHEN to use this**
+
+- The unit of work is the wave plan (alpha · beta · GA) with gates and beats, not a single announcement.
+- A launch needs readiness-gated sequencing instead of calendar-driven sequencing.
+- The team can name the message stack but not which audience hears which beat in which wave.
+
+**WHEN NOT to use this**
+
+- Writing the announcement copy or press surface — route to [`release-comms`](../release-comms/SKILL.md).
+- Locking the primary message and proofs — route to [`messaging-architecture`](../messaging-architecture/SKILL.md).
+- Pre-merge ops checklist (rollout, rollback, monitoring) — route to [`launch-readiness`](../launch-readiness/SKILL.md).
+- Post-launch retention design — route to [`retention-loops`](../retention-loops/SKILL.md).
+
+## When the agent should load this
+
+- "Plan the launch waves for the new pricing tier."
+- "Wir starten den GA — gib mir die Alpha-Beta-GA Sequenz."
+- "What are the entry gates for the beta wave?"
+- "Premortem the launch and rebuild the wave plan from the failure list."
+- "Sequence the audience waves around the proof we still need."
+
+## Output
+
+1. **`launch-premortem.md`** — three failure modes per prompt, ranked by carrying cost, each tagged with the wave that owns the neutraliser.
+2. **`wave-plan.md`** — three waves (alpha · beta · GA) with entry / exit gates, audience, leading-indicator threshold per wave.
+3. **`narrative-beats.md`** — one beat per wave (trust → proof → primary-message), with the line the team will not contradict on any surface during that wave.
+
+## Gotcha
+
+- Calendar-driven launches confuse a date with a gate. A date does not signal readiness; a gate does. The wave plan must hold even if the date slips two weeks.
+- "Friends-and-family alpha" is alpha-shaped theatre — it produces the wrong proof for the next wave. Recruit an alpha audience that exposes the load-bearing flow.
+- A premortem that produces only three failure modes was rushed; push for ten and keep the load-bearing three.
+
+## Do NOT
+
+- Do NOT write the announcement copy here — copy lives in `release-comms` downstream of locked beats.
+- Do NOT collapse alpha and beta to save calendar time — alpha and beta produce different proofs.
+- Do NOT lock GA without an explicit retention-loops handoff; an unowned post-launch fortnight is where most launches soften.
+
+## Runnable example
+
+Mid-market HR analytics tool launching workforce-analytics layer:
+
+- Premortem: (a) CFOs hear "another tool" not "retention saving"; (b) HRIS plug-in misconfigured under load; (c) reference customer quote not contractually approved by GA.
+- Wave plan — *Alpha:* 3 design-partner HR directors, gate = HRIS plug-in error-rate < 1 % under load. *Beta:* 10 HR leaders matching ICP, gate = activation curve hits 5 cohort-roll-ups per week. *GA:* full ICP segment, gate = quoted reference contractually approved.
+- Narrative beats — *Alpha:* "we sat next to you while it worked." *Beta:* "an HR director like you saved 7 hours last board-quarter." *GA:* primary message from `messaging-architecture` Step 1.
+- Hand-off → `release-comms` drafts the GA-wave surface; `retention-loops` owns the 30-day post-GA cohort.

package/.agent-src/skills/messaging-architecture/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: messaging-architecture
+description: "Use when shaping the primary message, supporting proofs, and audience-by-message matrix from a locked positioning frame — before any copy or launch beat. Triggers on 'tighten the message stack'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, customer-segment]
+---
+
+# messaging-architecture
+
+## When to use
+
+- Positioning is locked (four anchors + assumption ledger) and the next artefact — launch deck, homepage, sales narrative — needs a load-bearing message stack instead of one-off copy.
+- A team is shipping copy faster than it is shipping shared meaning; lines diverge across surfaces and the segment cannot recognise itself.
+- An audience-by-message matrix is missing and the same primary message is being shouted at three audiences who hear three different things.
+
+Do NOT use to write the copy itself (downstream of this skill),
+peer-vs-peer comparison (route to `competitive-positioning`), or
+launch sequencing (route to `gtm-launch`).
+
+## Cognition cluster
+
+- **Mental model 15 — Signal vs. noise.** Every message lands inside
+  an inbox that is already full. The primary message must clear the
+  segment's noise floor, not just be true. Estimate the noise before
+  drafting; without it, every line looks distinctive in the doc and
+  forgettable in market. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 15.
+- **Mental model 30 — Inversion.** Ask *"what is the strongest
+  message a credible alternative would land against us?"* The answer
+  exposes the proofs the message stack must carry, not the words.
+  See `mental-models.md` § 30.
+- **Context-spine — product + customer-segment.** Read the **product**
+  slot for the proofs the team can actually back; read the
+  **customer-segment** slot for the buyer's listening posture.
+  Architecture that exceeds the proofs available is fiction. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Inherit the positioning frame
+
+Open the `positioning.md` artefact ([`positioning-strategy`](../positioning-strategy/SKILL.md)
+Step 1 output). If the four anchors are missing or contested, stop
+and route back. Messaging architecture without a locked positioning
+frame is decoration — it will be rewritten the next quarter.
+
+### Step 1: Identify the primary message
+
+Identify the **one** sentence — the load-bearing claim
+that, if the segment remembered nothing else, would still trigger
+the right switch event. Structure:
+
+*"For \<segment\>, \<category\> that \<load-bearing benefit\>,
+instead of \<alternative\>."*
+
+The benefit must be the **switch-event benefit** — what changes the
+day they buy — not a feature list and not a brand attribute.
+
+### Step 2: Stack the supporting proofs
+
+Three proofs, ranked. Each proof is a sentence the team can defend
+with evidence (data, demo, reference, contract clause). Proofs that
+need adjective amplification (*"truly seamless"*, *"radically
+simple"*) are not proofs — they are the gap a proof would fill.
+
+Rank the proofs by **closing weight**: how much each moves the
+buyer's decision from *no* to *yes*. The order is the order of
+appearance in every downstream surface.
+
+### Step 3: Build the audience-by-message matrix
+
+Audiences are not segments — they are roles inside the segment
+(economic buyer, champion, end-user, finance, security). For each
+audience, fill: **what they fear · what they hope · what proof
+clears each.** The matrix forces the team to confront the surfaces
+where the primary message lands wrong on a role even when right on
+the segment.
+
+### Step 4: Validate against the noise floor and the inversion test
+
+Validate the stack on three checks:
+
+1. **Noise floor.** For the primary message, name three lines a
+   credible peer says today. If the primary message would not be
+   distinguishable when read alongside them, it is below the noise
+   floor — sharpen or drop.
+2. **Inversion.** Write the strongest counter-message a credible
+   alternative would land against us. Confirm at least one supporting
+   proof neutralises it; if none does, the stack is missing a proof.
+3. **Proof-coverage.** For every fear / hope cell in the matrix,
+   verify a proof exists. Cells without a proof are explicit gaps,
+   not silent omissions.
+
+### Step 5: Hand back
+
+Hand the three artefacts (see `## Output`) to
+[`gtm-launch`](../gtm-launch/SKILL.md) for launch-wave sequencing,
+[`editorial-calendar`](../editorial-calendar/SKILL.md) for cadence
+mapping, or [`fundraising-narrative`](../fundraising-narrative/SKILL.md)
+for capital-raising framing. Do **not** write the copy here — copy
+production is a downstream artefact.
+
+## Related Skills
+
+**WHEN to use this**
+
+- The unit of work is the message stack (primary + proofs + matrix), not a copy block.
+- Positioning is locked and downstream surfaces need a shared anchor.
+- Cross-audience messaging has scattered and the team cannot name a primary.
+
+**WHEN NOT to use this**
+
+- Locking the four-anchor positioning frame — route to
+  [`positioning-strategy`](../positioning-strategy/SKILL.md).
+- Peer-vs-peer ours-vs-theirs verdict table — route to
+  [`competitive-positioning`](../competitive-positioning/SKILL.md).
+- Launch-wave audience sequencing — route to
+  [`gtm-launch`](../gtm-launch/SKILL.md).
+- Voice attribute selection or tone-by-context matrix — route to
+  [`voice-and-tone-design`](../voice-and-tone-design/SKILL.md).
+
+## When the agent should load this
+
+- "Lock the message stack before we draft the launch deck."
+- "Wir brauchen eine primary message, keine Tagline."
+- "Build the audience-by-message matrix for the security buyer."
+- "Are our three proofs distinguishable from \<incumbent\>'s lines?"
+- "Inversion-check our messaging against the alternative."
+- "Our message has scattered across landing pages — re-anchor it."
+
+## Output
+
+1. **`primary-message.md`** — one sentence in the segment / category
+   / benefit / alternative shape, plus the load-bearing word and
+   why it is load-bearing.
+2. **`supporting-proofs.md`** — three proofs ranked by closing
+   weight, each with the evidence the team can defend it with.
+3. **`audience-matrix.md`** — one row per audience: fear · hope ·
+   proof-that-clears-each · primary-message variant if reframing is
+   needed.
+
+## Gotcha
+
+- A primary message everyone in the room agrees with on first read
+  is usually below the noise floor — agreement is consensus, not
+  distinctiveness.
+- Proofs that need adjectives are signals of a missing proof; replace
+  the adjective with the evidence or remove the line.
+- The audience matrix tempts the team to multiply primary messages.
+  Resist: the segment receives one primary; the matrix shapes
+  emphasis, not substitution.
+
+## Do NOT
+
+- Do NOT write copy in this skill — copy lives downstream.
+- Do NOT inflate the stack beyond three proofs; a stack of seven is
+  a wishlist, not architecture.
+- Do NOT skip the noise-floor check; an internally distinctive
+  message is not the same as a market-distinctive one.
+
+## Runnable example
+
+Mid-market HR analytics tool, positioning locked (segment: HR leaders
+at 200–2000-person growing companies; alternative: spreadsheet +
+HRIS report; PoV: retention beats acquisition):
+
+- Primary message: *"For HR leaders at growing 200–2000-person
+  companies, the workforce-analytics layer that turns the
+  board-quarter retention conversation into a one-click roll-up,
+  instead of a spreadsheet rebuild every quarter."*
+- Proofs ranked by closing weight: (1) cohort attrition by tenure
+  band in < 5 clicks (demo); (2) plugs into the existing HRIS,
+  not a replacement (architecture diagram); (3) board-quarter
+  rebuild collapses from \~ 8 hours to \~ 1 hour (reference
+  customer, contractually quoted).
+- Audience matrix — *Champion (HR director):* fear = another tool
+  to maintain; hope = looks competent to CEO; proof = HRIS
+  plug-in. *Economic buyer (CFO / COO):* fear = soft ROI; hope =
+  retention saving; proof = reference quote with hours saved.
+- Hand-off → `gtm-launch` sequences launch waves around the
+  retention-conversation moment in board-quarter cadence.

package/.agent-src/skills/onboarding-design/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: onboarding-design
+description: "Use when designing customer onboarding — time-to-first-value, milestone design, friction audit, drop-off diagnosis. Triggers on 'fix onboarding', 'why do new accounts churn fast'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, customer-segment, funnel-stage]
+---
+
+# onboarding-design
+
+## When to use
+
+- New accounts churn inside their first 30 days and the team cannot name which onboarding milestone they failed to reach — drop-off is treated as a single number, not a stage-by-stage signal.
+- A new segment is being onboarded against an onboarding flow built for a previous segment — the milestones likely do not match the new segment's switch-event shape.
+- Time-to-first-value is *"days, maybe weeks"* — the answer needs to be a number with a falsifiable definition, not a sentiment.
+
+Do NOT use to onboard employees (that is the Wing-4
+employee-onboarding program — different audience, different
+contract), diagnose long-cycle churn (route to
+`churn-prevention`), or run the full visitor → paid funnel (route
+to `funnel-analysis`).
+
+## Cognition cluster
+
+- **Mental model 14 — Meadows leverage points.** Onboarding is a
+  high-leverage system: a change in the milestone *definition*
+  reshapes retention more than a change in the welcome email. Pick
+  the leverage point — milestone definition over surface polish.
+  See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 14.
+- **Mental model 16 — Leading vs. lagging indicators.**
+  Time-to-first-value and milestone-completion are leading; D30
+  retention is lagging. Onboarding decisions built on lagging
+  signals can only confirm churn after it lands. See
+  `mental-models.md` § 16.
+- **Mental model 13 — Occam's razor.** When new accounts drop off,
+  the simpler explanation usually wins: *"the first milestone is
+  too far from the buyer's job to complete in one session"* beats
+  *"users do not understand our value proposition."* Pick the
+  simpler explanation; it changes the move. See
+  `mental-models.md` § 13.
+- **Context-spine — product + customer-segment + funnel-stage.**
+  Read the **product** slot for what the segment can actually
+  configure unattended, the **customer-segment** slot for the
+  segment's job and switch-event, and the **funnel-stage** slot for
+  where activation sits relative to signup and paid. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Inspect — pull the current onboarding shape
+
+Inspect the actual funnel: signup → milestone-1 → milestone-2 →
+activation → D30. For each transition pull conversion rate (with
+band) and median time-to-transition for the last two cohorts.
+Inspect whether the activation event correlates with paid retention;
+if not, the activation event is mis-defined and Step 2 fixes it.
+
+### Step 1: Define time-to-first-value with a falsifiable definition
+
+Write the sentence: *"\<Segment\> reaches first value when
+\<observable buyer action\> happens, by \<target hours / days\>
+after signup."* The action must be observable in instrumentation,
+must correlate with paid retention (Step 0 inspection), and must be
+something the buyer accomplishes — not something the product
+displays.
+
+### Step 2: Design three milestones earning activation
+
+Each milestone is a buyer action with a definition, a friction
+audit, and a default outcome.
+
+1. **Milestone definition** — one sentence in buyer-action form
+   (*"buyer has imported one record"*, not *"buyer has seen the
+   import screen"*).
+2. **Friction audit** — name the three highest-friction steps the
+   buyer must clear; each gets a *cheapest-fix* hypothesis.
+3. **Default outcome** — if the buyer does nothing, what does the
+   product do for them? A milestone with no default is a milestone
+   the busy half of the segment will miss.
+
+### Step 3: Audit friction at each milestone
+
+For each milestone, time the buyer journey: clicks, fields, decision
+points, wait states. Tag each as *blocker* (cannot proceed without
+it), *toll* (proceed but slow), or *fog* (buyer unsure what to do
+next). Fog kills more onboarding than blockers — fog is silent.
+
+### Step 4: Diagnose drop-off by segment × milestone
+
+The drop-off is rarely uniform. Segment by segment × milestone;
+the cell with the steepest below-band drop is the binding fix.
+Two cells dropping at once usually means a shared upstream cause
+(account-provisioning failure, ICP mismatch) — fix upstream, not
+in the milestone.
+
+### Step 5: Hand back
+
+Hand the time-to-first-value definition, the three milestones with
+friction audits, and the segment × milestone drop-off table to the
+implementing team and to
+[`churn-prevention`](../churn-prevention/SKILL.md) for downstream
+health-score signal definition. Onboarding owns days 0–30;
+churn-prevention owns the signals after.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Designing or auditing days 0–30 of the customer lifecycle.
+- Defining time-to-first-value as a falsifiable event, not a sentiment.
+
+**WHEN NOT to use this**
+
+- Long-cycle churn diagnosis (D60+) — route to
+  [`churn-prevention`](../churn-prevention/SKILL.md).
+- Account expansion or upsell mechanics — route to
+  [`expansion-playbook`](../expansion-playbook/SKILL.md).
+- Full visitor → paid funnel diagnosis — route to
+  [`funnel-analysis`](../funnel-analysis/SKILL.md).
+- Activation-event redefinition or aha-moment selection — route to
+  [`activation-design`](../activation-design/SKILL.md).
+
+## When the agent should load this
+
+- "Fix our onboarding — new accounts churn fast."
+- "Why does cohort-9 drop at milestone-2?"
+- "Define time-to-first-value for the mid-market segment."
+- "Wie viele Klicks bis zum ersten Wert?"
+
+## Output
+
+1. **`time-to-first-value.md`** — falsifiable definition: segment × observable action × target time × correlation with paid retention.
+2. **`milestones.md`** — three milestones, each with definition · friction audit (blocker / toll / fog) · default outcome.
+3. **`dropoff-table.md`** — segment × milestone conversion rates with bands; binding-fix cell flagged.
+
+## Gotcha
+
+- An activation event that does not correlate with paid retention is a vanity event. The funnel will look healthy and D30 will keep dropping.
+- *"Onboarding emails"* is not onboarding design. Emails are a surface; milestones are the system. Designing emails before milestones is rearranging deck chairs.
+- A milestone without a default outcome assumes the buyer drives the journey. Half of every segment will not — design for the half that will not.
+
+## Do NOT
+
+- Do NOT use industry-average onboarding benchmarks as targets; segment shape and product complexity dominate them.
+- Do NOT confuse signup with activation; signup is consent, activation is value.
+- Do NOT redesign milestones one at a time mid-cycle without an A/B holdout — concurrent changes destroy the signal.
+
+## Runnable example
+
+B2B mid-market analytics tool, D30 retention sagging from 71 % to 58 % over two quarters.
+
+- Time-to-first-value — *"Mid-market: buyer reaches first value when one connected data source returns one rendered dashboard, within 24 hours of signup."* Correlation with D90 paid retention: r = 0.62.
+- Milestones — *(1)* connect data source (friction: OAuth scope confusion = fog; default: paste-CSV fallback). *(2)* save first query (friction: schema picker = toll; default: starter-template per segment). *(3)* share dashboard with one teammate (friction: invite-flow buried = blocker; default: auto-invite admin).
+- Drop-off table — Mid-Market × milestone-1: 41 % conv (band 35–47, vs trailing-cohort median 62 %). Binding fix: OAuth fog at milestone-1.
+- Hand-off — milestones + drop-off → eng team for OAuth-fog fix; `churn-prevention` picks up D30+ health-score signals.

package/.agent-src/skills/pipeline-strategy/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: pipeline-strategy
+description: "Use when designing or auditing a sales pipeline — stage exit criteria, per-cell conversion, coverage reasoning, leak detection. Triggers on 'tighten our pipeline', 'where is the leak'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, customer-segment, channel-stage]
+---
+
+# pipeline-strategy
+
+## When to use
+
+- Pipeline stages are named but have no exit criteria — reps move deals on gut and forecasts ride on opinion, not evidence.
+- Coverage is being computed from a flat multiple (*"3x quota"*) without per-stage conversion rates, so the multiple flatters or punishes the team at random.
+- A board ask names *"why did pipeline coverage look fine and the quarter still missed?"* — a leak is hiding inside a healthy-looking total.
+
+Do NOT use to qualify a single deal (route to
+`deal-qualification-meddic`), construct the forecast call from a
+locked pipeline (route to `forecast-accuracy`), or configure
+CRM stage fields in a specific vendor tool (out of scope — this
+skill is strategy, not tooling).
+
+## Cognition cluster
+
+- **Mental model 6 — Theory of constraints.** A pipeline has one
+  binding stage at any time; rates upstream of the constraint are
+  inventory that never ships, rates downstream cannot exceed the
+  constraint. Find the constraint before changing anything else. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 6.
+- **Mental model 16 — Leading vs. lagging indicators.** Stage-to-stage
+  conversion is leading; closed-won is lagging. A coverage call built
+  on lagging signals can only confirm the miss after it lands. See
+  `mental-models.md` § 16.
+- **Mental model 3 — Pareto (80/20).** ~20 % of segment × stage cells
+  carry ~80 % of revenue risk. Coverage uniformly applied across cells
+  is theatre; coverage weighted by cell-level conversion is reasoning.
+  See `mental-models.md` § 3.
+- **Context-spine — product + customer-segment + channel-stage.**
+  Read the **product** slot for what is actually sellable this
+  quarter, the **customer-segment** slot for which segments belong in
+  pipeline (and which are pre-pipeline education), and the
+  **channel-stage** slot for where each segment enters. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Inspect — inventory the current pipeline shape
+
+Pull stage counts, $ value, age in stage, and stage-to-stage
+conversion for the trailing two quarters. Inspect whether each
+stage has a written exit criterion; if not, write one now (one
+bullet per stage, falsifiable). A pipeline without exit criteria
+cannot be audited.
+
+### Step 1: Lock stage definitions with exit criteria
+
+Each stage gets three lines:
+
+1. **Definition** — what the deal looks like in this stage (one sentence).
+2. **Entry trigger** — the buyer event that moves a deal in (not a rep action).
+3. **Exit criterion** — the artefact or signal that proves the deal earned the next stage (one bullet, falsifiable; *"meeting booked"* is not falsifiable, *"economic buyer named and confirmed"* is).
+
+Reject any stage whose exit criterion is a rep activity ("call
+made") rather than a buyer signal ("buyer confirmed budget owner").
+
+### Step 2: Compute per-stage conversion rates with bands
+
+For each stage transition, compute the trailing-quarter rate and a
+95 % confidence band. Segment by customer-segment (and channel-stage
+if the channel mix changed). Report the band, not the point — a
+30 % rate on 12 deals and a 30 % rate on 300 deals are different
+signals.
+
+### Step 3: Find the binding constraint
+
+The constraint is the stage whose conversion rate is **furthest
+below its segment-historical median, weighted by $ value flowing
+through it**. Add deals upstream of any other stage and watch them
+queue; add deals upstream of the constraint and they queue twice as
+fast. A pipeline-coverage call that ignores the constraint
+multiplies inventory the team cannot ship.
+
+### Step 4: Compute coverage cell by cell, not by total
+
+Coverage = (pipeline $ at stage *s*) ÷ (target closed-won $ in
+window) ÷ (cumulative conversion from *s* to closed-won). Compute
+per segment × stage cell. A 3× total can hide a 0.8× cell — the
+0.8× cell is the quarter's risk.
+
+### Step 5: Name three leaks with falsifiable hypotheses
+
+For the three lowest coverage cells (or the three steepest
+conversion-rate drops vs trailing-quarter median), write one
+sentence per leak: *"\<cell\> leaks at \<stage\> because \<cause\>;
+falsified if \<test\> shows \<expected signal\>."* If a cause is
+not testable in under two weeks, the hypothesis is not yet sharp
+enough — sharpen before recommending a fix.
+
+### Step 6: Hand back
+
+Hand the locked stages, the per-cell coverage table, and the three
+leak hypotheses to
+[`forecast-accuracy`](../forecast-accuracy/SKILL.md) for
+commit / best-case categorisation, and to
+[`deal-qualification-meddic`](../deal-qualification-meddic/SKILL.md)
+when the leak is upstream qualification, not late-stage execution.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Designing or auditing pipeline stages and per-stage rates.
+- Computing coverage by segment × stage instead of by total.
+
+**WHEN NOT to use this**
+
+- Single-deal qualification — route to
+  [`deal-qualification-meddic`](../deal-qualification-meddic/SKILL.md).
+- Forecast call construction from a locked pipeline — route to
+  [`forecast-accuracy`](../forecast-accuracy/SKILL.md).
+- Product-led conversion-funnel diagnosis (signup → activation → paid) — route to
+  [`funnel-analysis`](../funnel-analysis/SKILL.md).
+
+## When the agent should load this
+
+- "Tighten our pipeline stages — exit criteria are vibes."
+- "Coverage looks 3× and we still missed. Where is the leak?"
+- "Audit per-stage conversion by segment."
+- "Welche Stage ist das Bottleneck im Quartal?"
+
+## Output
+
+1. **`stage-definitions.md`** — one block per stage: definition · entry trigger · exit criterion (buyer signal, falsifiable).
+2. **`coverage-by-cell.md`** — table of segment × stage cells with $ pipeline, cumulative conversion, and computed coverage. Cells under 1× flagged.
+3. **`leak-hypotheses.md`** — three leaks with falsifiable test + expected signal + 2-week deadline.
+
+## Gotcha
+
+- A pipeline with exit criteria written as rep activities (*"call made"*) is unauditable — reps move deals on activity, not on buyer signal, and forecasts inherit the noise.
+- Total-pipeline coverage is the wrong unit. A 3× total made of 5× early-stage and 0.5× late-stage will miss the quarter even though the dashboard looks healthy.
+- Per-stage conversion rates without confidence bands are gossip dressed as evidence. Twelve deals give you a band so wide the rate is uninformative.
+
+## Do NOT
+
+- Do NOT invent stages to flatter the dashboard. Each stage must have a buyer signal earning the transition.
+- Do NOT compare the quarter's coverage to a fixed historical multiple if segment mix changed — recompute per cell.
+- Do NOT recommend a fix to a leak before naming the falsifiable test that proves the cause.
+
+## Runnable example
+
+Mid-market SaaS, total coverage 3.1×, quarter missed by 18 %.
+
+- Stages with exit criteria — *Discovery → Qualified (economic buyer named) → Proposal (pricing in writing) → Negotiation (terms in redline) → Won.*
+- Per-cell coverage — Mid-Market × Proposal: **0.7×**. Mid-Market × Discovery: **6.4×**. Enterprise × Negotiation: **2.1×**.
+- Constraint — Proposal → Negotiation conversion 22 % vs 41 % trailing-quarter median (band 14–31 %). Constraint is **Proposal exit**, not pipeline volume.
+- Leaks — *(1)* Mid-Market proposals stall at pricing-page review; falsified if a pre-proposal pricing-walkthrough call lifts Proposal → Negotiation to 35 %+ within four weeks. *(2)* Enterprise Negotiation drags > 60 days; falsified if procurement-checklist shipped at Proposal stage cuts median age by 20 days. *(3)* Discovery overflow is unqualified — route to `deal-qualification-meddic`.
+- Hand-off — coverage table + leaks → `forecast-accuracy` for commit / best-case rebuild on the corrected denominator.