@event4u/agent-config 2.8.0 → 2.10.0

package/.agent-src/skills/data-handling-judgment/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: data-handling-judgment
+description: "Use when classifying data, setting retention, judging cross-border transfer, or shaping DSR workflow. Triggers on 'how long do we keep this', 'can this data go to the US'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [regulatory-regime, customer-segment, product]
+---
+
+# data-handling-judgment
+
+## When to use
+
+- A data category needs classification (PII / PHI / financial / public / pseudonymous / aggregate) and downstream retention, access, and transfer rules depend on the classification.
+- A retention default is being set (or audited) and the question is *how long is defensible*, *how long is useful*, *how long is dangerous*.
+- A cross-border transfer is proposed (analytics in US, support in Philippines, backup in EU) and the transfer-mechanism + sub-processor obligations need a read.
+- A data-subject-rights (DSR) workflow is being designed: access, deletion, portability, correction, objection, automated-decision-objection.
+
+Do NOT use as a regulatory-regime delta read (route to `privacy-review` (P6); this skill composes P6 for the regime floor), for contract-clause depth (route to `contracts-cognition` (P5)), or for data-loss-prevention tool administration / classifier-engine configuration.
+
+## Cognition cluster
+
+- **Mental model 28 — Inversion.** *"If this data category leaked in this form, who would we have to notify and what would the headline read?"* The headline inversion forces honest classification ahead of operational convenience. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 28.
+- **Mental model 1 — First principles.** Strip every retention claim to: *what purpose does keeping this another day serve, and whose risk does it grow?* Most retention defaults are inherited from the previous system, not chosen. See `mental-models.md` § 1.
+- **Mental model 26 — Optionality.** Aggressive retention preserves *analytical optionality* but forecloses *deletion optionality* and grows *breach optionality* for the attacker. Each retention choice is a trade. See `mental-models.md` § 26.
+- **Context-spine — regulatory-regime + customer-segment + product.** Read **regulatory-regime** (J1) for floor (GDPR storage-limitation principle; HIPAA retention minimums for medical records; financial-regulator retention mandates). Read **customer-segment** for whose data sets the floor. Read **product** for which features actually need the data.
+
+## Cross-wing handoff
+
+- Composes / cites J1 `regulatory-regime` for the floor read; this skill operationalises the regime obligations into classification / retention / transfer / DSR shape.
+- Composed by P6 `privacy-review` — privacy-review flags *that* a classification / retention / transfer issue exists, this skill produces the *operational answer*.
+- Hands off to Wing-2 ops skills for implementation (retention-job scheduling, DSR-runbook authoring) — this skill produces the policy shape, ops implements.
+
+## Procedure
+
+### Step 0: Bind the regime floor and the segment
+
+Read J1 `regulatory-regime` for the customer-segment in scope. Note which regime mandates a *minimum* retention (HIPAA medical records: typically 6+ years state-dependent; financial: SOX, regulatory varies) vs which mandates a *maximum* (GDPR storage-limitation; CCPA "necessary purpose"). Both floors and ceilings can apply simultaneously and create a window.
+
+### Step 1: Classify the data category
+
+For each data category in scope, assign a classification tier and rationale:
+
+1. **Public** — already public or designed for publication; no confidentiality obligation.
+2. **Internal** — company-confidential, not subject-specific; protected by trade-secret / commercial logic.
+3. **Pseudonymous** — keyed to subject but not directly identifying; classification depends on re-identifiability (the GDPR test).
+4. **PII** — directly identifying; subject to regime baseline.
+5. **Sensitive-PII** — special-category (GDPR Art. 9), CCPA "sensitive personal information", financial-account, gov-ID.
+6. **PHI / regulated** — HIPAA PHI, payment-card data (PCI), or sector-specific (children = COPPA, biometrics = state laws).
+
+Rationale per category cites *what makes it that tier*, not just the label. Mis-classification downward is the canonical risk.
+
+### Step 2: Set retention with explicit purpose binding
+
+For each data category × processing purpose, name:
+
+1. **Purpose** — why we keep it (operational, analytical, legal-hold, contractual, regulatory-mandate).
+2. **Retention** — how long for that purpose; named in calendar units, not "as needed".
+3. **End-state** — at expiry: hard-delete, anonymise, aggregate-only, archive-with-access-restriction.
+4. **Authority** — what makes the chosen retention defensible (regime mandate, contract obligation, documented operational need).
+
+Default "indefinite" retention is the failure mode. Every category needs an explicit end-state.
+
+### Step 3: Cross-border-transfer judgment
+
+For each transfer hop where data crosses a regime boundary:
+
+1. **Source regime** vs **destination regime** — which subjects, which categories.
+2. **Mechanism** — adequacy decision, SCC (with which version), BCR, derogation. Schrems-II-level transfer-impact assessment for transfers to non-adequate jurisdictions.
+3. **Government-access risk** — destination jurisdiction's surveillance regime and the supplementary-measures shape (encryption with key-control, pseudonymisation before transfer, contractual challenge).
+4. **Sub-processor chain** — every onward transfer is itself a transfer; map two hops deep, not one.
+
+A transfer without a named mechanism + supplementary measures (where required) = an unauthorised transfer.
+
+### Step 4: Data-subject-rights workflow shape
+
+For each regime × right (access, deletion, portability, correction, objection, automated-decision-objection), name:
+
+1. **Window** — regime-mandated response time (GDPR: 1 month; CCPA: 45 days; HIPAA: 30 days for access).
+2. **Owner** — named human / role responsible (not "the team").
+3. **Mechanism** — how the subject submits, how identity is verified, how the response is delivered, how denials are reasoned.
+4. **Edge cases** — joint-controller scenarios, third-party data within a subject's record, deletion-vs-legal-hold conflicts.
+
+DSR workflows that exist only as a generic support-inbox process fail under every regime. Force named owners and windows.
+
+### Step 5: Validate the data-handling read before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Classification coverage** — confirm every in-scope data category has a tier + cited rationale; un-rationalised tiers are guesses and must be re-run.
+2. **Retention binding** — assert every category × purpose has a calendar-unit retention + named end-state + cited authority; "as needed" entries fail.
+3. **Transfer + DSR completeness** — check every cross-border hop has a mechanism + supplementary-measures read; every applicable regime × right has a named owner + window. Gaps are surfaced, not smoothed.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the data-handling-judgment artifact
+
+Produce the data-handling-judgment note for the feature owner, ops lead, and counsel. The artifact operationalises the regime floor into policy that ops can implement and counsel can sign off.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Classifying a new data category and setting downstream rules.
+- Setting / auditing retention defaults against regime and purpose.
+- Judging a cross-border-transfer mechanism + supplementary measures.
+- Designing a DSR workflow with named owners and windows.
+
+**WHEN NOT to use this**
+
+- Regime-floor regulatory delta read — route to [`privacy-review`](../privacy-review/SKILL.md) (P6); this skill composes P6.
+- Contract-clause redline depth — route to [`contracts-cognition`](../contracts-cognition/SKILL.md) (P5).
+- Regime-floor surface — route to `regulatory-regime` (J1); this skill operationalises J1, doesn't replace it.
+- DLP / classifier-engine tooling — out of scope.
+
+## When the agent should load this
+
+- "How do we classify this field?"
+- "How long do we keep this?"
+- "Can we send this to the US / India / wherever?"
+- "Design our DSR workflow."
+- "Wie lange dürfen wir Logs aufbewahren?"
+
+## Output
+
+1. **`classification-map.md`** — every in-scope data category × tier + cited rationale.
+2. **`retention-policy.md`** — category × purpose × retention × end-state × authority.
+3. **`transfer-register.md`** — cross-border hops × mechanism × supplementary measures × sub-processor chain (two-deep).
+4. **`dsr-workflow.md`** — regime × right × window × owner × mechanism × edge cases.
+
+## Gotcha
+
+- Pseudonymous ≠ anonymous. If re-identification is possible with reasonable means, it's still personal data under GDPR.
+- Retention defaults inherited from the previous system are usually wrong; treat every category as a fresh decision.
+- "Encryption in transit" is not a Schrems-II supplementary measure on its own; the question is who can access the keys in the destination jurisdiction.
+- Joint-controllership is silently common (analytics, embedded widgets); name the controller relationship explicitly per hop.
+
+## Do NOT
+
+- Do NOT issue privacy legal opinions; this skill produces operational policy, counsel signs it off.
+- Do NOT classify by least-conservative tier to avoid operational burden; mis-classification downward is the canonical regulator finding.
+- Do NOT set retention without a named end-state; "as needed" is not a retention.
+
+## Runnable example
+
+Series-B SaaS with EU + US customer mix, adding a customer-success analytics integration.
+
+- Step 0 — Regime floor: GDPR (EU subjects), CCPA (CA subset), no PHI. GDPR storage-limitation is the ceiling; no minimum-retention mandate applies.
+- Step 1 — Classify: account-id = pseudonymous (low re-id); email = PII; usage-event = PII (linked to email); free-text-feedback = PII + potentially sensitive (subjects may include health / political content). Aggregate cohort metrics = anonymous if k-anonymity ≥ 50.
+- Step 2 — Retention: usage-event for product-analytics = 18 months, hard-delete on expiry; usage-event for billing-dispute = 7 years (contractual + tax authority); free-text-feedback = 12 months, hard-delete; email-for-marketing = until consent withdrawn or 24 months inactive.
+- Step 3 — Transfer: analytics vendor in US (no adequacy), SCC 2021 module 2 + supplementary measures (pseudonymisation of free-text-feedback before transfer, key-control retained in EU). Sub-processor chain: vendor uses logging service in US-only; ok within SCC.
+- Step 4 — DSR: access (1 month, CS lead, in-app + verified-email submission); deletion (1 month, CS lead, soft-delete-then-hard-delete-30d unless legal-hold); portability (1 month, ops engineer, JSON export); objection-to-marketing (immediate, automated).
+- Step 5 — Validate: every category tier rationalised; every retention category × purpose has end-state + authority; transfer hops have SCC + supplementary measures; DSR rights have owners + windows. Pass.
+- Step 6 — Emit data-handling-judgment artifact; ops implements retention jobs and DSR runbook; counsel signs off on transfer-impact assessment.

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.