@event4u/agent-config 2.7.0 → 2.9.0

package/.agent-src/skills/scenario-modeling/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: scenario-modeling
+description: "Use when constructing base / upside / downside scenarios — three-statement modeling, sensitivity analysis, optionality reasoning. Triggers on 'model the scenarios', 'what if growth halves'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, fiscal-period, product]
+---
+
+# scenario-modeling
+
+## When to use
+
+- A board pack, fundraise process, or annual plan needs base / upside / downside scenarios — not a single forecast number with a sensitivity table bolted on.
+- A strategic bet (build / buy / partner, geo-expansion, pricing change) needs the **shape of its downside** before it locks; *"what's the worst defensible outcome"* is the load-bearing question.
+- A founder or finance-partner needs to compare two options by their optionality, not their expected value — the option whose downside is bounded wins, not the option with the highest mean.
+
+Do NOT use for per-customer economics (route to `unit-economics-modeling` (O1)), forecast-call construction (route to `forecasting` (O2)), or runway-shape reasoning (route to `runway-cognition` (O3)). This skill **composes** all three; it doesn't replace them.
+
+## Cognition cluster
+
+- **Mental model 21 — Second-order thinking.** Each scenario is a chain: revenue → margin → burn → runway → fundraise → dilution. Single-statement scenarios (just revenue) skip the chain and read like wishlists. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 21.
+- **Mental model 29 — Premortem.** *"It's two windows from now and the downside scenario happened. Walk back."* The premortem forces concrete failure paths into the model; without it the downside is just a 20 % discount on base. See `mental-models.md` § 29.
+- **Mental model 26 — Optionality.** Optionality = preserved future choices. Read each scenario by what choices it preserves vs forecloses. Bounded downside + preserved optionality > unbounded upside with foreclosed optionality. See `mental-models.md` § 26.
+- **Context-spine — org-stage + fiscal-period + product.** Read **org-stage** for which scenarios matter (pre-revenue → upside is traction speed; growth → downside is competitive pressure). Read **fiscal-period** for the modeling horizon. Read **product** for which revenue lines are real vs roadmap. See [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Inspect and pull the upstream frames
+
+Read the three Wing-4 inputs:
+
+1. **`unit-economics-frame.md`** from O1 — CAC, LTV, contribution margin per channel and blended; burn-multiple direction.
+2. **`forecast-band.json`** from O2 — construction shape, commit / best-case / pipeline, confidence band, retro signature.
+3. **`runway-frame.md`** from O3 — current cash, burn shape, band-target, fundraise verdict, cut-or-grow verdict.
+
+If any frame is missing, STOP and route to the producing skill. Do not synthesize the upstream frame; that breaks the boundary.
+
+### Step 1: Define the three scenario shapes
+
+1. **Base** = O2 commit + O3 status-quo burn + O1 channel mix unchanged. The "everything you've already said" scenario.
+2. **Upside** = O2 best-case + O1 channel-mix shift to highest LTV/CAC + one named tailwind (segment proof / channel scale / pricing). *Name the tailwind*; un-named upside is wishlisting.
+3. **Downside** = O2 commit-band lower bound + O1 channel mix shift to declining channel + one named headwind (segment churn / channel saturation / competitive entry). *Name the headwind*; un-named downside is "everything is 20 % worse".
+
+### Step 2: Construct three statements per scenario
+
+For each of the three scenarios, write three statements — **not three full models, three statements**:
+
+1. **Revenue statement** — top-line shape over the horizon. Cite which O2 inputs flex.
+2. **Margin statement** — gross + contribution shape. Cite which O1 inputs flex (channel mix, pricing, COGS).
+3. **Cash statement** — net burn → runway gap shape. Cite the O3 band-target it lands against.
+
+Each scenario = nine numbers (three statements × three time slices: now / mid-horizon / end-horizon) plus a one-line "what made this scenario this scenario" explanation.
+
+### Step 3: Premortem each scenario
+
+1. **Base premortem** — *"if base under-delivers by 20 %, which input was the load-bearing assumption?"* If the answer is one input, the base is fragile; demote that input and recompute.
+2. **Upside premortem** — *"if upside hits, did we have the operating capacity to absorb it?"* Upside without operating-capacity reasoning is a fundraise pitch, not a plan.
+3. **Downside premortem** — *"if downside hits, what's the next decision and when?"* Tag the decision points; un-tagged downsides have no operational meaning.
+
+### Step 4: Run sensitivity, not Monte Carlo
+
+For each scenario, vary the single load-bearing input (named in Step 3) by ±20 %. Read whether the runway-gap verdict changes shape.
+
+A scenario whose verdict is stable under ±20 % sensitivity on its load-bearing input is robust. A scenario whose verdict flips is brittle; demote it into a *"what if"* footnote, not a board-pack scenario.
+
+Monte-Carlo is over-precise for this cognition; the question is *"does the verdict survive the obvious sensitivity?"* — not *"what's the 95th percentile?"*.
+
+### Step 5: Read the optionality, not just the mean
+
+For each scenario, write the option-preservation note:
+
+- *"This scenario preserves: ___ (named choices)."*
+- *"This scenario forecloses: ___ (named choices)."*
+
+The decision shape is rarely *"pick the highest mean"*. It's *"pick the scenario whose foreclosures we can live with and whose preserved options match the strategy"*.
+
+### Step 6: Emit the scenario bundle
+
+Produce `scenario-bundle.md` — the artifact strategist (T2 / P1 `build-buy-partner`) and finance-partner (T1) read for downstream decisions. Per `docs/guidelines/wing4-handoff.md` § Chain 1.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Constructing base / upside / downside for a board pack, fundraise, or strategic bet.
+- Comparing two strategic options by their optionality and downside shape.
+
+**WHEN NOT to use this**
+
+- Per-customer economics — route to [`unit-economics-modeling`](../unit-economics-modeling/SKILL.md) (O1).
+- Forecast-call construction — route to [`forecasting`](../forecasting/SKILL.md) (O2).
+- Runway shape / fundraise timing — route to [`runway-cognition`](../runway-cognition/SKILL.md) (O3).
+- Insource-vs-outsource-vs-acquire decisions — route to [`build-buy-partner`](../build-buy-partner/SKILL.md) (P1); P1 consumes this skill's bundle.
+- Whole-business intrinsic value with terminal value — route to [`dcf-modeling`](../dcf-modeling/SKILL.md).
+
+Wing-4 handoff: this skill reads `unit-economics-frame.md` (O1),
+`forecast-band.json` (O2), `runway-frame.md` (O3); emits
+`scenario-bundle.md` consumed by P1 and T1. Per
+`docs/guidelines/wing4-handoff.md` § Chain 1.
+
+## When the agent should load this
+
+- "Model base / upside / downside for the board pack."
+- "What does the downside look like if growth halves?"
+- "Compare option A and option B by their downside shape."
+- "Wie sehen unsere Szenarien aus?"
+
+## Output
+
+1. **`scenario-bundle.md`** *(Wing-4 handoff)* — three scenarios × three statements × three time slices, plus tailwind / headwind names, sensitivity-stability flag, and optionality note per scenario.
+2. **`load-bearing-inputs.md`** — one input named per scenario as the load-bearing assumption; sensitivity result on each.
+3. **`optionality-map.md`** — preserved / foreclosed choices per scenario; decision-shape recommendation.
+4. **`premortems.md`** — base / upside / downside premortems with named failure paths and tagged decision points.
+
+## Gotcha
+
+- "Downside = base × 0.8" is the most common deception. Downside must have a *named* headwind; without it the scenario doesn't model anything.
+- Upside without operating-capacity reasoning is a fundraise narrative, not a plan. Capacity (hiring lag, infrastructure, support load) is the inversion check.
+- Monte-Carlo simulations on a forecast that has a typed confidence band are over-precise theatre. Sensitivity ±20 % on the load-bearing input is the honest test.
+- Three-statement = three statements per scenario, not three full models. Nine numbers + one-line explanation = a readable bundle.
+
+## Do NOT
+
+- Do NOT construct scenarios without the three upstream frames (O1 / O2 / O3) — that breaks Wing-4 cognition boundaries.
+- Do NOT name a scenario without naming its tailwind / headwind / decision points — the labels are the cognition.
+- Do NOT optimise on mean; optimise on optionality + downside shape.
+
+## Runnable example
+
+Series-A SaaS, annual plan window.
+
+- Step 0 — frames: O1 says blended LTV/CAC 3.1, burn-multiple 1.8 decel. O2 says hybrid forecast, commit $6.3M, best-case $8.1M, band ±14 %. O3 says runway gap −5mo, fundraise=raise.
+- Step 1 — Base = $6.3M revenue, status-quo burn. Upside = $8.1M, tailwind = "enterprise segment proof point closes Q2". Downside = $5.4M, headwind = "competitor enters mid-market, churn spikes 2× in Q3".
+- Step 2 — three statements × three slices each. Base lands at gap −5mo; upside closes to −1mo; downside opens to −9mo.
+- Step 3 — base premortem: load-bearing = enterprise segment close rate. Upside premortem: capacity = need 2 AEs by Q1 or upside is shape-wrong. Downside premortem: decision point = if churn ≥ 1.5× by mid-Q3, cut non-headcount + tighten fundraise narrative.
+- Step 4 — sensitivity on close-rate ±20 %: base flips brittle (gap shape changes); demote to "fragile-base" footnote, re-run with conservative close rate.
+- Step 5 — upside preserves M&A optionality; downside forecloses pricing-experiment optionality. Recommendation: plan against re-run base, raise narrative on upside, hold downside as triggered playbook.

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

package/.agent-src/skills/throughput-vs-morale-tradeoff/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: throughput-vs-morale-tradeoff
+description: "Use when balancing eng-team velocity vs quality vs burnout — on-call load, focus fragmentation, reorg shock. Triggers on 'team is burning out', 'why is velocity dropping'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, product, customer-segment]
+---
+
+# throughput-vs-morale-tradeoff
+
+## When to use
+
+- An engineering team's velocity is dropping (or about to) and the question is *which lever to pull* — scope, on-call, focus-time, team-shape — and *which lever costs more morale than it returns*.
+- Burnout signals are surfacing (cancelled 1:1s, slipped commitments, attrition risk, low Slack-volume) and the question is *which load to take off the team before someone leaves*.
+- A reorg, growth push, or major deadline is being planned and the question is *what's the throughput-vs-morale trade* before the decision is made, not after.
+
+Do NOT use this for individual performance issues (route to Q4 `perf-feedback-craft` or S1 `one-on-one-cadence`), as a hiring-rate skill (route to S2 `hiring-loop-design`), or for team-velocity-tracking-platform configuration.
+
+## Cognition cluster
+
+- **Mental model — Theory of constraints.** Team throughput has one binding constraint at a time — usually code review queue, single-threaded role, on-call load, or focus-fragmentation. Identifying the constraint with file:line precision is the most leveraged hour an EM spends in a quarter; lifting non-constraint loads produces zero throughput gain. See [`mental-models.md`](../../../docs/contracts/mental-models.md).
+- **Mental model 21 — Second-order thinking.** Throughput borrowed from morale always compounds back. A two-quarter sprint to a deadline costs three-to-four quarters of slower hiring (reputation), slower velocity (post-burnout shape), and senior-IC attrition. Compute the round-trip, not just the deadline.
+- **Mental model 28 — Inversion.** *"What would make this team silently disengage by quarter-end?"* — usually: chronic on-call without recovery, focus-fragmentation > 4 context-switches / day, reorg-shock without re-shape time, leadership-promised-relief that doesn't arrive. Inversion surfaces the 4 canonical morale-collapse causes.
+- **Mental model — Base rates.** A team running at 80% utilization has zero slack for incidents; this is the base rate, not a worst case. A team running at 90% utilization for two quarters has 50%+ attrition base rate. Most EMs over-estimate sustainable utilization by 20 percentage points.
+- **Context-spine — org-stage + product + customer-segment.** Read **org-stage** for what's feasible (10-person co: high tolerance for surge; 50-person: pattern-establishing matters; 150+: well-established burn-rate signals). Read **product** for incident-load shape (consumer high-traffic = heavier on-call; deep-domain = lower volume / higher severity). Read **customer-segment** for SLA-driven on-call obligations.
+
+## Cross-wing handoff
+
+- Composed by T4 `engineering-manager` persona; specializes the throughput / morale conversation for engineering teams.
+- Hands off to Q4 `perf-feedback-craft` when team-level morale signals trigger individual feedback exchanges.
+- Hands off to Q1 `org-design` when the binding constraint is structural (team boundary, single-threaded role, span-of-control).
+- Hands off to O3 `runway-cognition` when the throughput-vs-morale trade is being driven by runway pressure — finance owns the runway pressure, EM owns whether the team can absorb the response.
+
+## Procedure
+
+### Step 0: Diagnose the binding constraint, not the symptoms
+
+Symptoms (slipped commitment, missed deadline, attrition signal) point at constraints; force the diagnosis before reacting:
+
+1. **Code-review queue** — PRs waiting > 24h on average. Throughput bound by review, not by writing code.
+2. **Single-threaded role** — one person owns N critical workstreams; vacation / sickness collapses progress.
+3. **On-call load** — primary on-call shift > 1 in 6 weeks for the same person, or > 50% of weeks with paging; on-call exhaustion is invisible until departures.
+4. **Focus fragmentation** — > 4 context switches / day, or < 3 hours of contiguous focus time / day. Producing systems work in 30-minute windows is a known anti-pattern.
+5. **Scope volatility** — > 30% scope change mid-cycle; team velocity drops because half the work in progress becomes throwaway.
+6. **Reorg / role-change shock** — new manager, new team boundaries, or new role within 90 days; 3–6 months of degraded throughput is the baseline.
+
+A team running on multiple constraints simultaneously is in burnout shape; pick the binding one first.
+
+### Step 1: Size the current throughput / morale state
+
+For the team in scope, gather:
+
+1. **Sustained utilization** — % of capacity allocated to committed work; > 80% = no slack; > 90% for > 2 quarters = attrition base rate triggers.
+2. **On-call distribution** — shifts per person per quarter; pages per shift; recovery time after high-page shifts.
+3. **Morale signals** — cancellation rate of optional meetings, 1:1 cadence health, Slack-volume changes, vacation usage. Each signal is noisy alone; three or more co-occurring = pattern.
+4. **Throughput trend** — committed-vs-delivered ratio over last 6 cycles. Single-cycle miss = noise; three-cycle decline = pattern.
+
+Without measurement, the trade is being made on vibes; force the read.
+
+### Step 2: Inspect the proposed lever before pulling it
+
+For each candidate lever to lift the constraint, run an inspect step before committing:
+
+1. **Scope reduction** — what gets deferred, by whom, with what stakeholder communication. Reduces load cleanly; cost = scope conversation with PM / stakeholders.
+2. **Hiring** — only relevant if hiring lead-time < timeline; cost = onboarding tax (Q3) on existing team.
+3. **On-call rotation reshape** — wider rotation, better runbooks, page-quality work. Cost = upfront engineering investment.
+4. **Focus-protection** — meeting-free days, no-Slack windows, makers-vs-managers calendaring. Cost = manager-communication overhead.
+5. **Reorg / boundary reshape** — Q1 territory; cost = 3–6 months of degraded throughput before settling.
+
+The cheapest-looking lever (just push harder for 6 weeks) is the most expensive in second-order terms.
+
+### Step 3: Map the round-trip cost honestly
+
+For the chosen lever, name the round-trip:
+
+1. **Q1 cost / benefit** — immediate impact.
+2. **Q2 cost / benefit** — settling impact.
+3. **Q3+ cost / benefit** — compounding impact (attrition base rate, hiring reputation, internal trust).
+
+Pushing harder for 6 weeks looks like a + in Q1 but is usually – in Q2 + Q3 + Q4 once attrition + slower hiring + reputation effects ripple. Forcing the round-trip honest is the most-skipped step.
+
+### Step 4: Lock the recovery shape, not just the surge shape
+
+Throughput borrowed from morale must be paid back; the recovery is part of the design, not an afterthought:
+
+1. **Recovery window** — minimum 4 weeks of reduced-load work after a 6-week sprint; 8 weeks after a quarter-long sprint.
+2. **No-overlap rule** — recovery from sprint A cannot run during sprint B; sequential, not parallel.
+3. **Recovery-shape clarity** — what does "reduced load" mean concretely (e.g., 20% allocation to tech-debt, 0 on-call shifts for the 2 people who carried most pages, explicit no-deadline-commits in the recovery window).
+4. **Manager-visible recovery** — recovery is named, scheduled, and protected; recoveries that exist only in the manager's head do not happen.
+
+Sprints without recovery are extraction; the team learns that "sprint" means "permanent state" and morale collapses.
+
+### Step 5: Validate the throughput / morale plan before announcing
+
+Before communicating the plan to the team, inspect three things:
+
+1. **Constraint named with precision** — confirm Step 0 named exactly one binding constraint with file:line / person:role specificity; multi-constraint or vague reads fail and must be re-diagnosed.
+2. **Round-trip honest** — assert Step 3's Q2+ cost is sized in attrition-base-rate and throughput-recovery-time terms; missing round-trip means the plan over-claims and must be re-sized.
+3. **Recovery shape locked** — verify Step 4's recovery window is named, scheduled, and on the calendar before the surge starts; recovery promised after surge launches almost never lands.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the throughput / morale plan
+
+Produce the plan artifact for the EM + their VP / leadership chain + a team-facing version. The leadership artifact contains the diagnosis + lever + round-trip + recovery shape. The team-facing version names the surge + when it ends + what recovery looks like + how morale signals will be monitored during the surge.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Velocity drops, missed commitments, surfacing burnout signals.
+- Pre-decision read on a planned sprint / deadline / reorg.
+- Annual capacity / on-call shape planning.
+- Post-incident retrospective when team load was a contributing factor.
+
+**WHEN NOT to use this**
+
+- Individual performance issues — route to [`perf-feedback-craft`](../perf-feedback-craft/SKILL.md) (Q4) or [`one-on-one-cadence`](../one-on-one-cadence/SKILL.md) (S1).
+- Hiring-loop / role-family design — route to [`hiring-loop-design`](../hiring-loop-design/SKILL.md) (S2).
+- Org-shape / team-boundary decisions — route to [`org-design`](../org-design/SKILL.md) (Q1).
+- Runway-pressure-driven scope conversation — route to [`runway-cognition`](../runway-cognition/SKILL.md) (O3) for the upstream finance read.
+
+## When the agent should load this
+
+- "Team is burning out."
+- "Why is velocity dropping?"
+- "Should we push harder this quarter?"
+- "On-call is killing the team."
+- "Wie balanciere ich Tempo und Moral?"
+
+## Output
+
+1. **`constraint-diagnosis.md`** — named binding constraint with file:line / person:role specificity.
+2. **`current-state-sizing.md`** — sustained utilization, on-call distribution, morale signals, throughput trend.
+3. **`lever-comparison.md`** — candidate levers × immediate cost / benefit × round-trip cost / benefit.
+4. **`recovery-shape.md`** — recovery window + reduced-load definition + no-overlap rule + calendar-locked dates.
+5. **`team-facing-plan.md`** — surge scope + end date + recovery shape + morale-signal monitoring during surge.
+
+## Gotcha
+
+- "We can push harder for 6 weeks" is the most expensive sentence an EM says. Round-trip cost is 3–4 quarters.
+- 80% sustained utilization has zero slack for incidents; teams at 90% for two quarters have base-rate 50%+ attrition.
+- A surge without a calendar-locked recovery is extraction. The team learns the word "sprint" means "permanent state".
+- Multi-constraint reads are usually under-diagnosed; press for the binding one, even if multiple feel binding.
+- "Morale" in EMs' heads is usually 30–60 days behind reality; lagging-indicator decisions are the canonical mis-shape.
+
+## Do NOT
+
+- Do NOT pull a throughput lever without sizing the round-trip cost; first-order math always favors pulling, second-order math often doesn't.
+- Do NOT promise recovery after the surge ends; schedule it before the surge starts or it doesn't happen.
+- Do NOT confuse this with individual-performance work; team-level constraints have team-level fixes.
+
+## Runnable example
+
+Series-B SaaS eng team (8 engineers), velocity has dropped 30% over 3 cycles, two senior ICs hinting at leaving, on-call has been heavy.
+
+- Step 0 — Constraint diagnosis: 2 of 8 engineers are doing 60% of on-call (specialty domain knowledge); single-threaded-role + on-call-load both binding. Binding-most: on-call distribution.
+- Step 1 — Current state: 88% sustained utilization (no slack), 4-in-6-week primary on-call for the 2 specialists, vacation usage near zero for those 2, throughput trend declining 3 cycles. Pattern is unambiguous.
+- Step 2 — Lever comparison: (a) push-harder = + 0 throughput, very negative round-trip; (b) widen on-call rotation requires 6 weeks of runbook + onboarding work for 3 other engineers; (c) defer Q3 scope by 20% — clean immediate relief; (d) hire — lead-time 3-6 months, doesn't help this cycle.
+- Step 3 — Round-trip: lever (b) + (c) combined: Q1 = -10% throughput on current scope (runbook investment + deferred scope) but + 0 on roadmap (defer absorbed); Q2 = + 15% throughput (wider on-call + recovered ICs); Q3+ = + retention base rate (specialists no longer at exhaustion).
+- Step 4 — Recovery shape: 6 weeks of reduced load for the 2 specialists (no primary on-call, 20% tech-debt allocation) starting week 1 of Q3. Calendar-locked, communicated.
+- Step 5 — Validate: binding constraint named with person-specificity; round-trip sized in attrition + Q2 / Q3 throughput terms; recovery on calendar before plan announced. Pass.
+- Step 6 — Emit leadership plan (diagnosis + (b)+(c) lever + round-trip + recovery) and team-facing plan (Q3 scope-defer + on-call reshape + named recovery window for the 2 specialists).

package/.agent-src/skills/unit-economics-modeling/SKILL.md

@@ -1,10 +1,11 @@
 ---
 name: unit-economics-modeling
-description: "Use when modeling CAC, LTV, gross-margin payback, or contribution margin per customer — for SaaS, marketplace, or transactional businesses."
+description: "Use when modeling CAC, LTV, payback, contribution margin, or burn-multiple per customer — SaaS, marketplace, or transactional. Triggers on 'are we unit-economic', 'what is our LTV/CAC'."
 status: active
 tier: senior
 source: package
 domain: product
+context_spine: [product, fiscal-period]
 ---
 
 # unit-economics-modeling
@@ -14,9 +15,30 @@ domain: product
 - A board ask: "is this business unit-economic?" — needs CAC / LTV / payback, not vibes.
 - A new channel is scaling and the question is whether the CAC payback period is sustainable.
 - A pricing or packaging change needs to be tested against contribution margin per cohort.
+- A finance-partner needs to construct burn-multiple cognition before the next forecast or scenario pass.
 
 Do NOT use for full-business intrinsic-value modeling, OKR setting, funnel-stage diagnosis, or backlog ranking (see Related Skills).
 
+## Cognition cluster
+
+- **Mental model 1 — First principles.** Strip the unit to one paying
+  customer and one fully-loaded acquisition dollar. Aggregate ratios
+  ride on per-unit truth; if the unit is mis-defined (trial vs paid,
+  household vs seat), every ratio downstream is decoration. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 1.
+- **Mental model 8 — Second-order thinking.** A CAC drop driven by
+  discounting lifts LTV/CAC on paper while shortening cohort
+  retention — the second-order effect lands two quarters later in
+  churn. Score the second-order cost of every lever, not just the
+  first-order ratio. See `mental-models.md` § 8.
+- **Context-spine — product + fiscal-period.** Read the **product**
+  slot for what a "customer" actually is in this scope (seat vs
+  household vs paid trial vs activated free), and the
+  **fiscal-period** slot for the close-window the ratios must
+  reconcile against (monthly close vs quarterly board pack vs
+  annual plan). See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
 ## Procedure
 
 ### Step 0: Inspect
@@ -51,13 +73,30 @@ Do NOT use for full-business intrinsic-value modeling, OKR setting, funnel-stage
 2. **LTV / CAC ratio**: target ≥ 3.0. Below 1.5 is acquisition-loss territory; above 5.0 means under-investment in growth (or bad LTV math).
 3. Both numbers, not one. Payback drives capital efficiency; ratio drives long-run economics.
 
-### Step 5: Cohort the answer
-
-1. Run Steps 1–4 by signup-quarter cohort. Trends matter more than the point estimate.
+### Step 5: Compute burn-multiple judgment
+
+1. **Burn multiple** = `net burn / net new ARR` over the fiscal-period
+   slot's reporting window (monthly close / quarterly / annual).
+   It answers *"how many dollars of cash do we burn to add one
+   dollar of recurring revenue?"* — a single ratio that compresses
+   CAC, gross margin, and churn into capital efficiency.
+2. Compute on **net** new ARR (gross new − churn − contraction).
+   Burn-multiple on gross new ARR flatters the picture by exactly
+   the churn rate; auditors and acquirers will recompute.
+3. Read the ratio against the org-stage colour from the
+   **fiscal-period** + product spine — do not hardcode a band here.
+   The cognition is *"smaller is better, and the direction across
+   cohorts matters more than the point estimate."* Bands belong in
+   `runway-cognition` (O3) where stage context is the load-bearing
+   input.
+
+### Step 6: Cohort the answer
+
+1. Run Steps 1–5 by signup-quarter cohort. Trends matter more than the point estimate.
 2. If LTV/CAC is improving but payback is lengthening, you are buying retention with discounting — flag.
 3. If both deteriorate, the channel mix has shifted to a worse channel — segment by channel to find the leak.
 
-### Step 6: Validate
+### Step 7: Validate
 
 1. Sanity-check LTV against revenue retention. If implied LTV > 8× annual revenue per customer with monthly churn > 2%, the math is wrong.
 2. Sanity-check CAC against fully-loaded P&L. If channel CACs sum to less than total acquisition spend, allocations are missing.
@@ -88,6 +127,13 @@ Do NOT use for full-business intrinsic-value modeling, OKR setting, funnel-stage
 - Diagnosing where conversion drops — route to [`funnel-analysis`](../funnel-analysis/SKILL.md).
 - Ranking competing initiatives — route to [`rice-prioritization`](../rice-prioritization/SKILL.md).
 - Setting team objectives that move these metrics — route to [`okr-tree-modeling`](../okr-tree-modeling/SKILL.md).
+- Cash-runway shape, fundraise-trigger heuristics, or layoff-vs-cut-vs-grow framing — route to [`runway-cognition`](../runway-cognition/SKILL.md) (O3).
+- Multi-statement scenario construction over base / upside / downside — route to [`scenario-modeling`](../scenario-modeling/SKILL.md) (O4).
+- Forecast-call construction (commit / best-case / pipeline) — route to [`forecasting`](../forecasting/SKILL.md) (O2).
+
+Wing-4 handoff: this skill ships the `unit-economics-frame.md`
+artifact that `scenario-modeling` (O4) reads as its money input
+(`docs/guidelines/wing4-handoff.md` § Chain 1).
 
 ## When the agent should load this
 
@@ -99,7 +145,8 @@ Do NOT use for full-business intrinsic-value modeling, OKR setting, funnel-stage
 
 ## Output
 
-1. **`unit-econ-table.md`** — table per channel and blended: CAC · ARPA · gross margin · payback months · LTV · LTV/CAC. With cohort columns (last 4 quarters).
+1. **`unit-econ-table.md`** — table per channel and blended: CAC · ARPA · gross margin · payback months · LTV · LTV/CAC · burn-multiple. With cohort columns (last 4 quarters).
 2. **`assumptions.md`** — formula chosen (SaaS / marketplace / transactional), churn definition, COGS allocation method, lifetime cap. One bullet per choice.
-3. **`cohort-trend.md`** — trend chart (ASCII or markdown table) of CAC, payback, LTV/CAC over the last 4–8 cohorts. Annotate channel-mix shifts.
+3. **`cohort-trend.md`** — trend chart (ASCII or markdown table) of CAC, payback, LTV/CAC, burn-multiple over the last 4–8 cohorts. Annotate channel-mix shifts.
 4. **`sanity-checks.md`** — explicit cross-checks (LTV vs annual revenue, channel CAC sum vs P&L). Flag any that fail with a one-line investigation pointer.
+5. **`unit-economics-frame.md`** *(Wing-4 handoff)* — the typed artifact `scenario-modeling` (O4) reads: CAC / LTV ratio, contribution margin, payback band, burn-multiple verdict, segment scope, fiscal-period the frame reconciles against. Per `docs/guidelines/wing4-handoff.md` § Chain 1.

package/.agent-src/skills/vision-articulation/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: vision-articulation
+description: "Use when articulating internal vision — where we're going / why now / why us, founder-mode anchor, distinct from fundraising pitch. Triggers on 'what's our vision', 'why are we doing this'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, product, customer-segment]
+---
+
+# vision-articulation
+
+## When to use
+
+- An internal anchor is needed — board off-site, all-hands, strategy doc — and the question is *where are we going, why now, why us*. The audience is the team, not investors.
+- A founder or strategist is sense-checking whether the current direction still holds, or whether reality has diverged from the stated vision.
+- A new hire / new exec needs the founder-mode read of the company — not the fundraise pitch, the durable internal frame.
+
+Do NOT use for outward-facing fundraise pitch (route to Wing-3 `fundraising-narrative` (H7); vision is internal-anchor, fundraising is external-pitch — different audiences, different proof bars), positioning copy / launch narrative (route to Wing-3 `positioning-strategy` / `messaging-architecture`), or roadmap construction (route to `feature-roadmap` workflows; vision constrains roadmaps, doesn't replace them).
+
+## Cognition cluster
+
+- **Mental model 27 — Why now.** Vision without a *why now* is a wishlist. The market shift, technology wave, regulatory change, or demographic inflection that makes the vision *achievable in this window* is the load-bearing claim. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 27.
+- **Mental model 1 — First principles.** Strip the vision to outcomes for a named cohort, not feature lists or company milestones. *"Be the X for Y"* is shape; *"customer C does outcome O 10× faster"* is substance. See `mental-models.md` § 1.
+- **Mental model 21 — Second-order thinking.** *"If this vision is realised, what does the world look like in 5 years?"* If the answer is just *"we got bigger"*, the vision isn't load-bearing; if the answer is structural change (workflow shift, market re-shape), it is. See `mental-models.md` § 21.
+- **Context-spine — org-stage + product + customer-segment.** Read **org-stage** for vision-horizon (pre-seed = 3-year survival vision; growth = 5–7-year market-shape vision; mature = 10-year). Read **product** for the realistic shipping shape. Read **customer-segment** for the cohort whose outcome anchors the vision.
+
+## Procedure
+
+### Step 0: Identify stance — founder vs operator
+
+Vision-articulation is a founder-mode act, not an operator-mode act (per council Q6). Before starting:
+
+1. Confirm the requester is in founder-stance — they are setting the durable frame, not optimising within an existing frame.
+2. If the requester is in operator-stance (planning, executing, refining within a fixed frame), this skill is wrong; route to roadmap / planning skills.
+
+Founder-stance is the precondition; without it the output is mis-shaped.
+
+### Step 1: Frame "where we're going" — cohort + outcome + horizon
+
+One sentence: *"In [horizon], [customer-segment] [does outcome O] [because of structural change S]."*
+
+Anti-patterns to reject:
+
+1. *"We're the [Big Company] of [Vertical]"* — feature-comparison, not cohort outcome. Reject.
+2. *"We're building the future of X"* — generic, no cohort named. Reject.
+3. *"We're growing to $100M ARR"* — milestone, not vision. Reject.
+
+The sentence must name *who*, *what they do that they can't do today*, *why it matters in [horizon]*.
+
+### Step 2: Construct "why now"
+
+Name 2–3 inflections that make this vision achievable in this window — not next decade, not last decade:
+
+1. **Technology inflection** — capability newly cheap / newly possible (AI, edge compute, new platform).
+2. **Market inflection** — buyer behaviour shift, segment opening, incumbent vulnerability (M&A churn, regulatory burden, talent loss).
+3. **Demographic / regulatory inflection** — workforce shift, policy change, generational handover.
+
+Each inflection must be *recent* (last 24–36 months) or *imminent* (next 24 months). Inflections from 10 years ago are settled; inflections 10 years out are speculative. The *why now* window is narrow.
+
+### Step 3: Construct "why us"
+
+Name 2–3 reasons this team, not another, can execute the vision. Honesty test:
+
+1. **Unique capability** — composes `competitive-moat-analysis` (P3); cite the moat dimensions where we score strong with evidence.
+2. **Unique distribution** — channel, community, partnership we have and competitors structurally can't replicate.
+3. **Unique insight** — founder / team origin gives us a read on the cohort that competitors don't have.
+
+If the answer is *"we're hardworking"* or *"we move fast"*, the answer is none. Most teams are. Re-run.
+
+### Step 4: Inversion — what would falsify the vision?
+
+For each load-bearing claim (cohort outcome, why-now inflection, why-us reason), write:
+
+1. *"What evidence in the next 12 months would falsify this?"* — leading signal that the vision is wrong-shaped.
+2. *"What change in the world would make this vision obsolete?"* — exogenous shift we're betting against.
+
+A vision that can't be falsified is a slogan. Concrete falsifiers = real vision.
+
+### Step 5: Validate the vision before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Cohort-outcome specificity** — confirm the Step-1 sentence names a specific cohort + specific outcome + specific horizon; generic phrasing fails and must be re-run.
+2. **Why-now timestamp** — assert each Step-2 inflection is dated within the recent-24-36-months or imminent-24-months window; un-timestamped inflections are claims, not inflections.
+3. **Why-us falsifiability** — check that each Step-3 reason has a named Step-4 falsifier; un-falsifiable reasons are slogans and must be demoted.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the vision frame
+
+Produce the vision-frame artifact for internal use (board, all-hands, exec onboarding). Hand off to Wing-3 `fundraising-narrative` (H7) if an external pitch derivative is needed — that's a translation, not a copy.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Internal vision articulation for board off-site, all-hands, strategy doc.
+- Founder / exec sense-check on vision-vs-reality divergence.
+- New-hire / new-exec onboarding to founder-mode read.
+
+**WHEN NOT to use this**
+
+- Outward-facing fundraise pitch — route to Wing-3 [`fundraising-narrative`](../fundraising-narrative/SKILL.md) (H7); vision is internal anchor, fundraising is external pitch.
+- Positioning / messaging copy — route to Wing-3 [`positioning-strategy`](../positioning-strategy/SKILL.md) and [`messaging-architecture`](../messaging-architecture/SKILL.md).
+- Moat reading — route to [`competitive-moat-analysis`](../competitive-moat-analysis/SKILL.md) (P3); this skill composes P3 for the "why us" frame.
+- Roadmap / phase planning — route to roadmap workflows; vision constrains roadmaps, doesn't replace them.
+
+## When the agent should load this
+
+- "What's our vision?"
+- "Sense-check our direction — does this still hold?"
+- "Draft the vision section for the board off-site."
+- "Why now / why us frame for the strategy doc."
+- "Wo wollen wir hin und warum jetzt?"
+
+## Output
+
+1. **`vision-frame.md`** — one-sentence vision (cohort + outcome + horizon), three "why now" inflections, three "why us" reasons.
+2. **`falsifiers.md`** — leading signals + exogenous shifts that would falsify each load-bearing claim.
+3. **`vision-vs-reality.md`** *(optional)* — when used as a sense-check, the delta between stated vision and current trajectory; named divergence points.
+
+## Gotcha
+
+- "Be the X for Y" frames are positioning slogans, not vision. Reject; force cohort-outcome-horizon.
+- "Why now" with no timestamp is a claim, not an inflection. Force a date.
+- "Why us" answers like *"we're a great team"* mean none. Force unique capability / distribution / insight cited with evidence.
+- Vision artifacts that survive zero change in the world over 5 years are slogans. Real visions have falsifiers.
+
+## Do NOT
+
+- Do NOT collapse vision into fundraise pitch — different audiences, different proof bars.
+- Do NOT skip the inversion / falsifier step — un-stressed visions are unfalsifiable.
+- Do NOT bolt vision onto roadmap milestones — milestones are downstream of vision, not the same thing.
+
+## Runnable example
+
+Series-A vertical SaaS, founder requests vision sense-check for board off-site.
+
+- Step 0 — Stance: founder-mode confirmed (off-site context, setting durable frame).
+- Step 1 — Vision: *"In 5 years, mid-size healthcare specialty groups (50–200 providers) deliver patient scheduling with 80 % less administrative load because the workflow is regulation-aware and self-adapting per state."*
+- Step 2 — Why now: (a) state-licensure data became machine-readable in the last 24 months (tech inflection); (b) incumbent hospital-focused vendors hit their growth ceiling and are starting to mis-fit specialty groups (market inflection); (c) post-COVID, specialty-group practice owners control admin spend directly (buyer-behaviour shift, last 36 months).
+- Step 3 — Why us: (a) founder's clinical-ops background + customer-segment access (unique insight, cited with 12 customer interviews); (b) switching-cost moat from 24-month deployment depth (composes P3, cited evidence); (c) HIPAA + 50-state licensure capability stack (unique capability).
+- Step 4 — Falsifiers: (a) incumbent ships specialty-group focused migration tooling = unique-capability claim erodes; (b) state-licensure data becomes opaque again (regulatory rollback) = tech inflection inverts; (c) specialty-group consolidation accelerates so 50–200 cohort shrinks = cohort scope shrinks.
+- Step 5 — Validate: cohort + outcome + horizon present; why-now inflections all dated within 24–36 months; why-us reasons each have falsifier. Pass.
+- Step 6 — Emit vision-frame for board off-site; flag potential H7 derivative needed for the upcoming Series-B narrative.