@event4u/agent-config 2.8.0 → 2.10.0

package/.agent-src/skills/privacy-review/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: privacy-review
+description: "Use when reviewing data flows for GDPR / CCPA / HIPAA fit — regulatory-regime delta, consent shape, breach-impact triage. Triggers on 'is this GDPR-safe', 'do we need a DPA'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [regulatory-regime, customer-segment, product]
+---
+
+# privacy-review
+
+## When to use
+
+- A new feature, integration, or vendor introduces a data flow and the question is *which regulatory regime applies*, *what consent / lawful basis is required*, *what the breach-impact tail looks like*.
+- An existing data flow is being re-scoped (new geography, new customer segment, new processor) and the regulatory-regime delta must be read before the change ships.
+- A customer / counterparty requests a DPA, BAA, or SCC and the question is *what we can credibly sign* given current data-handling reality.
+
+Do NOT use as a substitute for qualified privacy counsel (this skill produces the non-lawyer cognition that prepares the counsel conversation), as a contract-level read (route to `contracts-cognition` (P5); P5 composes this skill for data-clause depth), or for privacy-platform SaaS configuration / audit-tool administration.
+
+## Cognition cluster
+
+- **Mental model 28 — Inversion.** *"What's the worst-case if this data flow leaks, is subpoenaed, or is mis-consented?"* Inversion sizes the regulatory tail before consent / DPA shape is debated. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 28.
+- **Mental model 1 — First principles.** Strip the data flow to: *who* (data subject), *what* (data category), *why* (lawful basis / purpose), *where* (residency / transfer), *how long* (retention), *who else* (sub-processors). Six primitives anchor every regime delta. See `mental-models.md` § 1.
+- **Mental model 21 — Second-order thinking.** Consent design at signup interacts with marketing automation; retention defaults interact with data-subject-rights workflow; sub-processor chains interact with breach-notification timelines. Each privacy choice has downstream regime obligations. See `mental-models.md` § 21.
+- **Context-spine — regulatory-regime + customer-segment + product.** Read **regulatory-regime** (J1) for the applicable floor (GDPR, CCPA/CPRA, HIPAA, PIPEDA, LGPD, sector-specific). Read **customer-segment** for who the data subjects are (B2C-EU = GDPR primary; US-healthcare = HIPAA primary; B2B-EU-of-US-customers = mixed). Read **product** for which features touch sensitive categories.
+
+## Cross-wing handoff
+
+- Cites J1 `regulatory-regime` (foundation slot) for the regime floor read; without J1, this skill cannot bind which regime applies.
+- Hands off to P5 `contracts-cognition` for clause-level redlines on DPAs / BAAs / SCCs.
+- Hands off to P7 `data-handling-judgment` for the classification, retention, and cross-border-transfer surface that this skill flags.
+
+## Procedure
+
+### Step 0: Bind the regulatory-regime floor
+
+Read the J1 `regulatory-regime` slot for the customer-segment and geography in scope. For each applicable regime, name:
+
+1. *Which data subjects does it protect?* (EU residents → GDPR; California residents → CCPA/CPRA; US patients in covered entities → HIPAA).
+2. *What categories does it gate?* (GDPR special categories; HIPAA PHI; CCPA "sensitive personal information").
+3. *What lawful-basis / consent shape does it require?* (GDPR Art. 6 + Art. 9; HIPAA authorization; CCPA notice + opt-out).
+
+Multiple regimes can apply simultaneously; the floor is the strictest applicable.
+
+### Step 1: Map the data flow
+
+For the feature / integration / vendor in scope, enumerate every hop:
+
+1. **Collection** — what data category, from whom, where, with what notice / consent.
+2. **Processing** — who processes (us, sub-processor), where, for what purpose.
+3. **Storage** — where stored (region, system), encrypted at rest, retention default.
+4. **Transfer** — cross-border hops, transfer mechanism (SCC, adequacy, BCR).
+5. **Disclosure** — who sees it (internal roles, third parties, government-access risk).
+6. **Deletion** — retention end-state, data-subject-rights workflow, hard-delete vs soft-delete.
+
+A flow without all six hops named is not mapped; it's assumed. Force the enumeration.
+
+### Step 2: Compute the regulatory-regime delta
+
+For each hop × each applicable regime, name the obligation:
+
+1. **Lawful basis / consent** — what's the basis for this hop under this regime; is it documented; is it user-affirmative where required.
+2. **Notice** — what notice was given at the collection hop; does it cover the downstream hops.
+3. **DPA / BAA / SCC** — for each sub-processor / cross-border hop, what contract is required; is it in place.
+4. **Data-subject rights** — for each hop, can we deliver access / deletion / portability / objection within the regime's window.
+5. **Breach-notification surface** — what's the notification timeline (GDPR 72 h, HIPAA 60 d, CCPA varies), to whom, with what content.
+
+Gaps = obligations un-met. Surface them, don't smooth them.
+
+### Step 3: Consent design read
+
+For each lawful-basis claim:
+
+1. *Is the basis defensible?* (legitimate-interest balancing test documented; consent freely given / specific / informed / unambiguous; contractual necessity actually necessary).
+2. *Is withdrawal as easy as granting?* (GDPR Art. 7.3; CCPA opt-out parity).
+3. *Are sensitive categories handled with explicit consent / authorization?*
+
+Consent-as-checkbox-at-signup is the canonical failure mode. Inversion check: *"if a regulator inspects the consent flow tomorrow, what would they find un-defensible?"*
+
+### Step 4: Breach-impact triage
+
+For each data category × hop, size the breach tail:
+
+1. **Volume** — how many subjects per hop.
+2. **Sensitivity** — special-category / PHI / financial / identity-document presence.
+3. **Notification surface** — 72-hour clock starts when; who notifies (us as controller, vendor as processor); content requirements.
+4. **Regulatory-fine exposure** — GDPR up to 4 % global turnover or €20M; HIPAA tiered; CCPA per-record statutory damages.
+
+A hop without a sized breach-tail is unstressed.
+
+### Step 5: Validate the privacy read before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Hop coverage** — confirm all six data-flow hops (collection, processing, storage, transfer, disclosure, deletion) were inspected; silent skips mean the flow was not mapped.
+2. **Regime delta completeness** — assert every applicable regime was checked for lawful basis, notice, DPA/BAA/SCC, data-subject rights, breach notification; un-checked obligations are gaps in disguise.
+3. **Counsel handoff** — verify the artifact explicitly flags which findings need privacy-counsel sign-off vs which are operational decisions; this skill does not replace counsel.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the privacy-review note
+
+Produce the privacy-review artifact for the feature owner, legal / counsel, and DPO if applicable. The artifact is the non-lawyer cognition that prepares the counsel conversation and gates the ship decision; it is not the legal opinion.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Reviewing a new feature / integration / vendor data flow against applicable regulatory regimes.
+- Re-scoping an existing flow under a new geography, segment, or processor.
+- Sizing the breach-impact tail before a ship decision.
+
+**WHEN NOT to use this**
+
+- Contract-clause redline depth — route to [`contracts-cognition`](../contracts-cognition/SKILL.md) (P5); P5 composes this skill for data-clause sections.
+- Data-classification / retention / cross-border judgment in isolation — route to [`data-handling-judgment`](../data-handling-judgment/SKILL.md) (P7); P7 is composed by this skill.
+- Regulatory-regime floor read in general — route to `regulatory-regime` (J1); this skill cites J1, doesn't replace it.
+- Legal privacy opinion — route to qualified privacy counsel.
+
+## When the agent should load this
+
+- "Is this GDPR-safe?"
+- "Do we need a DPA / BAA / SCC for this vendor?"
+- "What's the breach exposure on this data flow?"
+- "Review the consent flow for the new signup."
+- "Wir starten in der EU — was ändert sich datenschutzrechtlich?"
+
+## Output
+
+1. **`data-flow-map.md`** — six hops × what / who / where / how-long / who-else per hop.
+2. **`regime-delta.md`** — applicable regimes × obligations × gaps per hop.
+3. **`consent-design-note.md`** — lawful-basis defensibility, withdrawal parity, sensitive-category handling.
+4. **`breach-impact-triage.md`** — sized tail per category × hop; notification clock; fine exposure.
+5. **`counsel-handoff.md`** — findings that need counsel sign-off vs operational decisions.
+
+## Gotcha
+
+- "We're US-only, GDPR doesn't apply" is often wrong; GDPR follows the data subject, not the company.
+- Consent checkboxes pre-ticked at signup are not consent under GDPR; this is a canonical regulator-attention pattern.
+- Sub-processor chains drift silently; a vendor adds a sub-processor 6 months in and your DPA is stale.
+- Retention defaults of "forever" interact badly with data-subject-rights timelines under every regime.
+
+## Do NOT
+
+- Do NOT issue privacy legal opinions; this skill prepares cognition for counsel, not replaces counsel.
+- Do NOT collapse multiple regimes into the most familiar one; the floor is the strictest applicable.
+- Do NOT skip breach-impact triage; un-stressed flows ship with un-sized tail.
+
+## Runnable example
+
+Growth-stage SaaS adds an EU customer cohort; existing US-only flow now serves EU data subjects.
+
+- Step 0 — Bind regime: GDPR applies (EU data subjects); CCPA still applies for California subset; HIPAA n/a (no PHI).
+- Step 1 — Map flow: collection (signup, EU IP), processing (US-east region), storage (US-east + analytics warehouse), transfer (US-east → analytics vendor in US-west; analytics vendor uses sub-processor in India), disclosure (internal CS team, no third parties), deletion (soft-delete, 7-year retention default).
+- Step 2 — Regime delta: lawful basis missing for analytics (no opt-in); notice doesn't disclose Indian sub-processor; no SCC with analytics vendor; data-subject-rights workflow is manual ticket only; breach-notification process undocumented.
+- Step 3 — Consent: signup checkbox is pre-ticked for marketing — fails Art. 7. Withdrawal requires support email — fails parity.
+- Step 4 — Breach-impact: 12k EU subjects, no special categories, GDPR fine exposure up to 4 % global turnover; 72-hour notification clock with no documented owner.
+- Step 5 — Validate: six hops mapped; both regimes checked; counsel-handoff names SCC + analytics-vendor sub-processor chain + consent UX redesign as counsel-led; retention default + DSR workflow as operational. Pass.
+- Step 6 — Emit privacy-review note; gate EU launch on (a) SCC with analytics vendor; (b) consent UX redesign; (c) DSR workflow with named owner and 30-day window; (d) breach-notification runbook.

package/.agent-src/skills/runway-cognition/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: runway-cognition
+description: "Use when reasoning about cash runway — burn shape, fundraise triggers, layoff-vs-cut-vs-grow decisions. Triggers on 'how long do we have', 'should we raise', 'cut or grow'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, fiscal-period, product]
+---
+
+# runway-cognition
+
+## When to use
+
+- A finance-partner or founder needs to read the cash runway as a **shape** (not a single number) and decide whether to raise, cut, or grow.
+- Burn has shifted in a way the prior plan didn't anticipate; the question is whether the shift is structural (revise plan) or transient (hold).
+- A fundraise window is opening or closing; the question is whether to start the process now, in one quarter, or hold and grow.
+- A board / leadership debate has split between *cut to extend runway* and *invest to accelerate*; the framing — not the verdict — is what's missing.
+
+Do NOT use for per-customer economics (route to `unit-economics-modeling` (O1)), forecast-call construction (route to `forecasting` (O2)), or multi-statement scenario construction (route to `scenario-modeling` (O4)).
+
+## Cognition cluster
+
+- **Mental model 21 — Second-order thinking.** *"If we cut here, then ___, and then ___."* Runway decisions are second-order by construction: the first-order effect (extended runway) is trivial; the second-order effect (slower growth → next-round terms → dilution) is the real decision. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 21.
+- **Mental model 28 — Inversion.** *"What would force a down-round?"* Invert the fundraise question: instead of *"can we raise?"* ask *"what evidence would the market need to fund us at this valuation?"* and work backwards. See `mental-models.md` § 28.
+- **Mental model 16 — Leading vs lagging indicators.** Cash balance is lagging; **net burn trend over the last 3 fiscal-periods** + **pipeline coverage of next-window revenue** are leading. A runway model that reads only cash balance is reading yesterday's weather. See `mental-models.md` § 16.
+- **Context-spine — org-stage + fiscal-period + product.** Read the **org-stage** slot for what bands apply (pre-seed / seed / Series A / Series B+ / growth / public — each has a different "healthy runway" band; do not hardcode 18 months). Read **fiscal-period** for the cadence the runway model rolls forward against. Read **product** for what's GA-shippable in the window — pre-revenue product changes the cognition shape (extend until traction) vs post-revenue (extend until next milestone). See [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Establish the org-stage band
+
+Read the `org-stage` slot. The band selection is the load-bearing
+choice — *not the agent's*. The slot answers it. Use these shapes:
+
+- **Pre-seed / seed** → the band is "next milestone + buffer", not a fixed month count. Milestone = the evidence the next round will fund.
+- **Series A** → the band is "to product-market-fit signal + buffer". Buffer ≥ one fundraise cycle (typically 6–9 months in the org's segment).
+- **Series B+ / growth** → the band is "to next funding milestone with metric-driven evidence" (NRR, gross margin, growth rate). Buffer = one quarterly cycle.
+- **Public / cash-flow positive** → runway converges to "operating cash + facility headroom"; the cognition shifts to working-capital reasoning.
+
+If the slot is missing or contested, STOP and ask once. Do not infer from prose.
+
+### Step 1: Compute the burn shape, not the number
+
+1. Net burn = net cash out over the last 3 fiscal-periods. Use 3 windows, not 1 — single-window burn is noise.
+2. **Burn trend**: flat / accelerating / decelerating. Compute the slope. Accelerating burn is the leading indicator; flat burn at a high number is the lagging confirmation.
+3. **Burn-multiple** (cross-cite O1 `unit-economics-modeling` Step 5): net burn / net new ARR over the same windows. Read direction across the 3 windows, not the point estimate.
+
+Output is a shape: *"net burn $X/mo, decelerating over last 3 quarters; burn-multiple 2.4 → 1.8 → 1.3."*
+
+### Step 2: Inspect runway against the band
+
+1. Compute months-of-runway = cash / current-burn at three burn assumptions: status-quo, +20% (overspend scenario), −20% (cuts taken).
+2. Compare each to the **band-appropriate target** from Step 0. Do not compare to a fixed "18 months" — that's a Series-A heuristic that mis-fires at every other stage.
+3. Verdict shape: *"at status-quo burn, we have X months vs the Y-month band; gap is Z months."* Gap, not absolute number.
+
+### Step 3: Decide on the fundraise question (or refuse to)
+
+Three honest answers; pick one:
+
+1. **Raise now** — gap is closing into the band's lower bound, and at least one fundraise-trigger condition fires (revenue milestone hit, segment proof point demonstrable, founder bandwidth available). Cross-cite Wing-3 `fundraising-narrative` (H7) for external-pitch shape.
+2. **Hold and grow** — gap is comfortably inside the band AND the leading indicators (Step 1 burn-multiple direction + pipeline coverage of next-window revenue) are improving. Do not raise into a comfortable runway; the dilution math doesn't justify it.
+3. **Refuse to answer** — the gap is in the band's noise but no leading indicator has direction. The honest answer is *"I'm not ready to call this; tell me what to measure for two windows."*
+
+A *cut* (Step 4) is not an answer to the fundraise question; it's a separate decision.
+
+### Step 4: Decide on layoff-vs-cut-vs-grow
+
+1. **Grow** — leading indicators improving + band has headroom. The cut math is dilutive (every $ cut here is a $ of capacity not built).
+2. **Cut non-headcount** — leading indicators flat + band tightening. Tooling / contractors / venues / paid-marketing / unused real-estate first.
+3. **Cut headcount** — band tightening into the lower bound AND leading indicators flat-or-worsening for ≥ 2 windows. Smallest cut that moves the band by ≥ 1 buffer-cycle is the right cut. *"Across-the-board 10 %"* is the failure mode — it cuts what's already efficient at the same rate as what's not.
+
+The premortem (mental-model 29): *"if we lay off and the leading indicators don't improve, what did we just lose?"* If the answer is "the people who would have moved the indicators", the cut is wrong.
+
+### Step 5: Emit the runway frame
+
+Produce `runway-frame.md` — the typed artifact `scenario-modeling` (O4) reads as its runway input. Per `docs/guidelines/wing4-handoff.md` § Chain 1 / Chain 3.
+
+## Related Skills
+
+**WHEN to use this**
+
+- The question is cash-runway shape, fundraise-timing, or cut-vs-grow.
+- The decision is whether to raise, hold, or cut — at this org-stage.
+
+**WHEN NOT to use this**
+
+- Per-customer economics (CAC / LTV / payback) — route to [`unit-economics-modeling`](../unit-economics-modeling/SKILL.md) (O1).
+- Forecast-call construction (top-down vs bottom-up) — route to [`forecasting`](../forecasting/SKILL.md) (O2).
+- Three-statement scenario construction — route to [`scenario-modeling`](../scenario-modeling/SKILL.md) (O4).
+- External fundraise narrative — route to Wing-3 [`fundraising-narrative`](../fundraising-narrative/SKILL.md) (H7); cite for pitch shape.
+- People decisions (layoff process, communication, severance) — route to Wing-4 [`org-design`](../org-design/SKILL.md) (Q1) for shape; people-strategist owns process.
+
+Wing-4 handoff: this skill reads `forecast-band.json` from O2 and
+`unit-economics-frame.md` from O1; emits `runway-frame.md` consumed
+by O4. Per `docs/guidelines/wing4-handoff.md` § Chain 1.
+
+## When the agent should load this
+
+- "How long is our runway?"
+- "Should we raise now or hold?"
+- "Do we need to cut, and if so what?"
+- "Wie lange reicht das Geld noch?"
+- "Sind wir noch im sicheren Band für die Stage?"
+
+## Output
+
+1. **`runway-frame.md`** *(Wing-4 handoff)* — org-stage, fiscal-period, current cash, net-burn trend (flat / accel / decel), burn-multiple direction, months-of-runway at 3 burn assumptions, band-appropriate target, gap, fundraise verdict (raise / hold / refuse), cut-vs-grow verdict.
+2. **`burn-shape.md`** — last 3 fiscal-periods net burn + burn-multiple, with trend annotation.
+3. **`fundraise-decision.md`** — which of the three verdicts (raise / hold / refuse), leading indicators read, premortem if "raise".
+4. **`cut-or-grow.md`** *(only if cut verdict)* — non-headcount cuts first, headcount-cut shape if required, premortem on each cut.
+
+## Gotcha
+
+- "18 months runway" is a Series-A heuristic; applying it to seed (where milestone matters more than month count) or growth (where metric milestones matter more) silently mis-frames the decision.
+- Single-window net burn is noise. Always 3 windows.
+- Burn-multiple direction matters more than the point estimate. A 3.0 going to 2.0 is healthier than a 1.8 going to 2.4.
+- Raising into a comfortable runway is dilutive theatre — *"we have 18 months so we should raise now"* doesn't survive a second-order check.
+- *Across-the-board* cuts cut efficient teams at the same rate as inefficient ones. The smallest targeted cut that moves the band wins.
+
+## Do NOT
+
+- Do NOT compare months-of-runway against a fixed number; always against the band-appropriate target from Step 0.
+- Do NOT answer the fundraise question without checking leading indicators (Step 1 + pipeline coverage).
+- Do NOT collapse cut-vs-grow into a single "extend runway" verdict — they're separate decisions with separate evidence.
+
+## Runnable example
+
+Series-A SaaS, $4.2M cash, fiscal-period quarterly.
+
+- Step 0 — `org-stage = series-a`. Band: "to PMF signal + buffer 6–9 months". Target = NRR > 110 % + segment proof + 9-month cycle ≈ 12–15 months.
+- Step 1 — net burn last 3 quarters: $480k / $510k / $560k → accelerating. Burn-multiple: 2.1 → 1.9 → 1.7 → improving despite accel-burn (revenue catching up).
+- Step 2 — at status-quo $560k/mo: 7.5 months runway. Target band 12–15 months. Gap = 4.5–7.5 months below band.
+- Step 3 — verdict = **raise now**. Gap closes into lower-bound; segment-proof demonstrable; burn-multiple direction is the credible story. Cross-cite H7 for pitch.
+- Step 4 — grow (don't cut). Cutting now would kill the burn-multiple-improvement story; the cut math is dilutive vs the raise.
+- Step 5 — emit `runway-frame.md`: `org-stage=series-a, gap=-5mo, fundraise=raise, cut-or-grow=grow, premortem="if raise fails by Q3, structural cut to non-headcount + extend by 4 months"`.

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/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).