@event4u/agent-config 2.7.0 → 2.9.0

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/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/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/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"`.