@event4u/agent-config 2.8.0 → 2.10.0

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).

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.