@event4u/agent-config 2.7.0 → 2.9.0

package/.agent-src/skills/one-on-one-cadence/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: one-on-one-cadence
+description: "Use when designing engineering 1:1s — cadence, agenda mix, growth-vs-blocker-vs-trust shape, cancellation anti-patterns. Triggers on 'fix my 1:1s', 'should I cancel 1:1s this week'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, product, customer-segment]
+---
+
+# one-on-one-cadence
+
+## When to use
+
+- An engineering manager is setting up 1:1s with their team for the first time, or after a reorg / role change, and the question is *cadence, length, and agenda shape*.
+- 1:1s exist but are degrading — getting cancelled, devolving into status updates, becoming uncomfortable — and the question is *what's broken and how to repair*.
+- A team is scaling and 1:1 capacity is starting to bind (skip-levels, growing reports) and the question is *what to keep, what to delegate, what to drop*.
+
+Do NOT use this for non-engineering teams as the primary lens (Q4 `perf-feedback-craft` is the generalist surface; this skill specializes for the engineering context per the EM persona), as a comp-decision channel (route to Q2 `comp-banding`), or for 1:1-tooling-platform configuration.
+
+## Cognition cluster
+
+- **Mental model 1 — First principles.** Strip the 1:1 to: *what conversation can only happen between this manager and this report, that wouldn't happen anywhere else?* If the answer is "status that fits in standup", the 1:1 is mis-shaped. See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 1.
+- **Mental model 21 — Second-order thinking.** A cancelled 1:1 signals more than a missed conversation. Two consecutive cancellations from the manager side recalibrate the report's read of priority for months. Cancellation has compounding cost; protect the slot.
+- **Mental model 28 — Inversion.** *"What 1:1 shape would make this report stop bringing up real problems?"* — usually: pure status-update format, manager-talks-most, no growth dimension, recurring cancellation, public location. Inversion surfaces the 5 canonical failure modes.
+- **Mental model — Theory of constraints.** In a manager's week, 1:1 time is the binding constraint on people-leverage. Reducing per-1:1 time below 30 minutes for direct reports usually starves the channel; protecting 30–45 minutes weekly is the canonical default.
+- **Context-spine — org-stage + product + customer-segment.** Read **org-stage** for what 1:1 infrastructure exists (10-person co: 1:1 is core; 50-person: standard; 150+: skip-levels matter). Read **product** for what topics surface (deep-tech = more growth; high-velocity = more blocker). Read **customer-segment** for stakeholder-load shape (enterprise = stakeholder management surfaces in 1:1s).
+
+## Cross-wing handoff
+
+- Specializes Q4 `perf-feedback-craft` for engineering-team context — Q4 is the generalist cognition, S1 is the eng-context channel.
+- Composes Q3 `onboarding-program` at the 30 / 60 / 90 day milestones for new eng hires.
+- Hands off to Q2 `comp-banding` when scope-growth conversations surface in 1:1s and need a comp-cycle decision.
+- Owned by T4 `engineering-manager` persona; cited by T3 `people-strategist`.
+
+## Procedure
+
+### Step 0: Diagnose 1:1 intent per report
+
+Before locking cadence, name the dominant mode for each report:
+
+1. **New hire (first 90 days)** — orientation, decide-alone boundaries, early-win pathway. Weekly, 30–45 min, manager-prep heavier early.
+2. **Tenured IC, steady-state** — growth, blockers, trust-banking. Weekly or biweekly, 30 min, report-prep dominates.
+3. **Tenured IC, high-stakes / scope growth** — growth conversations, scope-shaping. Weekly, 45 min, growth dimension explicit.
+4. **Senior IC / staff** — strategy alignment, peer-org navigation, multipliers conversations. Weekly or biweekly, 45 min, manager listens more than directs.
+5. **Manager-of-managers report** — leadership patterns, team health, cross-org issues. Weekly, 45–60 min, more system-shaped than person-shaped.
+
+Same cadence for every report = mis-shaped channel. Different modes need different shapes.
+
+### Step 1: Set cadence and length
+
+Defaults by report type:
+
+1. **Weekly 30 min** — most ICs, steady state.
+2. **Weekly 45 min** — new hires, scope-growth ICs, senior IC, manager-reports.
+3. **Biweekly 45 min** — tenured ICs with stable scope; valid only when the report explicitly prefers it and the manager has high context.
+4. **Monthly 60 min** — skip-levels (one-level-down reports).
+
+Going below weekly without explicit report buy-in usually starves the channel. Going above weekly usually inflates manager load without proportional return.
+
+### Step 2: Shape the agenda mix
+
+Four canonical 1:1 dimensions; the mix shifts per report and per quarter:
+
+1. **Blocker** — what's in the way this week. Useful but should not dominate — pure blocker focus reduces to status update.
+2. **Growth** — what's the next rung; what scope / skill is being built. The most-skipped dimension; biggest leverage point.
+3. **Trust / relationship** — informal check-in, signal that the manager sees the human. Skipping for too long correlates with surprise departures.
+4. **Feedback (composes Q4)** — both directions; the 1:1 is the canonical feedback channel.
+
+Target mix for tenured IC: 30% blocker, 30% growth, 20% trust, 20% feedback. Heavy skew to blocker = mis-shaped.
+
+### Step 3: Set the agenda ownership rule
+
+Pick one explicit shape:
+
+1. **Report-owns** *(default for tenured IC)* — report sets the agenda in a shared doc before the 1:1; manager adds items but does not dominate.
+2. **Manager-prep heavier** *(default for new hires, first 90 days)* — manager prepares orientation prompts, decide-alone exploration, early-win check-in.
+3. **Alternating** — odd weeks report-owns, even weeks manager-prep; rare, only when the manager has a specific reason.
+
+Manager-dominated agenda for tenured ICs is a canonical anti-pattern; it converts the 1:1 from peer-shape to status-meeting.
+
+### Step 4: Cancellation policy
+
+Three rules:
+
+1. **Two-cancel rule** — two consecutive cancellations on the manager side triggers an explicit conversation about whether the cadence or relationship needs reshaping. Cancellation is the loudest signal in the 1:1 channel.
+2. **Replace, not skip** — if a slot truly can't happen, replace within the week, not skip entirely. Skip = signal that 1:1 isn't real.
+3. **Report-side cancel** — different signal; usually means topic is exhausted or there's a relationship issue. Worth a check-in conversation if it happens twice consecutively.
+
+A 1:1 cadence with regular cancellation is theatre.
+
+### Step 5: Validate the 1:1 design before rolling out
+
+Before formalising the cadence, inspect three things:
+
+1. **Per-report shape diagnosis** — confirm Step 0 named the mode per report; one-shape-for-all reports fails the check and must be re-run.
+2. **Growth dimension present** — assert Step 2's target mix has growth ≥ 20% for tenured ICs; growth-starved 1:1s are the canonical mis-shape and must be re-balanced before rolling out.
+3. **Capacity check** — verify total 1:1 hours fit the manager's week with focus-time and meeting-load room; a cadence that doesn't fit capacity collapses within 6 weeks.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the 1:1 cadence design
+
+Produce the cadence artifact for the manager: per-report cadence + length + agenda-ownership + dimension mix. For diagnostic use, also produce a cancellation log review and the gap-vs-target read.
+
+## Related Skills
+
+**WHEN to use this**
+
+- New EM setting up 1:1s for their team.
+- Existing 1:1s degrading (cancellations, status-creep, growth-starved).
+- Scaling EM with skip-levels emerging.
+- Post-reorg 1:1 re-design.
+
+**WHEN NOT to use this**
+
+- Non-engineering teams as primary lens — route to [`perf-feedback-craft`](../perf-feedback-craft/SKILL.md) (Q4) which is the generalist surface.
+- Comp decisions surfacing in 1:1s — route to [`comp-banding`](../comp-banding/SKILL.md) (Q2).
+- Hiring-loop / calibration — route to [`hiring-loop-design`](../hiring-loop-design/SKILL.md) (S2).
+- Team-velocity / throughput-vs-burnout conversations — route to [`throughput-vs-morale-tradeoff`](../throughput-vs-morale-tradeoff/SKILL.md) (S3).
+
+## When the agent should load this
+
+- "Fix my 1:1s."
+- "Should I cancel 1:1s this week?"
+- "How long / how often for senior eng 1:1s?"
+- "My 1:1s have become status updates."
+- "Wie strukturiere ich meine 1:1s?"
+
+## Output
+
+1. **`per-report-mode.md`** — diagnosed 1:1 mode per direct report (new hire / tenured / scope-growth / senior IC / mgr-of-mgrs).
+2. **`cadence-and-length.md`** — weekly vs biweekly × 30 vs 45 vs 60 min per report.
+3. **`agenda-mix.md`** — blocker / growth / trust / feedback target mix × ownership rule.
+4. **`cancellation-policy.md`** — two-cancel rule + replace-not-skip + report-side signal handling.
+5. **`capacity-check.md`** *(manager-side)* — total 1:1 hours / week vs focus-time and meeting-load remaining.
+
+## Gotcha
+
+- "Skip this week, busy" is the most damaging 1:1 sentence in the manager's vocabulary. Replace, don't skip.
+- Pure blocker focus is the canonical degradation; growth gets starved silently for months.
+- Same cadence and agenda for every report = mis-shaped channel. Different reports need different shapes.
+- Skip-levels are not optional past ~15 reports; they are the only way to keep skip-level signal flowing without overloading direct managers.
+
+## Do NOT
+
+- Do NOT default every report to the same shape; one-size-fits-all 1:1s collapse the growth dimension.
+- Do NOT cancel two consecutive 1:1s without an explicit conversation; the report's read of priority recalibrates in ways that are hard to repair.
+- Do NOT confuse this with feedback-craft (Q4); Q4 is what's said, S1 is when and how often.
+
+## Runnable example
+
+Mid-stage EM, 6 direct reports (2 new hires in months 1–2, 3 tenured ICs, 1 senior staff eng), 1:1s have devolved into status updates.
+
+- Step 0 — Per-report diagnosis: 2 new hires = onboarding mode; 2 tenured = steady-state; 1 tenured = scope-growth mode (taking on first lead role); 1 senior staff = strategy alignment mode.
+- Step 1 — Cadence: weekly 45 min for new hires + scope-growth IC + senior staff; weekly 30 min for steady-state ICs. Total: 4 × 45 + 2 × 30 = 4 hours / week (within capacity).
+- Step 2 — Mix re-design: current is 80% blocker. Target for steady-state ICs = 30/30/20/20. New hires = 50% onboarding-specific (decide-alone + early-win), 30% growth, 20% trust. Senior staff = 40% strategy, 40% growth, 20% trust.
+- Step 3 — Ownership: report-owns for all 4 tenured; manager-prep heavier for the 2 new hires.
+- Step 4 — Cancellation policy locked: two-cancel rule + replace-not-skip; explicit prior pattern (3 cancels in last quarter on the steady-state ICs' slots) acknowledged in the next 1:1.
+- Step 5 — Validate: per-report shape diagnosed; growth dimension restored to ≥ 20% (was ~0); capacity fits in 4 hrs / week with room for skip-levels at monthly cadence. Pass.
+- Step 6 — Emit cadence redesign + share with reports + name the change ("we've been status-heavy; here's what I'd like to shift") in next 1:1 round.

package/.agent-src/skills/org-design/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: org-design
+description: "Use when shaping team structure — functional vs squad, span-of-control, reorg cost, Conway-aware boundaries. Triggers on 'should we reorg', 'how do we split this team'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, product, customer-segment]
+---
+
+# org-design
+
+## When to use
+
+- Team shape is becoming a bottleneck — handoffs are slow, decisions stall, the same conversations repeat across teams — and the question is *what structure unblocks*.
+- A reorg is being proposed (often for a different stated reason) and the question is *what does this actually buy* and *what does it cost*.
+- A new product line, segment, or geography is being added and the question is *fold it into existing teams* vs *spin a new team* vs *embed people across teams*.
+
+Do NOT use as a hiring-plan substitute (route to forthcoming hiring-loop / comp skills for headcount and band shape), as a performance / individual-feedback surface (route to Q4 `perf-feedback-craft`), or for org-chart software / HRIS configuration.
+
+## Cognition cluster
+
+- **Mental model — Theory of constraints.** Org bottlenecks live in one or two places at a time; reorging everywhere else is theatre. Find the constraint (decision queue, dependency hub, single-threaded role), reshape around it, leave the rest. See [`mental-models.md`](../../../docs/contracts/mental-models.md).
+- **Mental model — Conway's law.** Systems mirror the communication structure that shipped them. If two services must integrate cleanly, the two teams must communicate cleanly. Org boundary = future architecture boundary. Use the inverse: pick the architecture you want, then draw the org to match.
+- **Mental model 28 — Inversion.** *"What problem does the proposed structure prevent us from solving?"* Every structure trades one class of problem for another. The honest question is which trade is acceptable, not which structure is best.
+- **Mental model 26 — Optionality.** Reorgs cost 3–6 months of throughput; the reorg is worth it only if the new shape preserves more optionality than the old shape forecloses. Reorging for short-term symptoms usually destroys optionality.
+- **Context-spine — org-stage + product + customer-segment.** Read **org-stage** for which problems are real (10-person co: structure barely matters; 50-person co: functional silos start; 150-person co: span-of-control breaks; 500+: Conway dominates). Read **product** for natural boundaries (modular product = squads work; tightly-coupled product = functional teams work better). Read **customer-segment** for whether segment-aligned teams pay off.
+
+## Cross-wing handoff
+
+- Composes P1 `build-buy-partner` for the insource-vs-outsource shape that affects whether a capability needs a team at all.
+- Hands off to Q2 `comp-banding` for the level / band design that the new shape implies.
+- Hands off to Q3 `onboarding-program` for the time-to-productivity shape that the new structure requires.
+- Hands off to S-block EM skills for the team-level mechanics within the chosen structure.
+
+## Procedure
+
+### Step 0: Identify the real problem before redesigning anything
+
+Most "we need to reorg" requests are misdiagnosed. Run three checks first:
+
+1. *Is the symptom a structure problem, a leadership problem, or a strategy problem?* Reorgs solve only the first; the other two get worse with structural churn.
+2. *Has the bottleneck been named with file:line precision?* (which decision, which handoff, which dependency, which role). Un-named bottlenecks = no real constraint identified.
+3. *Has the smallest local fix been tried?* (move one role, redraw one boundary, add one decision-rights doc). A reorg is the heaviest tool; reach for it last.
+
+If checks 1–3 don't justify a structural change, route the request elsewhere and stop.
+
+### Step 1: Frame the structural options honestly
+
+Four canonical shapes; each has trade-offs:
+
+1. **Functional** — eng, design, PM, ops as separate orgs. Best for: deep specialisation, small co, shared platform. Cost: cross-functional handoff overhead.
+2. **Cross-functional squad** — eng + design + PM bundled per product area. Best for: product-led shipping cadence, autonomous outcomes. Cost: duplicated capability, harder craft-leveling.
+3. **Matrix** — functional reporting + squad allocation. Best for: balancing specialisation and outcome ownership. Cost: dual-reporting confusion, decision ambiguity.
+4. **Segment-aligned** — teams own a customer segment end-to-end. Best for: deeply different segments with different jobs. Cost: code / platform divergence.
+
+Hybrid shapes exist (squads inside functions; functional platforms under segment-aligned product teams); name them explicitly, don't hide them.
+
+### Step 2: Read Conway, both directions
+
+For the option in scope, draw the implied future architecture:
+
+1. *Which interfaces become team-boundary interfaces?* (these calcify as contracts).
+2. *Which integrations cross team boundaries?* (these slow down, gain meetings, accrete bureaucracy).
+3. *Is the implied architecture the architecture we want?* If yes, the structure is honest; if no, redraw.
+
+Inverse Conway: if the desired architecture has clean modules A, B, C, draw teams around A, B, C — not around skill specialisations that will fight the architecture.
+
+### Step 3: Span-of-control and decision-rights audit
+
+For each manager / lead in the proposed shape:
+
+1. **Span** — how many direct reports. >7 is high-cost coaching; <4 is over-managed. Target 5–7 for engineering; varies for ops / design.
+2. **Depth** — layers between IC and CEO. Above 4 layers in a sub-150 org = excess.
+3. **Decision rights** — what does this role own vs need approval for? Un-named decision rights = stalls.
+4. **Single-threaded role check** — is there exactly one owner per significant outcome? (Amazon's STO principle).
+
+Span and decision-rights gaps are usually the actual fix, not a wholesale restructure.
+
+### Step 4: Reorg cost sizing
+
+For any structural change, name:
+
+1. **Disruption window** — 3–6 months of degraded throughput is typical for non-trivial reorgs. Larger structural changes can take 9–12 months to settle.
+2. **Attrition risk** — every reorg loses 5–15 % of impacted ICs to voluntary attrition; senior people more than juniors.
+3. **Re-platforming cost** — if Conway implies architecture change, the eng cost of that change.
+4. **Customer-facing disruption** — relationship continuity for account-aligned segments.
+
+A reorg whose stated benefit is smaller than these costs = don't do it. Force the sizing before approving.
+
+### Step 5: Validate the org-design read before emitting
+
+Before producing the artifact, verify three things:
+
+1. **Real-problem confirmation** — confirm Step 0 named the bottleneck with precision; un-named bottlenecks mean the reorg is theatre and must be re-run or abandoned.
+2. **Trade-off honesty** — assert each proposed shape names what it foreclose s, not just what it enables; structures sold as pure upside fail the check.
+3. **Cost sizing present** — verify Step 4 disruption / attrition / re-platforming / customer costs are sized in calendar units and % terms; un-sized reorgs are unrealistic and must be re-run.
+
+All three must pass. If any fails, return to the failing step.
+
+### Step 6: Emit the org-design read
+
+Produce the org-design artifact for the leadership decision-maker. The artifact frames the bottleneck, the candidate shapes, the Conway implications, the span / decision-rights audit, and the sized cost. The decision stays human.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Reorg proposals (real or implied).
+- Adding a new product line, segment, or geo and choosing fold-vs-spin-vs-embed.
+- Span-of-control / decision-rights audits.
+
+**WHEN NOT to use this**
+
+- Hiring-plan / headcount shape — out of scope here; this skill answers *what shape*, hiring answers *how many of each*.
+- Performance / individual-feedback work — route to [`perf-feedback-craft`](../perf-feedback-craft/SKILL.md) (Q4).
+- Team-level engineering management — route to S-block EM skills.
+- Compensation banding — route to [`comp-banding`](../comp-banding/SKILL.md) (Q2).
+
+## When the agent should load this
+
+- "Should we reorg?"
+- "How do we split this team?"
+- "Functional vs squad?"
+- "Span-of-control read on engineering."
+- "Wie strukturieren wir das Team neu?"
+
+## Output
+
+1. **`bottleneck-diagnosis.md`** — named constraint, evidence, smallest-local-fix check.
+2. **`shape-options.md`** — candidate structures × what each enables × what each forecloses × Conway implications.
+3. **`span-and-decision-rights.md`** — manager span audit, decision-rights mapping, single-threaded-role check.
+4. **`reorg-cost-sizing.md`** — disruption window, attrition risk, re-platforming cost, customer-facing impact.
+
+## Gotcha
+
+- "We need a reorg" is usually a strategy or leadership problem in disguise. Diagnose first.
+- Conway's law cuts both ways — pick the architecture, draw the org. Don't pick the org and hope the architecture follows.
+- Matrix structures sound balanced and run terribly without explicit decision-rights docs.
+- Reorgs done in <6-month cycles destroy more value than they create; structural change is a multi-quarter commitment.
+
+## Do NOT
+
+- Do NOT propose a reorg as the first response to a velocity / quality complaint; smaller fixes usually exist.
+- Do NOT design a structure whose Conway-implied architecture you'd reject if drawn directly.
+- Do NOT skip the cost sizing; un-sized reorgs are wishful.
+
+## Runnable example
+
+100-person SaaS, eng leadership claims "we need to move to squads because shipping is slow".
+
+- Step 0 — Diagnose: shipping-slow is the symptom; bottleneck inspection shows two PMs serving 8 engineers each, decision queue at the PM layer, not the eng-design boundary. Smallest local fix: hire 2 PMs. Reorg not yet justified.
+- Step 1 — Frame anyway as sanity check: functional vs cross-functional squad vs matrix.
+- Step 2 — Conway read: current platform is modular by domain (billing / scheduling / reporting); squad-by-domain is Conway-aligned; squad-by-customer-segment would fight architecture.
+- Step 3 — Span audit: VP Eng spans 9 direct reports (too wide); 1 EM has 11 reports (too wide); decision rights for "ship a public-API change" undefined.
+- Step 4 — Reorg cost sizing: 4-month throughput drop, 8–12 % attrition risk on senior eng who joined for current shape, no re-platforming needed.
+- Step 5 — Validate: bottleneck was misdiagnosed at the start; trade-off honest (squads cost shared-platform leveling); cost sizing present. Pass.
+- Step 6 — Emit org-design read: recommend (a) hire 2 PMs to clear the actual bottleneck, (b) shrink VP Eng span by promoting an Eng Director, (c) write decision-rights doc for public-API changes, (d) revisit squad question in 6 months with fresh data. Net: smallest-fix path beats reorg by a wide margin.

package/.agent-src/skills/perf-feedback-craft/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: perf-feedback-craft
+description: "Use when shaping feedback — situation-behavior-impact, growth-vs-corrective split, cadence design, ladder-of-inference checks. Triggers on 'how do I give this feedback', 'perf review shape'."
+status: active
+tier: senior
+source: package
+domain: process
+context_spine: [org-stage, customer-segment, product]
+---
+
+# perf-feedback-craft
+
+## When to use
+
+- A specific feedback conversation is upcoming (1:1, 30 / 60 / 90 check, mid-cycle review, end-of-cycle review, corrective conversation) and the question is *what shape this conversation should take*.
+- A team-wide feedback cadence is being designed or audited and the question is *which signals get surfaced, when, and through what channel*.
+- A growth conversation is being confused with a corrective conversation (or vice versa) and someone needs to separate them before the next exchange.
+
+Do NOT use as a comp-decision surface (route to Q2 `comp-banding`; feedback informs comp, doesn't substitute for it), as a hiring-loop / calibration-design skill (route to S2 `hiring-loop-design`), or for performance-review-software configuration.
+
+## Cognition cluster
+
+- **Mental model 1 — First principles.** Strip feedback to: *what observation, about what behavior, with what impact, requesting what change?* Most feedback fails because it skips the observation (jumps to interpretation) or skips the impact (assumes it's obvious). See [`mental-models.md`](../../../docs/contracts/mental-models.md) § 1.
+- **Mental model — Ladder of inference.** Behavior observed → data selected → meaning inferred → assumptions made → conclusions drawn → beliefs adopted → action taken. Most feedback exchanges fail because giver and receiver are on different rungs. Naming the rung you're on (and inviting the other party to do the same) is the single highest-leverage feedback skill.
+- **Mental model 28 — Inversion.** *"What would make this feedback land as an attack instead of a gift?"* — usually: public delivery, surprise (no prior signal), interpretation-as-fact, no specific request, no listening turn. Inversion surfaces the four canonical mis-deliveries.
+- **Mental model 21 — Second-order thinking.** Feedback ripples. Praise in public, correction in private — the inverse damages both giver and receiver. A single mishandled feedback exchange damages trust for 6+ months; a single well-handled one banks trust that compounds.
+- **Context-spine slots.** Read **org-stage** for what feedback infrastructure exists (10-person: ad-hoc; 50-person: cadence emerging; 150+: documented system). Read **customer-segment** and **product** for what behavior matters (B2B-enterprise sales = stakeholder management; consumer = velocity; deep-domain = quality bar).
+
+## Cross-wing handoff
+
+- Composed by Q3 `onboarding-program` at 30 / 60 / 90 milestone checkpoints (first feedback exchanges are highest-impact).
+- Hands off to Q2 `comp-banding` for compensation decisions — feedback shapes the evidence base for promotion / raise / market-correction lever choice.
+- Hands off to S1 `one-on-one-cadence` for the channel and frequency in engineering teams (S1 specializes Q4 for the eng context).
+- Composed by T3 `people-strategist` and cited by T4 `engineering-manager`.
+
+## Procedure
+
+### Step 0: Diagnose the conversation type before designing the words
+
+Before shaping any feedback exchange, name which of three types it is:
+
+1. **Growth feedback** — about expanding capability, scope, judgment. Audience: people performing at or above expectation, with capacity for the next level. Goal: name where the next rung lives.
+2. **Corrective feedback** — about closing a gap between current and expected behavior. Audience: people below expectation on a named behavior. Goal: clarity on the gap + path to close + timeline.
+3. **Acknowledgement / reinforcement** — about naming what worked. Often confused with growth, but distinct: this banks trust and reinforces behavior; it doesn't ask for change.
+
+Mixing types in one exchange is the canonical mistake. A corrective conversation that opens with growth language confuses everyone; growth feedback dressed as correction harms trust. Pick one.
+
+### Step 1: Build the SBI (situation-behavior-impact) frame
+
+For the exchange in scope, write three sentences:
+
+1. **Situation** — when, where, what context. Concrete enough that the receiver can place themselves back in it. *"In the planning meeting yesterday"* not *"in meetings generally"*.
+2. **Behavior** — what was observed, in their actions / words. Stays on the observation rung of the ladder; does not infer intent. *"You interrupted three times before each engineer finished their estimate"* not *"You don't respect the team"*.
+3. **Impact** — what consequence it had, observed or felt. Tells the *why this matters* without lecturing. *"The estimates skewed low because two engineers stopped pushing back"* not *"You're going to lose your team"*.
+
+The SBI test: read it aloud. If the behavior sentence contains an adjective about the person, rewrite it. Adjectives belong nowhere in feedback.
+
+### Step 2: Inspect the rung — verify ladder-of-inference position before delivery
+
+Before delivering, inspect where you are on the ladder of inference:
+
+1. Are you on the **observation** rung (data) or the **conclusion** rung (interpretation)?
+2. If you're on a higher rung, can you climb back down to the data? If you can't, the feedback is unsupported and must not be delivered yet.
+3. Have you asked yourself *"what other interpretation of this behavior is plausible?"* If only one interpretation comes to mind, you haven't climbed down far enough.
+
+This inspection step is the single most-skipped step in feedback delivery. Delivering interpretation-as-fact is the canonical trust-damaging move.
+
+### Step 3: Design the delivery channel and timing
+
+For a specific exchange, name:
+
+1. **Channel** — 1:1 private (default for corrective and most growth); team-public (reserved for acknowledgement that doesn't single out underperformance contrast); written-async (rare, only for high-density observations the receiver needs time with).
+2. **Timing** — within 48 hours of the behavior for tactical feedback; within the milestone for thematic feedback; never at end-of-cycle for first-surface (the surprise principle).
+3. **Sequence in the meeting** — do not lead with feedback; check-in first, named topic second, listening turn after delivery (the receiver gets time to respond before next-step is set).
+
+Surprise is the largest avoidable failure mode. A piece of corrective feedback that the receiver is hearing for the first time at end-of-cycle is malpractice.
+
+### Step 4: Listening turn and request shape
+
+After delivery, build in two things:
+
+1. **Listening turn** — explicit pause. *"What's your read on this?"* Not rhetorical. Wait. The receiver may have a fact you don't (was on PTO, was covering for someone, miscommunication upstream). Their read changes whether the feedback even stands.
+2. **Specific request** — what would change look like. Concrete, observable, time-boxed. *"In the next three planning meetings, hold your estimate until each engineer has spoken first"* not *"be more respectful"*.
+
+Requests without observable shape are wishes, not feedback.
+
+### Step 5: Validate the feedback shape before delivery
+
+Before opening the conversation, verify three things:
+
+1. **SBI integrity** — confirm Step 1's behavior sentence contains zero adjectives about the person and stays on the observation rung; if not, return to Step 1.
+2. **Inference check** — assert Step 2's rung-climb produced at least one alternative interpretation; single-interpretation feedback fails the check and must be re-thought.
+3. **Channel + request fit** — verify the channel matches the type from Step 0 (corrective ≠ public) and the request from Step 4 is observable and time-boxed.
+
+All three must pass. If any fails, return to the failing step. This is the canonical pre-delivery inspect step.
+
+### Step 6: Emit the feedback exchange or cadence design
+
+For a single conversation, the artifact is the SBI script + listening prompts + request + follow-up checkpoint. For a team-wide cadence design, the artifact is the feedback channel map (1:1 weekly, 30/60/90 named, mid-cycle thematic, end-of-cycle synthesis) with explicit no-surprise guarantees.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Specific upcoming feedback conversation (growth, corrective, acknowledgement).
+- Team-wide feedback cadence design / audit.
+- A growth-vs-corrective confusion needing separation.
+- Mid-cycle re-anchoring conversations.
+
+**WHEN NOT to use this**
+
+- Compensation decisions — route to [`comp-banding`](../comp-banding/SKILL.md) (Q2); feedback informs, doesn't decide.
+- Hiring / calibration loops — route to [`hiring-loop-design`](../hiring-loop-design/SKILL.md) (S2).
+- Engineering-team 1:1 cadence specialization — route to [`one-on-one-cadence`](../one-on-one-cadence/SKILL.md) (S1); S1 specializes Q4 for engineering teams.
+- Org structure conversations — route to [`org-design`](../org-design/SKILL.md) (Q1).
+
+## When the agent should load this
+
+- "How do I give this feedback?"
+- "Perf review shape."
+- "Growth vs corrective — which is this?"
+- "Design our feedback cadence."
+- "Wie gebe ich dieses Feedback?"
+
+## Output
+
+1. **`conversation-type.md`** — diagnosed growth / corrective / acknowledgement classification with evidence.
+2. **`sbi-script.md`** — situation + behavior + impact sentences passing the observation-rung + zero-adjective bar.
+3. **`ladder-check.md`** — current rung named, alternative interpretation surfaced, climb-down verified.
+4. **`delivery-plan.md`** — channel + timing + meeting sequence + listening prompts + observable time-boxed request.
+5. **`cadence-map.md`** *(team-wide variant)* — feedback channels × frequency × no-surprise guarantee × milestone alignment.
+
+## Gotcha
+
+- Adjectives in behavior sentences ("disrespectful", "unfocused", "strong") are the #1 feedback failure mode. Force action / words.
+- End-of-cycle surprise = malpractice. If the receiver is hearing it for the first time at review, the feedback system is broken, not the receiver.
+- Growth and corrective in the same conversation confuse signal. Separate.
+- A feedback exchange without a listening turn is a verdict, not feedback.
+- Praise in private is fine; correction in public is damage. Default to private; flip only with explicit reason.
+
+## Do NOT
+
+- Do NOT deliver feedback that hasn't passed the rung-climb check; interpretation-as-fact is the canonical trust-damaging move.
+- Do NOT mix conversation types in one exchange; the cost compounds.
+- Do NOT skip the request-shape step; feedback without an observable request is a wish.
+
+## Runnable example
+
+EM needs to address a senior eng who has been dismissive in planning meetings; previously raised informally, no improvement.
+
+- Step 0 — Type: corrective (gap between observed and expected behavior, not growth-to-next-level). Acknowledgement of strengths happens separately in a different conversation, not bundled.
+- Step 1 — SBI: *Situation:* "In the last three planning meetings"; *Behavior:* "you interrupted junior engineers an average of 2x per meeting before they finished their estimate, and dismissed two estimates as 'not realistic' without follow-up question"; *Impact:* "two of those engineers reported in 1:1 they no longer push back on your scoping, and the team's estimates have skewed 15% lower since".
+- Step 2 — Ladder check: behavior is on the data rung (counted interruptions); alternative interpretation surfaced — could be the senior eng is anxious about ship date and not aware of the pattern; climb-down verified.
+- Step 3 — Channel: 1:1 private. Timing: within 48h of next planning meeting, not end-of-cycle. Sequence: check-in → named topic → SBI → listening turn → request → follow-up commitment.
+- Step 4 — Listening prompt: "What's your read on what's been happening in planning?" Request: "For the next three planning meetings, hold your estimate input until each engineer has spoken first; we'll review the pattern in our 1:1 in three weeks."
+- Step 5 — Validate: SBI is adjective-free; alternative interpretation surfaced; channel + request appropriate. Pass.
+- Step 6 — Emit feedback script + 3-week follow-up checkpoint scheduled.

package/.agent-src/skills/pipeline-strategy/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: pipeline-strategy
+description: "Use when designing or auditing a sales pipeline — stage exit criteria, per-cell conversion, coverage reasoning, leak detection. Triggers on 'tighten our pipeline', 'where is the leak'."
+status: active
+tier: senior
+source: package
+domain: product
+context_spine: [product, customer-segment, channel-stage]
+---
+
+# pipeline-strategy
+
+## When to use
+
+- Pipeline stages are named but have no exit criteria — reps move deals on gut and forecasts ride on opinion, not evidence.
+- Coverage is being computed from a flat multiple (*"3x quota"*) without per-stage conversion rates, so the multiple flatters or punishes the team at random.
+- A board ask names *"why did pipeline coverage look fine and the quarter still missed?"* — a leak is hiding inside a healthy-looking total.
+
+Do NOT use to qualify a single deal (route to
+`deal-qualification-meddic`), construct the forecast call from a
+locked pipeline (route to `forecast-accuracy`), or configure
+CRM stage fields in a specific vendor tool (out of scope — this
+skill is strategy, not tooling).
+
+## Cognition cluster
+
+- **Mental model 6 — Theory of constraints.** A pipeline has one
+  binding stage at any time; rates upstream of the constraint are
+  inventory that never ships, rates downstream cannot exceed the
+  constraint. Find the constraint before changing anything else. See
+  [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 6.
+- **Mental model 16 — Leading vs. lagging indicators.** Stage-to-stage
+  conversion is leading; closed-won is lagging. A coverage call built
+  on lagging signals can only confirm the miss after it lands. See
+  `mental-models.md` § 16.
+- **Mental model 3 — Pareto (80/20).** ~20 % of segment × stage cells
+  carry ~80 % of revenue risk. Coverage uniformly applied across cells
+  is theatre; coverage weighted by cell-level conversion is reasoning.
+  See `mental-models.md` § 3.
+- **Context-spine — product + customer-segment + channel-stage.**
+  Read the **product** slot for what is actually sellable this
+  quarter, the **customer-segment** slot for which segments belong in
+  pipeline (and which are pre-pipeline education), and the
+  **channel-stage** slot for where each segment enters. See
+  [`context-spine`](../../../docs/contracts/context-spine.md).
+
+## Procedure
+
+### Step 0: Inspect — inventory the current pipeline shape
+
+Pull stage counts, $ value, age in stage, and stage-to-stage
+conversion for the trailing two quarters. Inspect whether each
+stage has a written exit criterion; if not, write one now (one
+bullet per stage, falsifiable). A pipeline without exit criteria
+cannot be audited.
+
+### Step 1: Lock stage definitions with exit criteria
+
+Each stage gets three lines:
+
+1. **Definition** — what the deal looks like in this stage (one sentence).
+2. **Entry trigger** — the buyer event that moves a deal in (not a rep action).
+3. **Exit criterion** — the artefact or signal that proves the deal earned the next stage (one bullet, falsifiable; *"meeting booked"* is not falsifiable, *"economic buyer named and confirmed"* is).
+
+Reject any stage whose exit criterion is a rep activity ("call
+made") rather than a buyer signal ("buyer confirmed budget owner").
+
+### Step 2: Compute per-stage conversion rates with bands
+
+For each stage transition, compute the trailing-quarter rate and a
+95 % confidence band. Segment by customer-segment (and channel-stage
+if the channel mix changed). Report the band, not the point — a
+30 % rate on 12 deals and a 30 % rate on 300 deals are different
+signals.
+
+### Step 3: Find the binding constraint
+
+The constraint is the stage whose conversion rate is **furthest
+below its segment-historical median, weighted by $ value flowing
+through it**. Add deals upstream of any other stage and watch them
+queue; add deals upstream of the constraint and they queue twice as
+fast. A pipeline-coverage call that ignores the constraint
+multiplies inventory the team cannot ship.
+
+### Step 4: Compute coverage cell by cell, not by total
+
+Coverage = (pipeline $ at stage *s*) ÷ (target closed-won $ in
+window) ÷ (cumulative conversion from *s* to closed-won). Compute
+per segment × stage cell. A 3× total can hide a 0.8× cell — the
+0.8× cell is the quarter's risk.
+
+### Step 5: Name three leaks with falsifiable hypotheses
+
+For the three lowest coverage cells (or the three steepest
+conversion-rate drops vs trailing-quarter median), write one
+sentence per leak: *"\<cell\> leaks at \<stage\> because \<cause\>;
+falsified if \<test\> shows \<expected signal\>."* If a cause is
+not testable in under two weeks, the hypothesis is not yet sharp
+enough — sharpen before recommending a fix.
+
+### Step 6: Hand back
+
+Hand the locked stages, the per-cell coverage table, and the three
+leak hypotheses to
+[`forecast-accuracy`](../forecast-accuracy/SKILL.md) for
+commit / best-case categorisation, and to
+[`deal-qualification-meddic`](../deal-qualification-meddic/SKILL.md)
+when the leak is upstream qualification, not late-stage execution.
+
+## Related Skills
+
+**WHEN to use this**
+
+- Designing or auditing pipeline stages and per-stage rates.
+- Computing coverage by segment × stage instead of by total.
+
+**WHEN NOT to use this**
+
+- Single-deal qualification — route to
+  [`deal-qualification-meddic`](../deal-qualification-meddic/SKILL.md).
+- Forecast call construction from a locked pipeline — route to
+  [`forecast-accuracy`](../forecast-accuracy/SKILL.md).
+- Product-led conversion-funnel diagnosis (signup → activation → paid) — route to
+  [`funnel-analysis`](../funnel-analysis/SKILL.md).
+
+## When the agent should load this
+
+- "Tighten our pipeline stages — exit criteria are vibes."
+- "Coverage looks 3× and we still missed. Where is the leak?"
+- "Audit per-stage conversion by segment."
+- "Welche Stage ist das Bottleneck im Quartal?"
+
+## Output
+
+1. **`stage-definitions.md`** — one block per stage: definition · entry trigger · exit criterion (buyer signal, falsifiable).
+2. **`coverage-by-cell.md`** — table of segment × stage cells with $ pipeline, cumulative conversion, and computed coverage. Cells under 1× flagged.
+3. **`leak-hypotheses.md`** — three leaks with falsifiable test + expected signal + 2-week deadline.
+
+## Gotcha
+
+- A pipeline with exit criteria written as rep activities (*"call made"*) is unauditable — reps move deals on activity, not on buyer signal, and forecasts inherit the noise.
+- Total-pipeline coverage is the wrong unit. A 3× total made of 5× early-stage and 0.5× late-stage will miss the quarter even though the dashboard looks healthy.
+- Per-stage conversion rates without confidence bands are gossip dressed as evidence. Twelve deals give you a band so wide the rate is uninformative.
+
+## Do NOT
+
+- Do NOT invent stages to flatter the dashboard. Each stage must have a buyer signal earning the transition.
+- Do NOT compare the quarter's coverage to a fixed historical multiple if segment mix changed — recompute per cell.
+- Do NOT recommend a fix to a leak before naming the falsifiable test that proves the cause.
+
+## Runnable example
+
+Mid-market SaaS, total coverage 3.1×, quarter missed by 18 %.
+
+- Stages with exit criteria — *Discovery → Qualified (economic buyer named) → Proposal (pricing in writing) → Negotiation (terms in redline) → Won.*
+- Per-cell coverage — Mid-Market × Proposal: **0.7×**. Mid-Market × Discovery: **6.4×**. Enterprise × Negotiation: **2.1×**.
+- Constraint — Proposal → Negotiation conversion 22 % vs 41 % trailing-quarter median (band 14–31 %). Constraint is **Proposal exit**, not pipeline volume.
+- Leaks — *(1)* Mid-Market proposals stall at pricing-page review; falsified if a pre-proposal pricing-walkthrough call lifts Proposal → Negotiation to 35 %+ within four weeks. *(2)* Enterprise Negotiation drags > 60 days; falsified if procurement-checklist shipped at Proposal stage cuts median age by 20 days. *(3)* Discovery overflow is unqualified — route to `deal-qualification-meddic`.
+- Hand-off — coverage table + leaks → `forecast-accuracy` for commit / best-case rebuild on the corrected denominator.