@event4u/agent-config 2.6.1 → 2.8.0

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.

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

@@ -0,0 +1,177 @@
+---
+name: positioning-strategy
+description: "Use when locking the market frame — category, segment, alternative, point-of-view — before messaging, launch, or pricing rides on it. Triggers on 'who are we for', 'opposable audit'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, customer-segment]
+---
+
+# positioning-strategy
+
+## When to use
+
+- A category sentence is missing or contested and the next artefact (messaging, launch, pricing page) is about to inherit the ambiguity.
+- The team can name what the product **does** but cannot name **who it is for**, **against what alternative**, or **what it refuses to be**.
+- An opposable-positioning audit is needed: every claim has to survive *"a reasonable competitor would argue the opposite"*.
+
+Do NOT use for peer-versus-peer feature comparison (route to
+`competitive-positioning`), copy generation (route to
+`messaging-architecture`), or pricing-tier construction.
+
+## Cognition cluster
+
+- **Mental model 1 — First-principles thinking.** Strip the category to
+  the underlying job: who fires what, to make what progress, under
+  what pressure. Inherited category labels are the trap; the unit of
+  positioning is the job, not the label. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 1.
+- **Mental model 30 — Inversion.** For every positioning claim, ask
+  *"what would a competitor with a credible alternative argue against
+  this?"* A claim that has no opposable counter is either trivially
+  true or invented — drop it. See `mental-models.md` § 30.
+- **Context-spine — product + customer-segment.** Read the **product**
+  slot for non-goals and the **customer-segment** slot for the ICP
+  shape before locking the frame. Positioning that contradicts either
+  slot fails its own audit. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Frame the job
+
+Write one sentence: *"\<Segment\> hires \<category\> to make progress
+in \<situation\>, when motivated by \<pressure\>, expecting
+\<outcome\>."* If you cannot finish the sentence, route to
+[`customer-research`](../customer-research/SKILL.md); positioning
+without job-evidence is invention, not earning.
+
+### Step 1: Lock the four anchors
+
+Each anchor is one sentence; ambiguity here propagates.
+
+1. **Category.** *"We are a \<category\>."* The category must be a
+   noun that the segment already uses to describe the budget line
+   the purchase comes out of — not a coined term.
+2. **Segment.** *"For \<segment\>."* Specific enough that a single
+   buyer recognises themselves; broad enough that the segment has
+   shared switch-events.
+3. **Alternative.** *"Instead of \<alternative\>."* Name the
+   single most-likely incumbent — usually a manual workflow, a
+   spreadsheet, or a competing product. *"Doing nothing"* counts.
+4. **Point of view.** *"Because \<load-bearing belief\>."* The
+   belief must be opposable — a credible peer holds the opposite.
+
+### Step 2: Validate via the opposable audit
+
+For every anchor, write the **strongest counter** a credible peer
+would make. Validate each anchor against the rule *"a credible peer
+holds the opposite"* — if no counter exists, the anchor is
+unfalsifiable (either trivially true or invented) and must be
+replaced before continuing.
+
+The four counters become the **assumption ledger**: explicit beliefs
+the positioning rides on. Each gets a re-evaluation trigger (event +
+metric + threshold) the team will watch for.
+
+### Step 3: Identify non-goals
+
+Write three sentences in the form *"We are not for \<adjacent
+segment\>, even though \<surface similarity\>, because \<reason
+grounded in the product slot\>."* Non-goals are how positioning
+earns its category — without them every prospect looks like a fit
+and the segment dissolves.
+
+### Step 4: Stress-test the frame
+
+For each anchor, walk the chain *"if this is true, then…"* through
+two consequences. If a consequence contradicts the product slot,
+the segment slot, or a shipped commitment, the anchor is wrong —
+fix the anchor, not the consequence.
+
+### Step 5: Hand back
+
+Hand the four anchors + assumption ledger + non-goals to
+[`messaging-architecture`](../messaging-architecture/SKILL.md) for
+primary-message construction. Do **not** write copy inside this
+skill — that is `messaging-architecture`'s job.
+
+## Related Skills
+
+**WHEN to use this**
+
+- The unit of work is the four-anchor frame, not a copy block.
+- A category sentence is contested and the next artefact rides on it.
+- An opposable audit is overdue and the team is shipping claims on faith.
+
+**WHEN NOT to use this**
+
+- Peer-vs-peer ours-vs-theirs verdict table — route to
+  [`competitive-positioning`](../competitive-positioning/SKILL.md).
+- Primary message + supporting proofs construction — route to
+  [`messaging-architecture`](../messaging-architecture/SKILL.md).
+- Fundraising "why now / why us" framing under capital constraint —
+  route to [`fundraising-narrative`](../fundraising-narrative/SKILL.md).
+- Pricing-tier construction or unit-economics modelling — route to
+  [`unit-economics-modeling`](../unit-economics-modeling/SKILL.md).
+
+## When the agent should load this
+
+- "Wer sind wir eigentlich für?"
+- "Lock the positioning before we write the launch deck."
+- "Brauche eine Category-Sentence für die Pricing-Page."
+- "Run an opposable-positioning audit on the homepage frame."
+- "Welche Alternative ranken wir uns gegen — Doing Nothing oder ein konkreter Wettbewerber?"
+
+## Output
+
+1. **`positioning.md`** — the four anchors (category · segment ·
+   alternative · point-of-view), one sentence each, opposable.
+2. **`assumption-ledger.md`** — one row per anchor: the strongest
+   peer-counter, the load-bearing belief, the re-evaluation trigger
+   (event + metric + threshold).
+3. **`non-goals.md`** — three sentences naming adjacent segments the
+   product refuses to serve, each grounded in the product slot.
+
+## Gotcha
+
+- A category sentence the segment does not already use is a coined
+  term, not a category — the segment will route around it.
+- *"Doing nothing"* is the most common alternative and the most
+  often skipped. If the buyer's status quo is free, the alternative
+  is free, and the positioning has to clear that bar.
+- A positioning frame without non-goals expands until everyone is a
+  prospect; that is the failure mode, not the success state.
+
+## Do NOT
+
+- Do NOT invent a category to differentiate — earned categories
+  beat coined categories; category theatre is the council Q1
+  out-of-scope.
+- Do NOT collapse positioning into a tagline; the four anchors are
+  the artefact, the tagline is a downstream compression.
+- Do NOT decide pricing tiers from positioning — hand off to
+  pricing / unit-economics work.
+
+## Runnable example
+
+Mid-market HR analytics tool, contested category:
+
+- Frame: *"\<HR leaders at 200–2000-person companies\> hire
+  \<workforce-analytics\> to make progress in \<board-quarter
+  retention reporting\>, when motivated by \<exec ask for cohort
+  attrition\>, expecting \<one-click roll-up by tenure band\>."*
+- Anchors — **category:** workforce analytics. **Segment:** HR
+  leaders at 200–2000-person, growing-headcount companies.
+  **Alternative:** a manually maintained spreadsheet plus the
+  HRIS-vendor's basic report. **Point of view:** *retention beats
+  acquisition as the lever in this segment*.
+- Assumption ledger — peer counter to point of view: *"acquisition
+  velocity dominates at \< 500 headcount."* Re-evaluation trigger:
+  new-hire-rate > 30 % year-on-year AND retention-flat → revisit.
+- Non-goals — *"We are not for enterprise (5000+); not for
+  workforce-planning (capacity modelling); not for engagement-survey
+  tooling."* Each grounded in the product slot's non-goals list.
+- Hand-off: four anchors → `messaging-architecture` for primary
+  message + audience-by-message matrix.

package/.agent-src/skills/retention-loops/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: retention-loops
+description: "Use when designing product-led retention — habit formation, trigger-action-reward, network vs single-user loops. Triggers on 'why don't users come back', 'design a habit loop'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, customer-segment, funnel-stage]
+---
+
+# retention-loops
+
+## When to use
+
+- D30 retention is flat or declining and the team cannot name a single product loop that pulls the user back — retention is treated as marketing's problem, not the product's.
+- A new feature shipped but did not move retention — there is no closed loop between trigger, action, and reward, so the feature is a destination, not a habit.
+- The product depends on a network effect that has not been instrumented as a loop — invites, content, or data are produced but the loop that pulls the next user back is unwritten.
+
+Do NOT use to fix days 0–30 onboarding friction (route to
+`onboarding-design`), classify churn causes (route to
+`churn-prevention`), or design human-led account-expansion plays
+(route to `expansion-playbook`).
+
+## Cognition cluster
+
+- **Mental model 14 — Meadows leverage points.** A retention loop
+  is a feedback structure: the leverage sits in the loop's
+  *gain* (how strong the reward is) and *delay* (how long until
+  the reward lands), not in the surface UI. Pick the leverage
+  point — gain or delay — over surface polish. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 14.
+- **Mental model 8 — Compounding.** A loop with even small gain
+  per cycle compounds across cohorts; a one-time activation
+  bump does not. Verify which loops compound before investing
+  cycles into them. See `mental-models.md` § 8.
+- **Mental model 18 — Pull vs. push.** A trigger the user pulls
+  (intrinsic need surfaced by the product) compounds; a trigger
+  the vendor pushes (marketing notification firing) decays the
+  channel and trains the user to mute. See `mental-models.md` § 18.
+- **Context-spine — product + customer-segment + funnel-stage.**
+  Read the **product** slot for which capability can carry a loop
+  (a loop is only as strong as the action it routes through), the
+  **customer-segment** slot for which segments have the latent
+  need the loop addresses, and the **funnel-stage** slot for where
+  the loop sits relative to activation and paid. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Inspect — name the current loops, if any
+
+Inspect the product. For each suspected loop, write the closed
+form: *"\<trigger\> → \<action\> → \<reward\> → \<trigger again\>."*
+If the loop cannot be written closed, it is not a loop; it is a
+funnel ending. Inspect whether the reward arrives quickly enough
+to reinforce the action — verify the delay against the segment's
+attention cycle.
+
+### Step 1: Classify each loop as single-user vs network
+
+1. **Single-user loop** — trigger and reward both originate from
+   the same user (a daily-summary email triggered by yesterday's
+   activity).
+2. **Network loop** — trigger or reward involves another user
+   (a teammate's comment, a partner's reply, a customer's reaction).
+
+Network loops compound harder but require minimum-viable-network
+density; below density they look broken. Classify before investing.
+
+### Step 2: Audit the gain and the delay per loop
+
+For each loop:
+
+1. **Gain per cycle** — what observable utility does the user
+   receive (information, social affirmation, time saved, reduced
+   error)? Gain measured as the user's revealed willingness to
+   repeat the action.
+2. **Delay** — time from trigger to reward. A delay longer than the
+   segment's attention window kills the loop regardless of gain.
+3. **Decay** — does the loop weaken when the user already has the
+   reward? Most product loops decay; design the next loop before
+   the first decays.
+
+### Step 3: Pick the binding loop and isolate it
+
+Of the loops named, pick the one whose gain × frequency × eligible
+segment-size is largest. **Verify** the loop is intrinsic-pull, not
+vendor-push: confirm the trigger originates from a user action or
+state, not from a marketing schedule. A push-trigger labelled as a
+loop will burn the channel.
+
+### Step 4: Design the missing step, not the missing UI
+
+If the binding loop is broken, the broken step is almost always:
+*trigger missing*, *action too far from trigger*, *reward delayed*,
+or *no path back to next trigger*. Design the missing **step**, not
+a UI tweak. UI tweaks polish a loop that already closes; they do
+not close an open one.
+
+### Step 5: Hand back
+
+Hand the loop inventory, the binding-loop selection with gain /
+delay / decay, and the step-level redesign to the implementing
+team and to
+[`activation-design`](../activation-design/SKILL.md) — activation
+is the loop's first cycle, and the activation event must complete
+the first cycle of the binding loop. Retention work without a named
+loop is rearranging notifications.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Designing or auditing product-led retention loops.
+- Selecting the binding loop and redesigning its missing step.
+
+**WHEN NOT to use this**
+
+- Days 0–30 onboarding milestones — route to
+  [`onboarding-design`](../onboarding-design/SKILL.md).
+- Cause-classification of churn events — route to
+  [`churn-prevention`](../churn-prevention/SKILL.md).
+- Human-led expansion plays — route to
+  [`expansion-playbook`](../expansion-playbook/SKILL.md).
+- Activation-event selection (first cycle of the binding loop) —
+  route to [`activation-design`](../activation-design/SKILL.md).
+
+## When the agent should load this
+
+- "Why don't users come back?"
+- "Design a habit loop for feature X."
+- "Is this loop single-user or network?"
+- "Welcher Loop tr\u00e4gt eigentlich unsere Retention?"
+
+## Output
+
+1. **`loop-inventory.md`** — every named loop in closed form: trigger → action → reward → next trigger, with single-user vs network tag.
+2. **`gain-delay-audit.md`** — per-loop gain · delay · decay · eligible-segment size · revealed repeat-rate.
+3. **`binding-loop-redesign.md`** — selected loop, the broken step, and the redesign in step terms (not UI terms).
+
+## Gotcha
+
+- A loop whose reward arrives outside the segment's attention window will look broken even when gain is high; delay kills loops more often than gain does.
+- A network loop below minimum-viable density behaves like an open funnel; instrumenting it and designing it before density is theatre.
+- *"Notifications fire daily"* is not a loop; it is a push schedule. A loop needs a closed return path from reward to next trigger that the user — not the vendor — closes.
+
+## Do NOT
+
+- Do NOT invest in surface UI on a loop that does not close; the loop closes by adding a step, not polishing one.
+- Do NOT instrument network loops as single-user loops; the metric will look broken until the network reaches density.
+- Do NOT design more than one binding loop at a time; concurrent loop changes destroy the signal.
+
+## Runnable example
+
+Mid-market collaboration tool, D30 retention 41 %, two suspected loops named.
+
+- Loop inventory — *(L1)* user receives daily summary → opens product → reviews changes → leaves a comment → teammate notified (network). *(L2)* user creates a doc → bookmark surfaces in nav → user reopens (single-user).
+- Gain–delay audit — L1 gain medium, delay 24 h (within attention window), decay low (network refreshes); L2 gain low, delay 0, decay high (bookmark stale within a week).
+- Binding loop — L1 selected (gain × frequency × segment-size dominates). Broken step: *"teammate notified"* fires but does not route teammate back to the originating doc — the loop opens.
+- Redesign — add teammate-return path: notification deep-links into the doc at the commented passage; **verify** with cohort A/B at 4-week horizon. Predicted: D30 +6 pp ± 3 pp.
+- Hand-off — loop inventory + redesign → eng team; activation event redefinition (one comment + one teammate notified) handed to `activation-design`.

package/.agent-src/skills/subagent-orchestration/SKILL.md

@@ -149,7 +149,7 @@ worktree → delegated-skill consumes the input shape declared in its
 `## Input` (or `## When the agent should load this`) block. The
 handoff is auditable; `lint_handoffs.py` validates the chain.
 
-**Example chain (W3 launch):** `positioning` (worktree A) →
+**Example chain (W3 launch):** `positioning-strategy` (worktree A) →
 `messaging-architecture` (worktree B, consumes positioning's
 `positioning-statement.md`) → `gtm-launch` (worktree C, consumes
 both prior artifacts). Each worktree carries one branch; the chain