@event4u/agent-config 2.8.0 → 2.10.0

package/.agent-src/skills/build-buy-partner/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: build-buy-partner
+description: "Use when deciding insource vs outsource vs acquire — integration-cost analysis, dependency-risk, optionality preservation. Triggers on 'should we build', 'buy vs partner'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, product, customer-segment]
+---
+
+# build-buy-partner
+
+## When to use
+
+- A capability gap exists and the question is whether to build internally, buy a vendor / acquisition, or partner.
+- An "obviously build" choice has crept in by default; the question is whether it survives a deliberate compare.
+- A vendor / partner relationship is up for renewal; the question is whether to keep buying, switch, or insource.
+- An acquisition has been floated; the question is whether the integration cost justifies the speed-to-capability.
+
+Do NOT use for vendor selection within a "buy" decision (different skill), market-entry beachhead choice (route to `market-entry-analysis` (P2)), or scenario-shape comparison (route to `scenario-modeling` (O4); P1 consumes O4's bundle).
+
+## Cognition cluster
+
+- **Mental model 28 — Inversion.** *"What would force us to undo this choice in 18 months?"* Inversion surfaces the dependency-risk and integration-cost that the forward case understates. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 28.
+- **Mental model 21 — Second-order thinking.** Each option chains: build → ongoing maintenance + opportunity cost; buy → integration + lock-in; partner → dependency + boundary management. Single-order *"build is cheaper"* fails on the second-order. See `mental-models.md` § 21.
+- **Mental model 26 — Optionality.** Read each option by which choices it preserves (switch costs, re-build optionality, re-negotiation power) vs forecloses. The option with bounded foreclosure usually wins. See `mental-models.md` § 26.
+- **Context-spine — org-stage + product + customer-segment.** Read **org-stage** for capacity (pre-seed should buy almost everything non-core; growth-stage can build deeper). Read **product** for whether the capability is core-differentiation (build) or commodity (buy). Read **customer-segment** for whether enterprise-segment buyers require a build-it-yourself story.
+
+## Procedure
+
+### Step 0: Frame the capability as core vs commodity
+
+Two questions:
+
+1. *Is this capability a differentiator for our customers?* If yes → build-bias. If no → buy-bias.
+2. *Does it sit on the critical path of our product?* If yes + differentiator → build. If yes + commodity → buy. If no → partner.
+
+The matrix is the starting frame, not the answer. Override is allowed but requires writing the override reason.
+
+### Step 1: Inventory the three options concretely
+
+Do not compare abstractions. Each option = a concrete plan:
+
+1. **Build** — named team, named timeline, named ongoing-maintenance cost. *"Squad of 3 engineers for 6 months + 1 FTE ongoing"* not *"we'd build it"*.
+2. **Buy** — named vendor (or vendor shortlist), named pricing band, named integration scope. *"Vendor X at $80k ARR + 4-week integration"* not *"we'd find a vendor"*.
+3. **Partner** — named partner, named scope of dependency, named exit clause. *"Partner Y owns the X interface with 90-day exit"* not *"we'd partner"*.
+
+Un-named options compare to nothing.
+
+### Step 1.5: Inspect the differentiator claim
+
+Before locking the matrix from Step 0, inspect the claim that this is
+or isn't a differentiator. Two questions: *"would a customer leave us
+if a competitor had a better version of this capability?"* and *"is
+the current build advantage replicable by a vendor with one quarter of
+focused work?"* Both `yes` answers → the capability is less of a
+differentiator than the frame suggested; bias back to buy.
+
+### Step 2: Compute integration cost honestly
+
+Integration cost is the most under-counted number. For each option:
+
+1. **Build** — engineering time + management overhead + opportunity cost (what's the team *not* building?).
+2. **Buy** — vendor integration (weeks to first value) + ongoing change-management cost + lock-in (cost to switch off).
+3. **Partner** — boundary management + divergence cost (what happens when partner changes their roadmap?).
+
+A buy decision with 2-week integration is rare; budget 4–8 weeks for non-trivial integrations and 3–6 months for enterprise-grade ones.
+
+### Step 3: Inversion — name the failure mode for each option
+
+For each option, write the 18-month failure mode:
+
+1. **Build fails** — *"team built the wrong thing because requirements shifted under them"* / *"team left and knowledge walked"*.
+2. **Buy fails** — *"vendor changed pricing 3×"* / *"vendor acquired and roadmap diverged"* / *"vendor sunset the product line"*.
+3. **Partner fails** — *"partner's incentive misaligned"* / *"partner's customer became our competitor"*.
+
+If one option's failure mode is *"can't think of one"*, the analysis is incomplete; sit with it longer.
+
+### Step 4: Read optionality
+
+For each option:
+
+1. **Preserved options** — what future choices remain (switch vendor, re-build, deepen the build, expand the partnership).
+2. **Foreclosed options** — what future choices are off the table (re-build after 2 years of vendor lock-in; re-vendor after a build commitment; competing against a former partner).
+
+The decision is rarely about today's cost; it's about which option preserves the choices we'll need in 18 months.
+
+### Step 5: Decide and emit the ADR
+
+Pick one. Emit a build-buy-partner ADR via the `adr-create` skill, citing this skill's output. The ADR is the durable record; the artifacts here are the cognition that justify it.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Insource-vs-outsource-vs-acquire decisions on a capability gap.
+- Vendor renewal / re-evaluation where re-building or switching is on the table.
+
+**WHEN NOT to use this**
+
+- Vendor selection within a locked buy decision — different skill (not in this roadmap).
+- Market-entry beachhead choice — route to [`market-entry-analysis`](../market-entry-analysis/SKILL.md) (P2).
+- Scenario shape comparison — route to [`scenario-modeling`](../scenario-modeling/SKILL.md) (O4); P1 consumes O4's `scenario-bundle.md`.
+- Org-shape changes (reorg, team-split) — route to [`org-design`](../org-design/SKILL.md) (Q1); P1 composes Q1 for the "build" option's team shape.
+- Decision-record authoring mechanics — route to [`adr-create`](../adr-create/SKILL.md); P1 emits an ADR via that skill.
+
+## When the agent should load this
+
+- "Should we build this or buy a vendor?"
+- "Make-vs-buy on capability X."
+- "Should we partner with Y or build in-house?"
+- "Renew vendor Z or insource?"
+- "Bauen wir das selber oder kaufen?"
+
+## Output
+
+1. **`build-buy-partner-frame.md`** — capability framing (core / commodity, critical-path / not), three concrete options named, integration-cost table per option.
+2. **`failure-modes.md`** — 18-month inversion per option; named failure paths.
+3. **`optionality-map.md`** — preserved / foreclosed options per choice; recommended option with reasoning.
+4. **ADR** *(via `adr-create`)* — the durable decision record; this skill produces the cognition, `adr-create` produces the file.
+
+## Gotcha
+
+- "Build" defaults are the most common silent choice. Engineers' bias is to build; the absence of a buy / partner option in the inventory is the bug, not a feature.
+- Integration cost is under-counted by 2–4× in buy decisions. Always budget the high-end of the band.
+- "We'd lose strategic capability" is sometimes true and sometimes a rationalisation. Test against Step 0's differentiator question.
+- Acquisitions that look cheap on price are expensive on integration. The integration cost is rarely less than the acquisition cost over 18 months.
+
+## Do NOT
+
+- Do NOT compare abstractions; each option must be concrete (named team / vendor / partner).
+- Do NOT skip the inversion step — un-stressed options always look attractive.
+- Do NOT collapse the three options into "build vs buy" — partner is a distinct option with distinct optionality.
+
+## Runnable example
+
+Series-A SaaS, capability gap: real-time data pipeline.
+
+- Step 0 — differentiator (no, every SaaS has one), critical-path (yes). Matrix says buy.
+- Step 1 — Build: 3 eng × 6 mo + 1 FTE ongoing ≈ $1.2M / yr. Buy: Confluent at $180k ARR + 4-week integration. Partner: customer's existing pipeline with 90-day exit — but no incentive alignment with our segment.
+- Step 1.5 — would customers leave if competitor's pipeline was better? Probably not (commodity layer). Vendor-replicable in one quarter? Yes. Confirms buy-bias.
+- Step 2 — Build integration: 6 mo to first value + 3 mo to scale. Buy: 4 weeks to first value, 12 weeks for enterprise-segment readiness ≈ 4 months total. Partner: 2 weeks, but divergence cost unknown.
+- Step 3 — Build fails: team-knowledge walks. Buy fails: Confluent re-prices on usage (mitigation: 2-year contract). Partner fails: partner's roadmap diverges (mitigation: thin exit clause).
+- Step 4 — Build preserves deep integration optionality (foreclosed by buy). Buy preserves capital optionality (foreclosed by build). Partner preserves nothing of consequence.
+- Step 5 — Decide buy. Emit ADR via `adr-create` citing the matrix verdict + integration-cost band + Confluent-specific lock-in mitigation.

package/.agent-src/skills/comp-banding/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: comp-banding
+description: "Use when designing levels, comp bands, equity-vs-cash, geo adjustments, or raise vs promotion vs market correction. Triggers on 'set our comp bands', 'is this raise market'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, customer-segment, regulatory-regime]
+---
+
+# comp-banding
+
+## When to use
+
+- Levels and comp bands need a first pass (or an annual refresh) and the question is *what shape the ladder takes*, *where the bands sit*, and *how cash / equity trade*.
+- A specific compensation decision crosses the desk (counter-offer, retention, market correction, promotion, geo move) and the question is *which lever is the right one*.
+- A funding event, geo expansion, or org-stage transition makes the existing comp shape misfit reality.
+
+Do NOT use as a payroll / equity-administration substitute (this skill produces the cognition; payroll / cap-table tools implement), as an individual-performance review (route to Q4 `perf-feedback-craft`), or for hiring-loop / sourcing design (separate skill area).
+
+## Cognition cluster
+
+- **Mental model 1 — First principles.** Strip every comp question to: *what behavior are we paying for, over what horizon, with what risk-bearing?* Cash pays for present effort; equity pays for future co-built value with risk; bonus pays for outcome-linked behavior. Mixing the levers without first-principles intent produces confusion. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 1.
+- **Mental model 28 — Inversion.** *"What comp shape would force our best people to leave?"* Inversion surfaces the load-bearing risks (compression at senior levels, equity refresh gaps, geo arbitrage that punishes loyalty).
+- **Mental model 26 — Optionality.** Each comp lever preserves or forecloses future options. Above-band offers preserve hire optionality but foreclose internal-equity optionality. Equity-heavy mix preserves cash runway but forecloses people who need liquidity. Read every move as an optionality trade.
+- **Mental model 21 — Second-order thinking.** A raise to one person ripples (perceived parity, retention pressure on peers, expectation-setting for next cycle). A band shift ripples (new-hire offers anchor higher, internal expectations re-anchor). Comp moves rarely stay isolated.
+- **Context-spine — org-stage + customer-segment + regulatory-regime.** Read **org-stage** for what's affordable and credible (pre-seed: cash-light, equity-heavy; growth: cash-competitive at 50th–75th; late: cash-led, equity less load-bearing). Read **customer-segment** for which talent pool we compete in (enterprise sales needs enterprise pay shape). Read **regulatory-regime** for pay-transparency / disclosure obligations (EU directive, CA / CO / NY state laws).
+
+## Cross-wing handoff
+
+- Composed downstream of Q1 `org-design` — the level / band shape follows the structure decision; comp without a structure is rootless.
+- Hands off to Q3 `onboarding-program` for the time-to-productivity expectation that comp shape implies.
+- Hands off to O1 `unit-economics-modeling` for the OpEx impact of comp decisions on burn / runway.
+- Composed when J1 `regulatory-regime` flags pay-transparency obligations.
+
+## Procedure
+
+### Step 0: Inspect intent before framing the comp question
+
+Before designing or adjusting bands, name:
+
+1. *What behavior are we paying for?* (retention, attraction at top of market, alignment to long-term outcome, performance leverage).
+2. *Over what horizon?* (this quarter, this year, this 4-year vest cycle).
+3. *Whose risk are we asking the person to bear?* (cash risk = ours; equity risk = theirs; bonus-on-outcome = shared).
+
+The intent gates which lever moves; without it, comp decisions chase symptoms.
+
+### Step 1: Design the level ladder
+
+Levels are the spine; bands attach to levels, not the other way around:
+
+1. **Ladder breadth** — name how many levels each track has (IC vs management; eng / design / PM / sales / ops separate or unified).
+2. **Level criteria** — what behaviors and scope distinguish L4 from L5 from L6. Force concrete scope language, not adjective stacks ("strong" → "leads a 3–5 person workstream end-to-end").
+3. **Dual-track parity** — IC vs management at equivalent levels should pay parity within a small band, or the IC track erodes silently.
+4. **Skip-level distance** — a step from L4 to L5 is usually 12–24 months of demonstrated growth; smaller steps inflate the ladder.
+
+A ladder where every adjective is "strong" is a placebo; force scope and behavior language.
+
+### Step 2: Place the bands
+
+For each level × function × geo, name:
+
+1. **Cash band** — 25th / 50th / 75th / 90th percentile against a named market reference (one named comp dataset, e.g. Pave / Radford / OptionImpact, not "feels right").
+2. **Equity band** — initial grant + refresh cadence. Equity in % of company at grant for early stage; in $ value or share count for later stage.
+3. **Bonus / variable** — applies primarily to sales / GTM; not appropriate as standard for eng / product without an explicit reason.
+4. **Total comp** — cash + (equity ÷ vest years) + expected bonus. Compare TC against market reference, not just base.
+
+Where to sit: pre-seed / seed = below 50th cash, above 75th equity; Series A / B = 50th–75th cash, above 50th equity; growth = 50th–75th cash, 50th equity; late = 75th cash, below 50th equity.
+
+### Step 3: Geo and remote shape
+
+Pick one explicit policy; ambiguity here destroys trust:
+
+1. **Same-band-everywhere** — single global band; expensive but stops geo arbitrage gaming.
+2. **Tiered-by-geo** — 2–4 tiers (e.g. tier 1: SF/NYC; tier 2: other US metro; tier 3: rest of US; tier 4: EU; tier 5: rest of world). Document tier assignments transparently.
+3. **Cost-of-living indexed** — per-city multiplier from a published index (Numbeo / similar). Most transparent but creates fairness debates for premium-cost low-pay cities.
+
+A move within the same role across tiers needs a documented rule (re-band, hold harmless, partial adjust).
+
+### Step 4: Decide the lever for a specific case
+
+For a specific decision (raise, retention, market correction, promotion, counter-offer), pick exactly one primary lever:
+
+1. **Promotion** — when scope has grown to the next level; comp follows level. Wrong lever for "retention without scope growth".
+2. **Market correction** — when the person's comp drifted below band due to market movement; not contingent on performance. Apply to a cohort, not just the squeaky wheel.
+3. **Retention / counter-offer** — when external pull risks loss; size the cost-of-loss honestly (re-hire cost, knowledge loss, team morale). Use sparingly; each one re-prices the next.
+4. **Performance raise** — within band, for demonstrated above-expectation impact. Documented in performance evidence.
+5. **Equity refresh** — for retention beyond initial vest; typically annual for high-impact talent past year 2.
+
+Mixing levers ("a raise AND a promotion AND a refresh") confuses signal and inflates anchor for next cycle.
+
+### Step 5: Validate the comp decision before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Intent confirmed** — confirm Step 0 named the behavior, horizon, and risk-bearer; un-named intent means the lever is chosen on vibes and must be re-run.
+2. **Lever-vs-symptom check** — assert the chosen lever in Step 4 matches the diagnosed root cause; using promotion for retention without scope growth is canonical mis-use and fails the check.
+3. **Ripple sized** — verify the second-order ripple (peer parity, anchor for next-hire offers, internal-equity impact) is sized; un-sized ripples blow up at the next review cycle.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the comp artifact
+
+Produce the comp-banding artifact for the leadership decision-maker and / or the specific compensation case file. For band-design exercises, emit the ladder + bands + geo policy + lever-decision tree. For individual decisions, emit the diagnosed root cause + chosen lever + ripple-sized impact.
+
+## Related Skills
+
+**WHEN to use this**
+
+- First-pass level ladder + comp band construction.
+- Annual comp refresh against market movement.
+- Individual case decisions (raise, retention, promotion, geo move, counter-offer).
+- Funding-event / org-stage transition comp re-shape.
+
+**WHEN NOT to use this**
+
+- Performance / individual-feedback work — route to [`perf-feedback-craft`](../perf-feedback-craft/SKILL.md) (Q4).
+- Org / team structure decisions — route to [`org-design`](../org-design/SKILL.md) (Q1).
+- Onboarding / time-to-productivity — route to [`onboarding-program`](../onboarding-program/SKILL.md) (Q3).
+- Compensation-platform admin (Pave / Carta / Sequoia) — out of scope.
+
+## When the agent should load this
+
+- "Set our comp bands."
+- "Is this raise market?"
+- "Promotion or market correction?"
+- "How do we handle geo for remote hires?"
+- "Wie banden wir die Levels?"
+
+## Output
+
+1. **`level-ladder.md`** — tracks × levels × scope-and-behavior criteria × dual-track parity check.
+2. **`comp-bands.md`** — level × function × geo × cash / equity / variable bands referenced to a named market dataset.
+3. **`geo-policy.md`** — same-band / tiered / COL-indexed + tier assignments + move-across-tier rules.
+4. **`lever-decision.md`** *(per-case)* — diagnosed root cause × chosen lever × ripple sizing × counter-anchor for next cycle.
+
+## Gotcha
+
+- "Strong" / "senior" / "leads" without scope is a placebo level ladder. Force concrete language.
+- IC and management parity at equivalent levels matters more than people say; ICs notice within a quarter.
+- Counter-offers always cost more than they look on paper; they re-anchor the next person who threatens to leave.
+- Pay transparency laws are not optional and not consistent across geos; a band that looks fine in one state can be a posting violation in another.
+
+## Do NOT
+
+- Do NOT design bands without a named market reference dataset; "feels right" bands are unfalsifiable and erode trust.
+- Do NOT promote as a retention tactic without genuine scope growth; this is the canonical inflation mechanism.
+- Do NOT skip the ripple sizing; isolated comp moves are rare in practice.
+
+## Runnable example
+
+Series-B SaaS, 80 people, eng lead requests a 25 % raise for a senior eng with a competing offer.
+
+- Step 0 — Intent: retention; horizon = next 12 months; risk = loss of person + 6 months re-hire cost.
+- Step 1 — Ladder check: person is L5 senior; scope hasn't grown to L6 staff. Promotion is not the right lever.
+- Step 2 — Band check: current cash sits at 55th percentile per Pave; competing offer is at 90th. Band ceiling for L5 is 75th. 25 % raise would push above the L5 band ceiling.
+- Step 3 — Geo: person is remote tier 2; offer is remote tier 1. Tier-policy check: company policy allows tier 1 only on relocation; offer is staying tier 2.
+- Step 4 — Lever: not promotion (no scope growth), not full retention to competing offer (breaches L5 band ceiling), not market correction (already at 55th). Recommended lever: partial cash raise to 70th of L5 band + equity refresh sized to span 3-year retention horizon + named scope-growth path with explicit L6 promotion criteria over next 12–18 months.
+- Step 5 — Validate: intent named (retention with future scope growth as anchor); lever matches root cause without breaking ladder; ripple sized (two peer L5s are at 50th, will need parity correction within 6 months — budget that now).
+- Step 6 — Emit lever-decision artifact for VP Eng + finance approval; document scope-growth path in the perf-feedback system for the next review cycle.

package/.agent-src/skills/competitive-moat-analysis/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: competitive-moat-analysis
+description: "Use when mapping competitors, naming defensibility, and finding white-space — moat reasoning, where-to-play, where-not-to-play. Triggers on 'who are we competing with', 'what's our moat'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [customer-segment, product, org-stage]
+---
+
+# competitive-moat-analysis
+
+## When to use
+
+- A strategist needs a competitor map for a market / segment — not a feature-comparison sheet, but a *where-they-are-strong / where-we-are-strong / where-no-one-is* read.
+- A board pack or fundraise narrative claims a moat; the question is *which moat*, *how durable*, and *what would erode it*.
+- A market-entry decision needs white-space identification — where can we win cleanly because incumbents structurally can't follow?
+
+Do NOT use for narrative / messaging surface (route to Wing-3 `positioning-strategy` for the outward-facing pitch; this skill produces the internal cognition that pitch rests on), per-package adoption comparisons (route to `competitive-positioning` (Wing-1 package-peer comparison)), or build-vs-buy decisions (route to `build-buy-partner` (P1)).
+
+## Cognition cluster
+
+- **Mental model 18 — Where to play, where not to play.** A moat is read as much from *what we refuse to do* as from what we do. Trying to win everywhere = winning nowhere. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 18.
+- **Mental model 28 — Inversion.** *"What would force a customer to leave us for an incumbent?"* The inversion answer surfaces the load-bearing moat assumption. If the answer is *"nothing"*, the moat is wishful; if the answer is concrete, that's the real fragility. See `mental-models.md` § 28.
+- **Mental model 21 — Second-order thinking.** Moats compound or decay; *"feature parity today"* says nothing about *"feature parity in 18 months"*. Read each moat by its compounding rate, not its current state. See `mental-models.md` § 21.
+- **Context-spine — customer-segment + product + org-stage.** Read **customer-segment** for which incumbent matters in which segment (the enterprise incumbent is rarely the SMB incumbent). Read **product** for which moats are real vs roadmap. Read **org-stage** for moat realism (pre-revenue moats are claims; growth-stage moats are evidence).
+
+## Procedure
+
+### Step 0: Frame the competitive set honestly
+
+Most "competitor lists" are too broad. For each candidate competitor, ask:
+
+1. *Do they sell to our customer-segment slot, or an adjacent one?* Different segments = different competitive set.
+2. *Do customers actually evaluate them against us, or are they a "we sometimes get compared" mention?* Evaluation-set ≠ market-set.
+3. *Are they direct (same outcome) or indirect (different outcome, same budget line)?* Both matter; tag which.
+
+Output: the *evaluated-against* set, the *adjacent* set, and the *indirect-budget-competitor* set — three distinct lists.
+
+### Step 1: Map the moat dimensions
+
+Pick 4–7 dimensions where moats actually live — not feature checklists. Canonical dimensions:
+
+1. **Data network effect** — does data accumulated by each customer compound across all customers?
+2. **Two-sided network effect** — does each new participant make the product more valuable to existing participants?
+3. **Switching cost** — does integration depth, data lock-in, or workflow embeddedness raise the exit cost?
+4. **Distribution lock-in** — do we own a channel competitors can't replicate (community, partner ecosystem, OEM)?
+5. **Cost-structure advantage** — is our unit-economics floor structurally lower than competitors' (route to `unit-economics-modeling` (O1) for the read)?
+6. **Domain capability** — proprietary algorithm, regulatory licence, certification stack, or proprietary dataset.
+7. **Brand / trust** — only legitimate in regulated / high-stakes segments where trust is the gating factor.
+
+Don't list dimensions where no one has a moat; those are commodities.
+
+### Step 2: Score each competitor on each dimension
+
+For each (competitor × dimension) cell:
+
+1. **Their position** — `strong / moderate / weak / not-applicable`.
+2. **Our position** — same scale.
+3. **Evidence** — file, doc, customer quote, public artifact. Cells without evidence = *unknown*, not parity.
+
+The output is a matrix. Cells without evidence are surfaced, not silently called ties.
+
+### Step 3: Inspect the inversion — what would erode each moat we claim?
+
+For each dimension where we score `strong`:
+
+1. *What's the technical / business mechanism that holds it?*
+2. *What competitor move would erode it in 18 months?* (new pricing model, new vertical entry, new tech wave, regulatory shift)
+3. *What evidence would tell us it's eroding?* (leading signal, not lagging revenue)
+
+A moat without a named erosion path is unfalsifiable — flag as "claimed-moat, unstressed".
+
+### Step 4: Identify the white-space
+
+White-space = (segment × need) cells where no one currently has a strong position. For each:
+
+1. *Why is no one there?* (capability gap, distribution gap, no incumbent has it as a focal job, regulatory complexity)
+2. *Is the gap durable or just slow-to-fill?* (durable = structural barrier; slow = first-mover gets a 12-month window then incumbents follow)
+3. *Does our context-spine slot (org-stage, product, segment) let us address it?*
+
+White-space ≠ TAM; it's where we can plant a flag and defend it.
+
+### Step 5: Validate the moat read before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Evidence coverage** — confirm every `strong` cell cites concrete evidence; uncited `strong` cells are demoted to *claimed* and must be re-run.
+2. **Inversion mitigation** — assert that every claimed moat has a named erosion path and at least one leading signal to monitor; un-stressed moats are unfalsifiable and must be flagged.
+3. **White-space ≠ wishlist** — check that each white-space cell has a named structural reason no one is there; un-named white-space is wishful and must be demoted.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the moat read
+
+Produce the moat-and-white-space artifact. P3 feeds P2 (`market-entry-analysis`) for beachhead defensibility, P4 (`vision-articulation`) for "why us" framing, and Wing-3 `positioning-strategy` for the outward-facing narrative.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Internal moat reading for board, fundraise, strategy off-site.
+- Beachhead defensibility check before market entry.
+- White-space identification for product / segment expansion.
+
+**WHEN NOT to use this**
+
+- Outward-facing positioning narrative — route to Wing-3 [`positioning-strategy`](../positioning-strategy/SKILL.md); P3 produces the internal read, positioning-strategy produces the external pitch.
+- Package-vs-peer adoption comparison — route to [`competitive-positioning`](../competitive-positioning/SKILL.md) (Wing-1 meta).
+- Build-vs-buy on a capability gap — route to [`build-buy-partner`](../build-buy-partner/SKILL.md) (P1).
+- Market-entry sequencing — route to [`market-entry-analysis`](../market-entry-analysis/SKILL.md) (P2); P2 composes this skill for beachhead defensibility.
+- Vision narrative — route to [`vision-articulation`](../vision-articulation/SKILL.md) (P4); P4 composes this skill for the "why us" frame.
+
+## When the agent should load this
+
+- "Who are we actually competing with?"
+- "What's our moat?"
+- "Where's the white-space?"
+- "What would force a customer to leave us?"
+- "Wo gewinnen wir wirklich?"
+
+## Output
+
+1. **`competitive-set.md`** — evaluated-against / adjacent / indirect-budget lists, each named with one-sentence rationale.
+2. **`moat-matrix.md`** — competitor × dimension grid; evidence-cited cells; unknowns surfaced.
+3. **`moat-stress-test.md`** — for each claimed moat: erosion path, leading signals, falsifiability flag.
+4. **`white-space-map.md`** — (segment × need) cells no one owns; durability tag; addressability check against context-spine.
+
+## Gotcha
+
+- "Brand" as a moat is rarely real outside regulated / high-trust segments. Be skeptical.
+- "Feature parity" today is not a moat read; it's a snapshot. Read the compounding rate.
+- White-space without a named structural reason no one is there = wishlist. Push back hard on un-named white-space.
+- The competitive set is usually too broad. Most "competitors" don't show up in customer evaluation sets.
+
+## Do NOT
+
+- Do NOT treat feature lists as moat dimensions; moats live in compounding / lock-in / structural-cost dimensions.
+- Do NOT call cells parity when there's no evidence — surface as unknown.
+- Do NOT claim a moat without a named erosion path and leading signals.
+
+## Runnable example
+
+Series-B vertical SaaS in healthcare scheduling.
+
+- Step 0 — Evaluated-against: 2 vertical incumbents + 1 horizontal scheduling tool. Adjacent: 3 general-purpose calendar SaaS (different segment). Indirect: in-house clinic-management software custom builds.
+- Step 1 — Dimensions: switching cost (workflow embeddedness), domain capability (HIPAA + state-licensure handling), distribution lock-in (EHR-integration partnerships), cost-structure, data network effect.
+- Step 2 — Matrix scored with evidence: we score strong on domain capability (HIPAA certs + 50-state licensure rules) and switching cost (24-month deployment investment); incumbent A strong on distribution (5 EHR integrations); horizontal tool weak across all healthcare dimensions.
+- Step 3 — Erosion path for switching-cost moat: "incumbent A ships migration-tooling that cuts switch cost by 70 %." Leading signal: incumbent A hiring senior eng for "migration platform."
+- Step 4 — White-space: mid-size dental specialty groups (50–200 providers); incumbents focus on hospitals (too small) or solo practitioners (margin too thin). Structural reason: regulatory complexity per state × dental-specialty workflows mean horizontal tools don't customize enough; hospital-focused incumbents won't down-segment.
+- Step 5 — Validate: every strong cell evidence-cited; switching-cost moat has erosion path + leading signal; white-space has structural reason. Pass.
+- Step 6 — Emit moat-and-white-space artifact; P2 composes it for the dental-specialty beachhead defensibility read.

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

@@ -0,0 +1,147 @@
+---
+name: contracts-cognition
+description: "Use when reading a contract for risk and constraint — clause shape, redline priority, what the contract actually binds. Triggers on 'review this contract', 'what does this MSA constrain'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [regulatory-regime, customer-segment, org-stage]
+---
+
+# contracts-cognition
+
+## When to use
+
+- A draft MSA / DPA / SOW / vendor contract / partner agreement lands and a non-lawyer needs to read it for *what it actually constrains*, *which clauses carry real risk*, and *what to redline first*.
+- An existing contract is being renegotiated; the question is *which clauses are now misshapen* given current scale, regulatory regime, or customer mix.
+- A new customer contract triggers obligations (SLA, indemnity, audit, data-handling) that need to be sized against operational capacity before signing.
+
+Do NOT use as a substitute for actual legal counsel (this skill produces the *non-lawyer cognition* that prepares the conversation with counsel, not the legal opinion), for privacy-specific review (route to `privacy-review` (P6); this skill composes P6 for data clauses), or for contract management software / e-signature operations.
+
+## Cognition cluster
+
+- **Mental model 28 — Inversion.** *"What would force us to invoke this clause? What would force the counterparty to invoke it?"* Inversion surfaces which clauses are dormant boilerplate vs which are loaded triggers. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 28.
+- **Mental model 21 — Second-order thinking.** Each clause has a second-order shape: indemnity caps interact with insurance coverage; SLAs interact with operating-cost; auto-renewal interacts with switching cost. Reading clauses in isolation misses the load-bearing combinations. See `mental-models.md` § 21.
+- **Mental model 26 — Optionality.** Each clause either preserves or forecloses future choices (terminate-for-convenience preserves; auto-renewal forecloses; exclusivity forecloses; MFN forecloses). The cost of a clause is the optionality it removes. See `mental-models.md` § 26.
+- **Context-spine — regulatory-regime + customer-segment + org-stage.** Read **regulatory-regime** (J1) for floor-bound clauses (GDPR DPA terms, HIPAA BAA, SOC 2 audit). Read **customer-segment** for risk sizing (enterprise SLA terms ≠ SMB SLA terms). Read **org-stage** for what's affordable (early-stage = avoid uncapped indemnities; growth = can absorb tighter SLAs).
+
+## Procedure
+
+### Step 0: Frame the contract by intent
+
+Two questions before reading clauses:
+
+1. *What outcome are we trying to enable?* (sell to enterprise, integrate vendor, partner co-sell, license IP).
+2. *What outcomes are we trying to prevent?* (unbounded liability, lock-in, IP leakage, audit ambush, payment risk).
+
+Without intent, every clause looks equally important. With intent, 80 % of clauses are background and 20 % are load-bearing.
+
+### Step 1: Identify the load-bearing clause families
+
+Five families carry most real risk for non-lawyers:
+
+1. **Liability & indemnity** — caps, carve-outs, IP indemnity, mutual vs one-way. Uncapped indemnity is the canonical trap.
+2. **Term, renewal, termination** — auto-renewal, notice windows, termination-for-convenience vs for-cause, data-return obligations.
+3. **Data & privacy** — DPA, sub-processors, data location, breach notification, retention, deletion. Compose `privacy-review` (P6) for the deep read.
+4. **IP & confidentiality** — work-product ownership, license grants, confidentiality term, residual-knowledge clauses.
+5. **Commercial mechanics** — payment terms, MFN, exclusivity, change-of-control, audit rights.
+
+Other clauses (governing law, force majeure, severability, notices) are usually boilerplate; flag deviations but don't lead with them.
+
+### Step 2: Inspect each load-bearing family
+
+For each family, read three things:
+
+1. **The clause as written** — what does it literally say.
+2. **The clause invoked** — *"under what scenario does this clause fire?"*
+3. **The clause's tail risk** — *"what's the worst-case if it fires?"*
+
+A clause whose tail risk is bounded and small = accept. Bounded and large = redline to reduce. Unbounded = redline to cap or refuse.
+
+### Step 3: Run the inversion check
+
+For each load-bearing clause, ask:
+
+1. *"Would we sign this if the counterparty had 10× our leverage?"* Reveals which clauses we tolerate because of relationship, not because they're fair.
+2. *"What would we want if we were the counterparty?"* Reveals which clauses are mutual vs one-way unfairly.
+3. *"What scenario makes this clause matter in 18 months?"* If no scenario, the clause is dormant; if a plausible scenario exists, prioritize the redline.
+
+### Step 4: Build the redline priority list
+
+Rank redlines by:
+
+1. **Tail-risk size** — uncapped > capped-large > capped-small.
+2. **Probability of invocation** — high-likelihood clauses (auto-renewal, payment terms) outrank low-likelihood (force majeure).
+3. **Asymmetry** — one-way clauses where the counterparty bears no symmetric risk.
+4. **Optionality cost** — clauses that foreclose future moves (exclusivity, MFN, change-of-control restrictions).
+
+Top 3–5 redlines = the negotiation; everything else is acceptable or backlog.
+
+### Step 5: Validate the read before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Family coverage** — confirm each of the five load-bearing families was inspected (Step 2); silent skips mean the contract was not read, only skimmed.
+2. **Tail-risk sizing** — assert every top-5 redline has a named worst-case scenario and a named cap / carve-out / refusal-shape ask; un-sized redlines fail.
+3. **Counsel handoff** — check that the contract-cognition note explicitly flags which clauses need legal counsel review vs which are commercial / operational decisions; this skill does not replace counsel.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the contract-cognition note
+
+Produce the contract-cognition artifact for the negotiation lead (founder, sales lead, ops lead) and for counsel. The artifact is the non-lawyer cognition that prepares the conversation with counsel, not the legal opinion.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Reading a draft MSA / DPA / SOW / vendor / partner contract for risk and constraint.
+- Renegotiating an existing contract at a new scale or under a new regulatory regime.
+- Sizing customer-contract obligations against operational capacity.
+
+**WHEN NOT to use this**
+
+- Privacy-specific deep read — route to [`privacy-review`](../privacy-review/SKILL.md) (P6); this skill composes P6 for data clauses.
+- Data-classification / retention judgment — route to [`data-handling-judgment`](../data-handling-judgment/SKILL.md) (P7).
+- Build-vs-buy / partner-vs-vendor decision shape — route to [`build-buy-partner`](../build-buy-partner/SKILL.md) (P1); P1 outputs the *whether*, this skill outputs the *what to redline*.
+- Actual legal opinion — route to qualified counsel; this skill prepares the cognition for the counsel conversation, not replaces it.
+
+## When the agent should load this
+
+- "Review this MSA."
+- "What does this DPA actually bind us to?"
+- "Which clauses do we redline first?"
+- "Is this contract safe to sign?"
+- "Lies mir den Vertrag durch."
+
+## Output
+
+1. **`contract-frame.md`** — intent (what to enable / prevent), counterparty leverage read, regulatory-regime context.
+2. **`load-bearing-clauses.md`** — five families × clause-as-written + invocation scenario + tail risk per clause.
+3. **`redline-priority.md`** — top 3–5 redlines ranked by tail-risk × probability × asymmetry × optionality cost; named asks per redline.
+4. **`counsel-handoff.md`** — explicit list of clauses that need legal counsel review vs commercial / operational decisions.
+
+## Gotcha
+
+- Uncapped indemnity is the silent killer. If the cap is missing or excludes major risk categories (IP, data breach), it's the first redline.
+- Auto-renewal with short notice windows compounds across years — calendar the notice window the day the contract is signed.
+- "Industry-standard" is a marketing word, not a legal one. Push for the specific cap / term / carve-out.
+- Mutual NDAs that look symmetric often aren't — confidentiality term, residual-knowledge, and remedy clauses skew one-way silently.
+
+## Do NOT
+
+- Do NOT issue legal opinions; this skill prepares cognition for counsel, not replaces counsel.
+- Do NOT collapse all clauses into one list; the five families carry the real risk, treat them differently.
+- Do NOT skip the inversion check — clauses that look fine in our shoes often look terrible in the counterparty's.
+
+## Runnable example
+
+Growth-stage SaaS, customer is Fortune-500 enterprise, MSA draft from customer's legal.
+
+- Step 0 — Intent: enable enterprise deal, prevent uncapped liability + audit ambush + data-handling overreach.
+- Step 1 — Identify families: liability (mutual indemnity, uncapped on IP); term (3-year auto-renew, 90-day notice); data (DPA references but no DPA attached); IP (work-product ownership unclear for integration scripts); commercial (MFN clause buried in pricing schedule).
+- Step 2 — Inspect: uncapped IP indemnity → tail risk = bet-the-company (uncapped patent claim). Auto-renewal 3-year → tail risk = $1.2M locked in if missed notice. MFN → tail risk = forecloses bundle pricing across portfolio.
+- Step 3 — Inversion: would we sign this with 10× leverage? No. Symmetric? Indemnity is one-way; MFN is one-way.
+- Step 4 — Redline priority: (1) cap IP indemnity at 2× annual contract value with reasonable carve-outs; (2) reduce auto-renewal to 1 year, expand notice to 180 days; (3) strike MFN or limit to identical-SKU; (4) attach DPA before signing; (5) clarify integration-script IP ownership.
+- Step 5 — Validate: five families inspected; top-5 redlines sized with cap / refusal asks; counsel-handoff names IP indemnity + MFN as counsel-led, auto-renewal as commercial-led. Pass.
+- Step 6 — Emit contract-cognition note for negotiation lead; route IP indemnity + MFN to counsel; sales lead negotiates auto-renewal and DPA attachment.