@event4u/agent-config 2.8.0 → 2.9.0

package/.agent-src/skills/forecasting/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: forecasting
+description: "Use when constructing the finance-side forecast — top-down vs bottom-up shape, confidence bands, retro-loop. Triggers on 'build the forecast model', 'reconcile top-down with bottom-up'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [product, fiscal-period, customer-segment]
+---
+
+# forecasting
+
+## When to use
+
+- The annual plan or quarterly board pack needs a forecast model that survives a retro — not last quarter's number with a multiplier.
+- Top-down (TAM × penetration × motion) and bottom-up (deal-level) calls have diverged and the reconciliation hasn't been written.
+- A new finance-partner inherits a forecast and needs to rebuild the construction shape without inheriting the prior regime's optimism.
+
+Do NOT use to qualify a single deal (route to `deal-qualification-meddic`), construct the RevOps commit list (route to `forecast-accuracy` (H10) — finance owns the shape, RevOps owns the call), or run capital-runway scenarios (route to `runway-cognition` (O3)).
+
+## Cognition cluster
+
+- **Mental model 9 — Hypothesis-driven thinking.** Each forecast is
+  a falsifiable claim about a window. If the call cannot be falsified
+  inside the window, the call is a narrative, not a forecast. See
+  [`mental-models.md`](../../../docs/contracts/mental-models.md) § 9.
+- **Mental model 29 — Premortem.** Before locking the call, write the
+  post-window retro as if commit missed by 20 %. The premortem
+  surfaces which construction inputs were riding on weak evidence;
+  demote those before the call locks. See `mental-models.md` § 29.
+- **Mental model 16 — Leading vs lagging.** Closed-won is lagging;
+  pipeline coverage, segment conversion, and slot-completeness are
+  leading. A forecast built only on lagging signals can confirm but
+  not steer. See `mental-models.md` § 16.
+- **Context-spine — product + fiscal-period + customer-segment.**
+  Read the **product** slot for what is GA-shippable in the window;
+  the **fiscal-period** slot for the cadence the model must
+  reconcile against (monthly close vs quarterly board pack vs annual
+  plan vs multi-year plan); the **customer-segment** slot for
+  segment-historical close rates. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Inspect the construction shape
+
+Read the fiscal-period slot. Decide between three shapes:
+
+1. **Top-down** — anchor against TAM × penetration band × motion
+   band. Healthy for annual plans and multi-year plans where
+   bottom-up evidence is thin past one window.
+2. **Bottom-up** — sum deal-level conviction (composes H10
+   `forecast-accuracy` via the `forecast-construction-shape` ADR).
+   Healthy for quarterly windows where deal evidence is fresh.
+3. **Hybrid** — both, with an explicit reconciliation. Healthy when
+   top-down and bottom-up diverge by more than the historical
+   confidence band.
+
+State the choice. A forecast without a stated shape inherits the
+prior regime's shape silently.
+
+### Step 1: Construct the call against the shape
+
+For top-down: write `{tam, penetration_band, motion_band}` — every
+input cites its source. Penetration bands are evidence ranges, not
+single points; motion bands reflect channel mix.
+
+For bottom-up: consume H10's commit-list against the
+`forecast-construction-shape` interface. Sum commit-tagged ×
+in-window close-rate per segment.
+
+For hybrid: do both, then write the reconciliation. If top-down ≠
+bottom-up by more than the confidence band, the divergence is the
+forecast — not either number.
+
+### Step 2: Calibrate the confidence band
+
+Compute historical deviation from the last 4–8 windows of the same
+fiscal-period cadence. Attach as `{plus_pct, minus_pct}`. A band
+asymmetric on the downside is honest about prior misses; symmetric
+bands silently pretend prior accuracy.
+
+### Step 3: Premortem the construction
+
+Write *"if the forecast misses by 20 %, the reason is ___."* For
+top-down: which penetration / motion input was the load-bearing
+assumption? For bottom-up: which anchor deals carry > 10 % of
+commit? Demote inputs that the premortem can name as single-point
+risks.
+
+### Step 4: Emit the typed interface
+
+Produce `forecast-band.json` per the `forecast-construction-shape`
+ADR. H10 consumes the artifact for the commit-call. The fields:
+`construction_shape`, `commit_value`, `best_case_value`,
+`pipeline_value`, `confidence_band`, `retro_signature`,
+`segment_scope`, `fiscal_period`, `construction_inputs`. Drop the
+artifact in the location H10's `## Output` references.
+
+### Step 5: Run the accuracy retro-loop
+
+At window-end, compare predicted commit / best-case to actual
+closed-won. Compute per-segment and per-construction-input miss
+rate. Patterns that repeat for two windows become shape changes in
+Step 0 (e.g. switching from bottom-up to hybrid because deal
+evidence stopped predicting); one-off misses become input upgrades
+in Step 1.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Constructing the finance-side forecast (annual plan, board pack, multi-year plan).
+- Running the construction-shape retro and feeding it back into Step 0.
+
+**WHEN NOT to use this**
+
+- Single-deal qualification — route to [`deal-qualification-meddic`](../deal-qualification-meddic/SKILL.md).
+- Commit / best-case / pipeline categorisation of deals — route to [`forecast-accuracy`](../forecast-accuracy/SKILL.md) (H10); H10 consumes against this skill's `forecast-band.json` interface.
+- Cash-runway shape and fundraise-trigger heuristics — route to [`runway-cognition`](../runway-cognition/SKILL.md) (O3).
+- Multi-statement scenario construction over base / upside / downside — route to [`scenario-modeling`](../scenario-modeling/SKILL.md) (O4).
+
+Wing-4 handoff: this skill emits the `forecast-band.json` artifact
+that `forecast-accuracy` (H10, Wing-3) reads. Per
+`docs/contracts/adr-forecast-construction-shape.md`,
+`docs/guidelines/wing4-handoff.md` § Chain 4.
+
+## When the agent should load this
+
+- "Build the annual forecast model."
+- "Top-down and bottom-up disagree — reconcile them."
+- "Why was last quarter's forecast off?"
+- "Was machen wir bei der Forecast-Konstruktion anders?"
+
+## Output
+
+1. **`forecast-band.json`** *(Wing-3 / Wing-4 typed interface)* — `construction_shape`, `commit_value`, `best_case_value`, `pipeline_value`, `confidence_band`, `retro_signature`, `segment_scope`, `fiscal_period`, `construction_inputs`. Per `adr-forecast-construction-shape.md`.
+2. **`construction-notes.md`** — shape chosen + why; per-input evidence; reconciliation note (hybrid only).
+3. **`premortem.md`** — "if we miss by 20 %, the reason is ___"; tagged demotions from Step 3.
+4. **`retro-deltas.md`** *(at window-end)* — predicted vs actual per construction input; shape-change recommendation if the pattern repeats.
+
+## Gotcha
+
+- A forecast without a stated `construction_shape` inherits last regime's shape silently. Always emit the field.
+- Symmetric confidence bands lie about prior misses. If the last two windows missed on the downside, the band is asymmetric.
+- Top-down models with single-point penetration assumptions are scenarios in disguise. Use bands.
+- Hybrid models that don't write the reconciliation are top-down models with bottom-up garnish.
+
+## Do NOT
+
+- Do NOT collapse hybrid forecasts into a single number without keeping the divergence visible.
+- Do NOT skip Step 4 — the typed interface is what makes H10 reproducible.
+- Do NOT change the construction shape on a single-window miss; shape changes require a two-window pattern.
+
+## Runnable example
+
+End of FY: annual plan + Q1 commit both due.
+
+- Step 0 — fiscal-period slot says `annual` + `quarterly`. Annual is top-down; Q1 is bottom-up.
+- Step 1 — top-down: TAM $4.2B, penetration band 0.6–0.9 %, motion band SaaS-mid; expected $25–38M ARR. Bottom-up: H10 commit-list sums to $8.1M in Q1, segment close rate 78 %.
+- Step 2 — last 4 quarters deviation: +6 % / –14 %. Confidence band attached.
+- Step 3 — premortem: top-down anchored on penetration upper bound; demoted to 0.6–0.75 %. Bottom-up: two anchor deals tagged single-risk procurement; demoted.
+- Step 4 — emit `forecast-band.json`: `construction_shape=hybrid`, commit $6.3M, best-case $8.1M, band +6/–14 %, retro_signature `quarterly | [+6, –14]`, segment_scope mid-market, fiscal_period `quarterly`.
+- Retro — at quarter-end, actual $6.1M; band held. Annual top-down revisit in two quarters.

package/.agent-src/skills/hiring-loop-design/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: hiring-loop-design
+description: "Use when shaping an engineering hiring loop — stages, take-home vs live, calibration, bar-raiser, signal-vs-noise audit. Triggers on 'design our interview loop', 'audit our hiring bar'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, product, customer-segment]
+---
+
+# hiring-loop-design
+
+## When to use
+
+- A first engineering hiring loop is being designed (early-stage co, first dedicated EM, first PM hire) and the question is *what stages, in what order, with what signal each*.
+- An existing loop is producing inconsistent outcomes (high false-positive rate, high false-negative rate, long time-to-hire) and the question is *which stage to fix*.
+- A new role family inside engineering is opening (first staff IC, first SRE, first ML eng) and the question is *what does the loop look like for this archetype*.
+
+Do NOT use this for non-engineering hiring as the primary surface (sales / GTM hiring is a different loop shape entirely), as a sourcing / recruiting-pipeline skill (separate surface area), or for applicant-tracking-system configuration.
+
+## Cognition cluster
+
+- **Mental model 1 — First principles.** Strip hiring to: *what signal does each stage produce that no other stage can produce?* Stages that duplicate signal waste candidate-time and interviewer-time. The strongest loops have one stage per signal, not five stages probing the same thing. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 1.
+- **Mental model 28 — Inversion.** *"What would make a great hire withdraw from this loop?"* — usually: 7+ stages, take-home > 6 hours, no role-context conversation, long calendar gaps, no senior-IC time, no offer-narrative. Inversion surfaces the canonical withdrawal causes; great candidates have options and use them.
+- **Mental model 21 — Second-order thinking.** A loose bar at L4 produces a chain: weaker L4 → harder L5 calibration → erodes ladder credibility → ICs leave. A single accept-the-no-vote ripples for 2+ years. The cost of a wrong hire dwarfs the cost of a missed hire; bar discipline is a multi-year compounding decision.
+- **Mental model — Base rates.** Most signals in interviews are noise; the most-confident signal-claim is usually the most-overfit to one observation. Calibrate against the base rate: *"out of 10 candidates who passed this stage with this signal, how many succeeded at 12 months?"* If unknown, the stage is unfalsifiable.
+- **Context-spine — org-stage + product + customer-segment.** Read **org-stage** for what's affordable (pre-seed: 3-stage loop, fast; growth: 5-stage with calibration; late: 5–6 with bar-raiser). Read **product** for what behaviors matter (deep-systems = system-design heavier; consumer = velocity + judgment heavier; regulated = ethics + judgment heavier). Read **customer-segment** for stakeholder-management exposure needed.
+
+## Cross-wing handoff
+
+- Composed downstream of Q1 `org-design` — the role-family shape determines the loop shape; hiring without a clear role definition is broken from stage 1.
+- Composed downstream of Q4 `perf-feedback-craft` — the calibration session is structurally a feedback exchange about a candidate; Q4's SBI + ladder-of-inference apply.
+- Hands off to Q3 `onboarding-program` — the loop's signal evidence becomes the day-1 ramp-evidence base.
+- Hands off to Q2 `comp-banding` for the offer construction step.
+
+## Procedure
+
+### Step 0: Define the role-shape before designing the loop
+
+For the role being hired, name:
+
+1. **Level** — L3 / L4 / L5 / L6 / staff / principal. Levels matter because signal evidence changes per level (L4 needs strong execution signal; L6 needs leverage / system-design signal).
+2. **Archetype** — IC-builder / IC-strategist / IC-system-designer / manager / staff-multiplier. Same level, different archetype = different loop shape.
+3. **First-90-day deliverable** — what should this person ship by day 90. Concrete enough to design loop signals against.
+
+A loop designed without a role definition produces noise. Force the role definition step.
+
+### Step 1: Map signal needs to stages
+
+For the role from Step 0, enumerate the signals that need direct evidence:
+
+1. **Coding / craft** — for IC roles. Live coding, take-home, or pair-programming.
+2. **System design** — for L5+. Two-hour bounded-scope problem.
+3. **Domain judgment** — for senior roles. Behavioral case with context-specific tradeoffs.
+4. **Communication / stakeholder** — for any role. Cross-functional collaboration exercise.
+5. **Leadership / multiplier** *(L6+)* — narrative of past leverage, mentoring decisions, ladder reasoning.
+6. **Values fit** — explicitly NOT culture fit. Concrete questions about handling pressure / disagreement / failure.
+
+One signal per stage. If two stages probe the same signal, kill one.
+
+### Step 2: Pick the stage shape per signal
+
+For each signal, pick the lightest-touch stage that produces the signal cleanly:
+
+1. **Recruiter / role-context call** *(30 min)* — role + company + light values. NOT a screen.
+2. **Hiring-manager screen** *(45 min)* — judgment + role-fit + reverse-context. Required.
+3. **Coding signal** — choose: (a) take-home ≤ 3 hours with explicit time-cap (most candidate-respectful for senior); (b) live coding 60 min (for L3–L4, faster signal); (c) pair-programming 90 min (best signal but heavy on interviewer time).
+4. **System design** *(2 hours, L5+)* — bounded scope; rubric set in advance.
+5. **Behavioral / domain judgment** *(45–60 min)* — structured by signal area; SBI-anchored prompts.
+6. **Leadership / values** *(45–60 min)* — narratives + specific past-decision probes.
+7. **Bar-raiser / cross-team** *(45 min, L5+)* — perspective from outside the hiring team to check ladder consistency.
+
+Take-home > 6 hours = candidate-hostile and produces survivorship-biased pools (only those with no other options finish). Keep ≤ 3 hours or skip.
+
+### Step 3: Design the rubric per stage
+
+Each stage gets a written rubric before the first interview runs:
+
+1. **Signal target** — what behavior demonstrates the signal at this level.
+2. **Anti-signal** — what behavior fails the signal (named, not inferred).
+3. **Strong-no-hire / no-hire / hire / strong-hire** — four-band scoring, not 5-band (5-band collapses to "3" for everything).
+4. **Evidence anchor** — what the interviewer writes down to support the rating; rating without evidence = inadmissible.
+
+Loops without rubrics produce gut-feel hires and hidden bias. Force rubrics before the loop opens.
+
+### Step 4: Calibration session shape
+
+For every offer-eligible candidate, run a calibration session before sending offer:
+
+1. **All interviewers attend** — synchronous or async-with-deadline.
+2. **Evidence-first reading** — each interviewer reads their rubric + evidence aloud (or shares the doc) before opinions are stated.
+3. **Bar-raiser veto** *(L5+)* — bar-raiser can no-hire even when the team votes yes; reverse is not true (team can no-hire over bar-raiser yes).
+4. **Decision** — strong-hire if all four bands are hire-or-above, no single strong-no; gray-zone = no-hire by default (the cost of a wrong hire dwarfs the cost of a missed hire).
+
+A loop without calibration loosens; the bar erodes by 5% per quarter without explicit recalibration cycles.
+
+### Step 5: Validate the loop design before opening it
+
+Before running the first candidate through, inspect three things:
+
+1. **Signal-stage mapping check** — confirm Step 1's signals each map to exactly one stage from Step 2; duplicate-signal stages fail and must be merged or dropped.
+2. **Rubric completeness** — assert every stage in Step 3 has a written rubric with signal + anti-signal + four-band scoring + evidence anchor; missing rubrics fail.
+3. **Candidate-time check** — verify total candidate hours ≤ 8 (5 interview hours + 3 take-home); loops exceeding 8 hours produce survivorship bias and erode top-of-funnel.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the hiring-loop design
+
+Produce the loop-design artifact for the hiring team. The artifact contains the role-shape, the stage-signal map, the per-stage rubrics, the calibration shape, and the candidate-time budget. The first three candidates after the loop opens trigger a retrospective check (signal-vs-actual review).
+
+## Related Skills
+
+**WHEN to use this**
+
+- New engineering role family being opened.
+- First-pass hiring loop design.
+- Audit of an existing loop with inconsistent outcomes.
+- Calibration / bar-raiser design.
+
+**WHEN NOT to use this**
+
+- Non-engineering hiring loops (GTM / sales / ops) — different loop shape; out of scope here.
+- Role / level decisions independent of hiring — route to [`comp-banding`](../comp-banding/SKILL.md) (Q2) for ladder design.
+- Feedback shape — route to [`perf-feedback-craft`](../perf-feedback-craft/SKILL.md) (Q4); S2 composes Q4 at the calibration session.
+- Onboarding after hire — route to [`onboarding-program`](../onboarding-program/SKILL.md) (Q3).
+
+## When the agent should load this
+
+- "Design our interview loop."
+- "Audit our hiring bar."
+- "Should we use a take-home?"
+- "Why are we mis-hiring at L5?"
+- "Wie sieht unser Hiring-Loop für Staff Engineer aus?"
+
+## Output
+
+1. **`role-shape.md`** — level + archetype + first-90-day deliverable definition.
+2. **`stage-signal-map.md`** — signal-needed × stage × time-budget × interviewer pool.
+3. **`per-stage-rubrics.md`** — signal + anti-signal + four-band scoring + evidence anchor per stage.
+4. **`calibration-shape.md`** — session format + bar-raiser rules + gray-zone default.
+5. **`candidate-time-budget.md`** — total candidate hours + take-home cap + scheduling shape.
+
+## Gotcha
+
+- "Culture fit" is a known bias-amplifier; use "values fit" with concrete questions about pressure / disagreement / failure.
+- Take-home longer than 3 hours = survivorship bias in your funnel; you get only those with no other options.
+- Loops that go above 5 onsite hours produce candidate withdrawal; great candidates have options.
+- A no-rubric loop produces "felt good in the room" hires that don't replicate.
+- Gray-zone calibration default must be no-hire; cost of false-positive dwarfs cost of false-negative.
+
+## Do NOT
+
+- Do NOT design a loop without a written role-shape; un-defined roles produce un-falsifiable signals.
+- Do NOT score on 5-band scales; everything collapses to "3" and the rubric becomes decorative.
+- Do NOT skip calibration on a "we all agree" basis; the disagreements are where the signal lives.
+
+## Runnable example
+
+Series-B SaaS opens its first staff-IC role; current loop is L4-shaped (45-min coding + 60-min behavioral + offer) and last two staff-level offers churned at 9 months.
+
+- Step 0 — Role-shape: L6 staff IC, archetype = system-designer with multiplier impact. First-90-day deliverable: scope and own one cross-team platform initiative.
+- Step 1 — Signal needs: system design (L6 anchor), domain judgment, leadership / multiplier, coding sanity-check, values fit. Five signals.
+- Step 2 — Loop: recruiter call (30) + HM screen (45) + system design (120) + domain judgment behavioral (60) + leadership narrative (60) + bar-raiser (45) + light coding sanity-check (60). Total candidate time: 7 hours + 0 take-home = 7 hours. Within 8-hour budget.
+- Step 3 — Rubrics drafted per stage; system-design rubric anchored to "drove three nontrivial architecture decisions with explicit tradeoffs" not "designed a great system".
+- Step 4 — Calibration: all 7 interviewers + bar-raiser; evidence-first; gray-zone defaults to no-hire; bar-raiser can veto.
+- Step 5 — Validate: signal-stage 1:1 mapping (no duplication); rubrics complete; 7 hours fits the 8-hour budget. Pass.
+- Step 6 — Emit loop; first three candidates trigger retrospective; review whether system-design rubric is calibrated to actual L6 staff behavior or diverging toward L5.

package/.agent-src/skills/market-entry-analysis/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: market-entry-analysis
+description: "Use when sequencing market entry — geo / segment / vertical, beachhead selection, regulatory-delta. Triggers on 'should we enter market X', 'which segment first'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [customer-segment, regulatory-regime, product]
+---
+
+# market-entry-analysis
+
+## When to use
+
+- A new market is on the table — geographic (EU, US, APAC), segment (SMB → mid-market → enterprise), or vertical (healthcare, fintech, manufacturing) — and the question is whether to enter, where to start, and in what sequence.
+- A current market is saturating and the question is which adjacent market unlocks the next growth window.
+- A regulatory shift opens or closes a market; the question is whether the new constraint changes the entry case.
+
+Do NOT use for build-vs-buy decisions on capability gaps (route to `build-buy-partner` (P1)), positioning narrative (route to `competitive-positioning` (P3); this skill composes P3), or per-customer economics within the entered market (route to `unit-economics-modeling` (O1)).
+
+## Cognition cluster
+
+- **Mental model 23 — Beachhead.** Pick a single segment / geo / vertical where the constraints favour winning, then expand from a position of strength. Trying to enter "the whole market" with no beachhead is the canonical failure pattern. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 23.
+- **Mental model 21 — Second-order thinking.** Entry costs (sales motion, regulatory compliance, segment-specific support) compound across markets. Reading entry as *"just open the door"* misses the second-order shape of multi-market operations. See `mental-models.md` § 21.
+- **Mental model 16 — Leading vs lagging.** Revenue from new market is lagging; **segment-specific pipeline coverage** + **win rates against incumbents in target segment** are leading. Reading only lagging signals = entering markets that already won't work. See `mental-models.md` § 16.
+- **Context-spine — customer-segment + regulatory-regime + product.** Read **customer-segment** for which buyer cohort the entry targets; **regulatory-regime** for the compliance delta (often the load-bearing cost in geo expansion); **product** for what's GA-shippable in the target market without re-platforming.
+
+## Procedure
+
+### Step 0: Frame the entry axis
+
+Pick **one** of three axes; do not mix:
+
+1. **Geo** — new region (US → EU, EU → APAC). Load-bearing constraint = regulatory-regime delta.
+2. **Segment** — new buyer cohort (SMB → mid-market → enterprise). Load-bearing constraint = sales-motion shift.
+3. **Vertical** — new industry (horizontal → healthcare). Load-bearing constraint = domain knowledge + segment-specific integrations.
+
+Mixing axes ("enter European healthcare enterprise") = three entries simultaneously. The correct framing is to pick one axis at a time and sequence the others.
+
+### Step 1: Select the beachhead
+
+Within the chosen axis, score 3–5 candidate beachheads on:
+
+1. **Constraint favourability** — does the segment / geo's constraint shape favour us? (e.g. for a self-serve product, SMB favours; enterprise penalises).
+2. **Reference-customer reachability** — can we land 3–5 named reference customers in the next two windows?
+3. **Regulatory delta** — compliance cost to operate (read `regulatory-regime` slot; e.g. EU + B2C + processing PII = GDPR-floor; EU + B2B + no PII = thin delta).
+4. **Expansion path** — does winning this beachhead unlock the adjacent ones, or is it a dead end?
+
+The beachhead is rarely the largest segment; it's the segment where we win cleanly and from which adjacent segments become accessible.
+
+### Step 2: Inspect the entry cost
+
+Three concrete cost categories — each named, not estimated:
+
+1. **Sales motion** — does the existing motion translate? (Self-serve → enterprise requires inside-sales + AE buildout; SMB → mid-market requires AE specialisation.)
+2. **Product delta** — what's missing for the target segment? (Compliance certs, SSO, audit logs, locale support, segment-specific integrations.)
+3. **Operating cost** — entity setup, tax, legal, segment-specific support. Geo entries add a 3–6 month operating-readiness window.
+
+Total entry cost = these three. Compare against `runway-frame.md` (O3) for whether the band has headroom.
+
+### Step 3: Inversion — name the failure mode
+
+For the chosen beachhead, write the 18-month failure mode:
+
+1. *"We entered and the incumbent's playbook neutralised us"* — incumbent's segment-specific advantage held.
+2. *"We entered and the sales motion didn't translate"* — assumed motion (self-serve) didn't work in the segment (enterprise).
+3. *"We entered and the regulatory cost ate the unit economics"* — compliance delta was load-bearing and under-estimated.
+
+If the failure mode has no mitigation, the entry is not ready. Sit with it.
+
+### Step 4: Sequence the expansion
+
+Beachhead = first move. Map the next 2–3 expansion moves explicitly:
+
+1. *"Win beachhead → unlock adjacent segment X (same motion, larger TAM) → unlock adjacent geo Y (same segment, regulatory delta manageable)."*
+2. *"Win beachhead → unlock co-sell with vendor Z → unlock vertical W."*
+
+Un-sequenced beachhead wins are dead-ends. The sequence is the long-game; the beachhead is just the first move.
+
+### Step 5: Validate the entry case before emitting
+
+Before emitting the entry plan, verify three things:
+
+1. **Beachhead defensibility** — confirm the chosen beachhead scores higher than the runner-up on at least two of the four Step-1 dimensions; if it ties or wins on one only, the choice is brittle and must be re-run.
+2. **Entry cost vs runway band** — check that the Step-2 entry cost lands inside the `runway-frame.md` (O3) band; if it doesn't, the entry is not yet financeable and must be deferred or staged.
+3. **Failure-mode mitigation** — assert that the Step-3 failure mode has a named mitigation; an un-mitigated failure mode means the analysis is incomplete.
+
+All three must pass. If any fails, the entry plan is not ready to emit; return to the failing step.
+
+### Step 6: Emit the entry plan
+
+Produce the entry plan artifact. P2 composes P3 (`competitive-positioning`) for the narrative against incumbents in the target segment.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Sequencing market entry across geo / segment / vertical axes.
+- Choosing the beachhead within a chosen entry axis.
+
+**WHEN NOT to use this**
+
+- Build-vs-buy capability decisions — route to [`build-buy-partner`](../build-buy-partner/SKILL.md) (P1).
+- Positioning narrative against incumbents — route to [`competitive-positioning`](../competitive-positioning/SKILL.md) (P3); this skill composes P3.
+- Per-customer economics in the target market — route to [`unit-economics-modeling`](../unit-economics-modeling/SKILL.md) (O1).
+- Channel / funnel design for the entry — route to Wing-3 [`funnel-analysis`](../funnel-analysis/SKILL.md) and [`content-funnel-design`](../content-funnel-design/SKILL.md).
+
+## When the agent should load this
+
+- "Should we enter the EU market?"
+- "Which segment do we go to next — mid-market or enterprise?"
+- "Pick the beachhead for our vertical expansion."
+- "Wo greifen wir als erstes an?"
+
+## Output
+
+1. **`entry-axis-frame.md`** — chosen axis (geo / segment / vertical), why this axis first, what's deferred.
+2. **`beachhead-scorecard.md`** — 3–5 candidate beachheads scored on the four Step-1 dimensions; named winner with reasoning.
+3. **`entry-cost-table.md`** — sales-motion delta, product delta, operating cost; compared against runway band.
+4. **`expansion-sequence.md`** — beachhead + next 2–3 moves, with the unlock-mechanism named per move.
+
+## Gotcha
+
+- "Enter the European enterprise healthcare market" mixes three axes. Pick one.
+- The largest segment is rarely the right beachhead; the segment where constraints favour us is.
+- Geo regulatory delta is the most under-estimated cost. Budget the high-end of the band for compliance.
+- Beachhead win without sequenced expansion = isolated revenue stream that never compounds.
+
+## Do NOT
+
+- Do NOT mix entry axes — sequence them.
+- Do NOT pick a beachhead without a named 18-month failure mode + mitigation.
+- Do NOT skip the expansion sequence — the beachhead's value is which next moves it unlocks.
+
+## Runnable example
+
+Horizontal SaaS, US-only, mid-market, considering EU expansion.
+
+- Step 0 — axis = geo (EU). Defer segment (stay mid-market) and vertical (stay horizontal).
+- Step 1 — candidate beachheads: DACH, Nordics, UK, Benelux. Scored: UK wins on constraint-favour (English-language sales motion translates, common-law contract familiarity), reference-reachability (5 mid-market UK customers reachable via existing channels), regulatory delta (UK-GDPR ≈ EU-GDPR floor with thinner data-residency requirement), expansion path (UK → Benelux → DACH).
+- Step 2 — Sales motion: existing AE motion translates to UK. Product delta: data-residency in EU (12 weeks). Operating cost: UK Ltd entity, VAT registration ≈ 3 months.
+- Step 3 — failure mode: "incumbent's UK channel partnerships locked us out of mid-market." Mitigation: direct-AE motion + content-led pipeline.
+- Step 4 — sequence: UK (beachhead) → Benelux (same motion, thin regulatory delta) → DACH (German-speaking sales hire required, larger TAM).
+- Step 5 — emit entry plan + compose P3 for UK-vs-incumbents positioning.

package/.agent-src/skills/onboarding-program/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: onboarding-program
+description: "Use when shaping employee onboarding — time-to-productivity, role-by-role program, mentor pairing, 30/60/90 milestones. Triggers on 'design our onboarding', 'why are new hires ramping slow'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, product, customer-segment]
+---
+
+# onboarding-program
+
+## When to use
+
+- A first onboarding program is needed because hires are arriving and ramping is ad-hoc, expensive, and slow.
+- An existing program is producing inconsistent ramp times across roles or cohorts and the question is *where the program leaks productivity*.
+- A new role family (first sales hire, first designer, first SRE) is being added and the question is *what role-shaped onboarding looks like for this function*.
+
+Do NOT use as a customer-onboarding surface (route to Wing-3 [`onboarding-design`](../onboarding-design/SKILL.md) (H11); this skill is internal-employee, that one is external-customer), as a performance-feedback skill (route to Q4 `perf-feedback-craft`), or for HRIS-onboarding-module configuration.
+
+## Cognition cluster
+
+- **Mental model 1 — First principles.** Strip onboarding to: *what does this person need to know, do, and decide alone before being net-positive?* Most onboarding programs over-index on what's easy to teach (history, slides) and under-index on what's hard (decision rights, who-knows-what, codebase / domain context). See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 1.
+- **Mental model 21 — Second-order thinking.** Onboarding is paid for in mentor time. A 4-hour-per-week mentor commitment from a senior person costs more than people realise; mentor capacity is the binding constraint on hiring velocity. Read mentor cost as part of the program, not a free input.
+- **Mental model 28 — Inversion.** *"What would make this hire fail in their first 90 days?"* Inversion surfaces the load-bearing risks (unclear scope, no early win, missing tools, no peer relationship). Most onboarding failures trace to one of these four, not to skill gaps.
+- **Mental model 26 — Optionality.** A heavy template onboarding preserves *consistency* optionality but forecloses *role-specific* optionality. A pure free-form onboarding preserves customization but forecloses scalability. Pick the trade explicitly per role family.
+- **Context-spine — org-stage + product + customer-segment.** Read **org-stage** for what's affordable (10-person co: founder onboards; 50-person co: managers + buddies; 150+: dedicated onboarding owner). Read **product** for domain complexity (deep regulated domain = longer ramp). Read **customer-segment** for which roles need customer-context immersion early.
+
+## Cross-wing handoff
+
+- Composed downstream of Q1 `org-design` — onboarding shape follows team structure; onboarding without a clear team home is broken from day one.
+- Composed downstream of Q2 `comp-banding` — level + scope expectations from comp banding anchor the ramp expectations.
+- Hands off to Q4 `perf-feedback-craft` for the first 30 / 60 / 90 feedback checkpoint shape.
+- Distinct from Wing-3 H11 `onboarding-design` (customer onboarding) — different audience, different proof bar.
+
+## Procedure
+
+### Step 0: Identify role-family and ramp definition
+
+Before designing the program, name:
+
+1. *What role family is in scope?* (eng IC, eng manager, PM, design, sales AE, sales SDR, CS, ops, finance). Onboarding shape varies sharply by family.
+2. *What does "ramped" mean for this family?* — define net-positive in concrete behavior: an eng IC ships a PR alone by week 4 and owns a workstream by week 12; an AE books N qualified meetings by week 4 and closes a deal by quarter end. Adjective-only definitions ("getting up to speed") fail the bar.
+3. *What's the realistic time-to-ramp benchmark?* — typically 30 / 60 / 90 days for individual contributors; 6 months for managers; 6–12 months for senior leaders. Compare proposed program length to benchmark.
+
+A program with no concrete ramped-definition is unfalsifiable.
+
+### Step 1: Map what the role needs to know, do, decide alone
+
+For the role family, enumerate three buckets:
+
+1. **Know** — domain context (industry, regulation, product), system context (codebase tour, dataflow, ops), people context (who owns what, who decides what). Force concrete artifacts (which doc, which repo, which dashboard) — not abstract topics.
+2. **Do** — first owned task, first reviewed task, first solo task, first shipped task. Sequence from low-risk to medium-risk; arrange to produce one demonstrable early win in week 1–2.
+3. **Decide alone** — what kind of decision can this person make without consulting? Spell out the boundary; the absence of this is the #1 cause of slow ramp.
+
+Most onboarding programs cover Know well, Do partially, Decide-alone almost never. The last bucket is the leverage point.
+
+### Step 2: Design 30 / 60 / 90 milestones
+
+For each milestone, name:
+
+1. **30-day** — Know complete; first owned task shipped; named buddy and named manager 1:1 cadence locked.
+2. **60-day** — Owns a workstream segment; has produced one visible artifact for the team; has had at least one feedback checkpoint (composes Q4).
+3. **90-day** — Net-positive on standalone contribution; named scope for next quarter; has built one cross-team relationship.
+
+Each milestone needs an objective check (shipped artifact, behavior observed) — not "feels good" attestation.
+
+### Step 3: Pair the mentor / buddy / manager triad
+
+Three roles, distinct purposes:
+
+1. **Manager** — sets scope, removes blockers, runs 1:1 cadence (weekly first 90 days, biweekly after).
+2. **Buddy** — peer-level, week-1 to week-12, low-friction questions, social onboarding. Buddy is not a mentor; mixing the role overloads the buddy.
+3. **Mentor** *(optional, role-dependent)* — senior in the craft, monthly cadence, growth-focused. Reserved for higher-stakes hires (senior eng, manager, first-in-role).
+
+Mentor / buddy capacity is the binding constraint; if there are no available buddies, hiring should pause, not push through.
+
+### Step 4: Build the early-win path
+
+Inversion: *"what makes this hire feel they made the wrong choice in week 2?"* — usually: no tools, no clarity, no peer, no early demonstrable win.
+
+1. Pre-day-1: laptop / accounts / access provisioned. Verified by the manager before day 1, not assumed.
+2. Day 1–5: orientation, codebase / domain tour, 1:1s with named peers, manager 1:1 scheduled out for 90 days.
+3. Week 2–4: first owned task — selected to be shippable, visible, low-risk, but real. Not a synthetic onboarding-only task; a real one.
+4. Week 4–6: first feedback checkpoint; explicit acknowledgement of one thing going well + one thing to adjust.
+
+The early-win path is the #1 driver of 12-month retention for new hires.
+
+### Step 5: Validate the program before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Ramp-definition concreteness** — confirm Step 0 named net-positive in concrete behavior; adjective-only definitions fail and must be re-run.
+2. **Decide-alone coverage** — assert Step 1's third bucket is non-empty; decide-alone gaps are the canonical ramp-slowing failure mode.
+3. **Mentor capacity check** — verify the buddy / mentor commitments fit within available mentor capacity for the cohort size; overbooked mentors collapse onboarding silently.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the onboarding program
+
+Produce the onboarding-program artifact for the role-family owner (engineering lead, sales lead, design lead) and people partner. The artifact frames the ramped definition, the Know/Do/Decide map, the 30/60/90 milestones, the triad assignments, and the early-win path.
+
+## Related Skills
+
+**WHEN to use this**
+
+- First-pass internal-employee onboarding program design.
+- Role-family-specific onboarding (first sales hire, first SRE, first designer).
+- Existing program audit when ramp times are inconsistent or long.
+
+**WHEN NOT to use this**
+
+- Customer onboarding — route to Wing-3 [`onboarding-design`](../onboarding-design/SKILL.md) (H11); different audience entirely.
+- Performance / feedback design — route to [`perf-feedback-craft`](../perf-feedback-craft/SKILL.md) (Q4); Q3 composes Q4 at milestone checkpoints, doesn't replace it.
+- Org structure decisions — route to [`org-design`](../org-design/SKILL.md) (Q1).
+- Compensation banding — route to [`comp-banding`](../comp-banding/SKILL.md) (Q2).
+
+## When the agent should load this
+
+- "Design our onboarding."
+- "Why are new hires ramping slow?"
+- "What does the first 90 days look like for a sales AE?"
+- "Set up a buddy program."
+- "Wie bauen wir das Onboarding für Engineering auf?"
+
+## Output
+
+1. **`ramp-definition.md`** — role-family × concrete ramped-definition × benchmark time-to-ramp.
+2. **`know-do-decide-map.md`** — three buckets with concrete artifacts and decide-alone boundary.
+3. **`milestones-30-60-90.md`** — milestone × objective check × feedback checkpoint.
+4. **`triad-assignment.md`** — manager / buddy / mentor mapping with capacity check.
+5. **`early-win-path.md`** — pre-day-1 through week-6 sequence with named first owned task pattern.
+
+## Gotcha
+
+- "Read these 40 docs" is a placebo onboarding. Force know-by-doing.
+- Buddy ≠ mentor. Overloading the buddy with growth conversations collapses the role.
+- Decide-alone boundaries unwritten = stalled ramps. The single biggest leverage point most programs miss.
+- Synthetic onboarding tasks teach less than real tasks selected for low risk. Resist the urge to manufacture training-only work.
+
+## Do NOT
+
+- Do NOT skip the ramped-definition step; un-defined ramp is unfalsifiable.
+- Do NOT assign onboarding to an already-overloaded buddy; the program looks great on paper and fails in week 3.
+- Do NOT confuse this with customer onboarding (H11); the two operate on different proof bars.
+
+## Runnable example
+
+Series-A SaaS hires its first dedicated SRE, no prior SRE onboarding shape.
+
+- Step 0 — Role family: senior SRE. Ramped means: on-call alone by week 12, owns one production reliability workstream by month 6, has shipped one runbook and one alert-quality improvement by month 3.
+- Step 1 — Know: prod architecture doc, incident-response runbooks, last 6 months of incidents. Do: shadow on-call weeks 1–2, secondary on-call weeks 3–6, primary on-call by week 12. Decide-alone: page severity, can declare incident, can deploy hotfix during business hours; cannot make architecture changes alone before month 4.
+- Step 2 — Milestones: 30-day Know complete + first runbook PR shipped; 60-day secondary on-call + alert-quality artifact produced; 90-day primary on-call + first standalone reliability initiative scoped.
+- Step 3 — Triad: manager = VP Eng (weekly 1:1); buddy = senior backend engineer (peer, week 1–12); mentor = none initially (no other SREs in-house; consider external mentor at month 6).
+- Step 4 — Early win: first runbook PR for a known-rough incident scenario; shippable in week 2, visible to whole eng team.
+- Step 5 — Validate: ramped definition concrete; decide-alone boundary explicit; buddy commitment is 2h/week which fits the backend engineer's current load. Pass.
+- Step 6 — Emit onboarding program for SRE role family; flag to revisit at month 6 once second SRE is hired (mentor capacity will exist then).