@diottodev/runic 1.0.0 → 1.1.0

package/c-level/strategic-alignment/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: "strategic-alignment"
+description: "Cascades strategy from boardroom to individual contributor. Detects and fixes misalignment between company goals and team execution. Covers strategy articulation, cascade mapping, orphan goal detection, silo identification, communication gap analysis, and realignment protocols. Use when teams are pulling in different directions, OKRs don't connect, departments optimize locally at company expense, or when user mentions alignment, strategy cascade, silo, conflicting OKRs, or strategy communication."
+license: MIT
+metadata:
+  version: 1.0.0
+  author: Alireza Rezvani
+  category: c-level
+  domain: strategic-alignment
+  updated: 2026-03-05
+  python-tools: alignment_checker.py
+  frameworks: alignment-playbook
+---
+
+# Strategic Alignment Engine
+
+Strategy fails at the cascade, not the boardroom. This skill detects misalignment before it becomes dysfunction and builds systems that keep strategy connected from CEO to individual contributor.
+
+## Keywords
+strategic alignment, strategy cascade, OKR alignment, orphan OKRs, conflicting goals, silos, communication gap, department alignment, alignment checker, strategy articulation, cross-functional, goal cascade, misalignment, alignment score
+
+## Quick Start
+
+```bash
+python scripts/alignment_checker.py    # Check OKR alignment: orphans, conflicts, coverage gaps
+```
+
+## Core Framework
+
+The alignment problem: **The further a goal gets from the strategy that created it, the less likely it reflects the original intent.** This is the organizational telephone game. It happens at every stage. The question is how bad it is and how to fix it.
+
+### Step 1: Strategy Articulation Test
+
+Before checking cascade, check the source. Ask five people from five different teams:
+**"What is the company's most important strategic priority right now?"**
+
+**Scoring:**
+- All five give the same answer: ✅ Articulation is clear
+- 3–4 give similar answers: 🟡 Loose alignment — clarify and communicate
+- < 3 agree: 🔴 Strategy isn't clear enough to cascade. Fix this before fixing cascade.
+
+**Format test:** The strategy should be statable in one sentence. If leadership needs a paragraph, teams won't internalize it.
+- ❌ "We focus on product-led growth while maintaining enterprise relationships and expanding our international presence and investing in platform capabilities"
+- ✅ "Win the mid-market healthcare segment in DACH before Series B"
+
+### Step 2: Cascade Mapping
+
+Map the flow from company strategy → each level of the organization.
+
+```
+Company level:  OKR-1, OKR-2, OKR-3
+    ↓
+Dept level:     Sales OKRs, Eng OKRs, Product OKRs, CS OKRs
+    ↓
+Team level:     Team A OKRs, Team B OKRs...
+    ↓
+Individual:     Personal goals / rocks
+```
+
+**For each goal at every level, ask:**
+- Which company-level goal does this support?
+- If this goal is 100% achieved, how much does it move the company goal?
+- Is the connection direct or theoretical?
+
+### Step 3: Alignment Detection
+
+Three failure patterns:
+
+**Orphan goals:** Team or individual goals that don't connect to any company goal.
+- Symptom: "We've been working on this for a quarter and nobody above us seems to care"
+- Root cause: Goals set bottom-up or from last quarter's priorities without reconciling to current company OKRs
+- Fix: Connect or cut. Every goal needs a parent.
+
+**Conflicting goals:** Two teams' goals, when both succeed, create a worse outcome.
+- Classic example: Sales commits to volume contracts (revenue), CS is measured on satisfaction scores. Sales closes bad-fit customers; CS scores tank.
+- Fix: Cross-functional OKR review before quarter begins. Shared metrics where teams interact.
+
+**Coverage gaps:** Company has 3 OKRs. 5 teams support OKR-1, 2 support OKR-2, 0 support OKR-3.
+- Symptom: Company OKR-3 consistently misses; nobody owns it
+- Fix: Explicit ownership assignment. If no team owns a company OKR, it won't happen.
+
+See `scripts/alignment_checker.py` for automated detection against your JSON-formatted OKRs.
+
+### Step 4: Silo Identification
+
+Silos exist when teams optimize for local metrics at the expense of company metrics.
+
+**Silo signals:**
+- A department consistently hits their goals while the company misses
+- Teams don't know what other teams are working on
+- "That's not our problem" is a common phrase
+- Escalations only flow up; coordination never flows sideways
+- Data isn't shared between teams that depend on each other
+
+**Silo root causes:**
+1. **Incentive misalignment:** Teams rewarded for local metrics don't optimize for company metrics
+2. **No shared goals:** When teams share a goal, they coordinate. When they don't, they drift.
+3. **No shared language:** Engineering doesn't understand sales metrics; sales doesn't understand technical debt
+4. **Geography or time zones:** Silos accelerate when teams don't interact organically
+
+**Silo measurement:**
+- How often do teams request something from each other vs. proceed independently?
+- How much time does it take to resolve a cross-functional issue?
+- Can a team member describe the current priorities of an adjacent team?
+
+### Step 5: Communication Gap Analysis
+
+What the CEO says ≠ what teams hear. The gap grows with company size.
+
+**The message decay model:**
+- CEO communicates strategy at all-hands → managers filter through their lens → teams receive modified version → individuals interpret further
+
+**Gap sources:**
+- **Ambiguity:** Strategy stated at too high a level ("grow the business") lets each team fill in their own interpretation
+- **Frequency:** One all-hands per quarter isn't enough repetition to change behavior
+- **Medium mismatch:** Long written strategy doc for teams that respond to visual communication
+- **Trust deficit:** Teams don't believe the strategy is real ("we've heard this before")
+
+**Gap detection:**
+- Run the Step 1 articulation test across all levels
+- Compare what leadership thinks they communicated vs. what teams say they heard
+- Survey: "What changed about how you work since the last strategy update?"
+
+### Step 6: Realignment Protocol
+
+How to fix misalignment without calling it a "realignment" (which creates fear).
+
+**Step 6a: Don't start with what's wrong**
+Starting with "here's our misalignment" creates defensiveness. Start with "here's where we're heading and I want to make sure we're connected."
+
+**Step 6b: Re-cascade in a workshop, not a memo**
+Alignment workshops are more effective than documents. Get company-level OKR owners and department leads in a room. Map connections. Find gaps together.
+
+**Step 6c: Fix incentives before fixing goals**
+If department heads are rewarded for local metrics that conflict with company goals, no amount of goal-setting fixes the problem. The incentive structure must change first.
+
+**Step 6d: Install a quarterly alignment check**
+After fixing, prevent recurrence. See `references/alignment-playbook.md` for quarterly cadence.
+
+---
+
+## Alignment Score
+
+A quick health check. Score each area 0–10:
+
+| Area | Question | Score |
+|------|----------|-------|
+| Strategy clarity | Can 5 people from different teams state the strategy consistently? | /10 |
+| Cascade completeness | Do all team goals connect to company goals? | /10 |
+| Conflict detection | Have cross-team OKR conflicts been reviewed and resolved? | /10 |
+| Coverage | Does each company OKR have explicit team ownership? | /10 |
+| Communication | Do teams' behaviors reflect the strategy (not just their stated understanding)? | /10 |
+
+**Total: __ / 50**
+
+| Score | Status |
+|-------|--------|
+| 45–50 | Excellent. Maintain the system. |
+| 35–44 | Good. Address specific weak areas. |
+| 20–34 | Misalignment is costing you. Immediate attention required. |
+| < 20 | Strategic drift. Treat as crisis. |
+
+---
+
+## Key Questions for Alignment
+
+- "Ask your newest team member: what is the most important thing the company is trying to achieve right now?"
+- "Which company OKR does your team's top priority support? Can you trace the connection?"
+- "When Team A and Team B both hit their goals, does the company always win? Are there scenarios where they don't?"
+- "What changed in how your team works since the last strategy update?"
+- "Name a decision made last week that was influenced by the company strategy."
+
+## Red Flags
+
+- Teams consistently hit goals while company misses targets
+- Cross-functional projects take 3x longer than expected (coordination failure)
+- Strategy updated quarterly but team priorities don't change
+- "That's a leadership problem, not our problem" attitude at the team level
+- New initiatives announced without connecting them to existing OKRs
+- Department heads optimize for headcount or budget rather than company outcomes
+
+## Integration with Other C-Suite Roles
+
+| When... | Work with... | To... |
+|---------|-------------|-------|
+| New strategy is set | CEO + COO | Cascade into quarterly rocks before announcing |
+| OKR cycle starts | COO | Run cross-team conflict check before finalizing |
+| Team consistently misses goals | CHRO | Diagnose: capability gap or alignment gap? |
+| Silo identified | COO | Design shared metrics or cross-functional OKRs |
+| Post-M&A | CEO + Culture Architect | Detect strategy conflicts between merged entities |
+
+## Detailed References
+- `scripts/alignment_checker.py` — Automated OKR alignment analysis (orphans, conflicts, coverage)
+- `references/alignment-playbook.md` — Cascade techniques, quarterly alignment check, common patterns

package/c-level/stress-test/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: "stress-test"
+description: "/em -stress-test — Business Assumption Stress Testing"
+---
+
+# /em:stress-test — Business Assumption Stress Testing
+
+**Command:** `/em:stress-test <assumption>`
+
+Take any business assumption and break it before the market does. Revenue projections. Market size. Competitive moat. Hiring velocity. Customer retention.
+
+---
+
+## Why Most Assumptions Are Wrong
+
+Founders are optimists by nature. That's a feature — you need optimism to start something from nothing. But it becomes a liability when assumptions in business models get inflated by the same optimism that got you started.
+
+**The most dangerous assumptions are the ones everyone agrees on.**
+
+When the whole team believes the $50M market is real, when every investor call goes well so you assume the round will close, when your model shows $2M ARR by December and nobody questions it — that's when you're most exposed.
+
+Stress testing isn't pessimism. It's calibration.
+
+---
+
+## The Stress-Test Methodology
+
+### Step 1: Isolate the Assumption
+
+State it explicitly. Not "our market is large" but "the total addressable market for B2B spend management software in German SMEs is €2.3B."
+
+The more specific the assumption, the more testable it is. Vague assumptions are unfalsifiable — and therefore useless.
+
+**Common assumption types:**
+- **Market size** — TAM, SAM, SOM; growth rate; customer segments
+- **Customer behavior** — willingness to pay, churn, expansion, referrals
+- **Revenue model** — conversion rates, deal size, sales cycle, CAC
+- **Competitive position** — moat durability, competitor response speed, switching cost
+- **Execution** — team velocity, hire timeline, product timeline, operational scaling
+- **Macro** — regulatory environment, economic conditions, technology availability
+
+### Step 2: Find the Counter-Evidence
+
+For every assumption, actively search for evidence that it's wrong.
+
+Ask:
+- Who has tried this and failed?
+- What data contradicts this assumption?
+- What does the bear case look like?
+- If a smart skeptic was looking at this, what would they point to?
+- What's the base rate for assumptions like this?
+
+**Sources of counter-evidence:**
+- Comparable companies that failed in adjacent markets
+- Customer churn data from similar businesses
+- Historical accuracy of similar forecasts
+- Industry reports with conflicting data
+- What competitors who tried this found
+
+The goal isn't to find a reason to stop — it's to surface what you don't know.
+
+### Step 3: Model the Downside
+
+Most plans model the base case and the upside. Stress testing means modeling the downside explicitly.
+
+**For quantitative assumptions (revenue, growth, conversion):**
+
+| Scenario | Assumption Value | Probability | Impact |
+|----------|-----------------|-------------|--------|
+| Base case | [Original value] | ? | |
+| Bear case | -30% | ? | |
+| Stress case | -50% | ? | |
+| Catastrophic | -80% | ? | |
+
+Key question at each level: **Does the business survive? Does the plan make sense?**
+
+**For qualitative assumptions (moat, product-market fit, team capability):**
+
+- What's the earliest signal this assumption is wrong?
+- How long would it take you to notice?
+- What happens between when it breaks and when you detect it?
+
+### Step 4: Calculate Sensitivity
+
+Some assumptions matter more than others. Sensitivity analysis answers: **if this one assumption changes, how much does the outcome change?**
+
+Example: 
+- If CAC doubles, how does that change runway?
+- If churn goes from 5% to 10%, how does that change NRR in 24 months?
+- If the deal cycle is 6 months instead of 3, how does that affect Q3 revenue?
+
+High sensitivity = the assumption is a key lever. Wrong = big problem.
+
+### Step 5: Propose the Hedge
+
+For every high-risk assumption, there should be a hedge:
+
+- **Validation hedge** — test it before betting on it (pilot, customer conversation, small experiment)
+- **Contingency hedge** — if it's wrong, what's plan B?
+- **Early warning hedge** — what's the leading indicator that would tell you it's breaking before it's too late to act?
+
+---
+
+## Stress Test Patterns by Assumption Type
+
+### Revenue Projections
+
+**Common failures:**
+- Bottom-up model assumes 100% of pipeline converts
+- Doesn't account for deal slippage, churn, seasonality
+- New channel assumed to work before tested at scale
+
+**Stress questions:**
+- What's your actual historical win rate on pipeline?
+- If your top 3 deals slip to next quarter, what happens to the number?
+- What's the model look like if your new sales rep takes 4 months to ramp, not 2?
+- If expansion revenue doesn't materialize, what's the growth rate?
+
+**Test:** Build the revenue model from historical win rates, not hoped-for ones.
+
+### Market Size
+
+**Common failures:**
+- TAM calculated top-down from industry reports without bottoms-up validation
+- Conflating total market with serviceable market
+- Assuming 100% of SAM is reachable
+
+**Stress questions:**
+- How many companies in your ICP actually exist and can you name them?
+- What's your serviceable obtainable market in year 1-3?
+- What percentage of your ICP is currently spending on any solution to this problem?
+- What does "winning" look like and what market share does that require?
+
+**Test:** Build a list of target accounts. Count them. Multiply by ACV. That's your SAM.
+
+### Competitive Moat
+
+**Common failures:**
+- Moat is technology advantage that can be built in 6 months
+- Network effects that haven't yet materialized
+- Data advantage that requires scale you don't have
+
+**Stress questions:**
+- If a well-funded competitor copied your best feature in 90 days, what do customers do?
+- What's your retention rate among customers who have tried alternatives?
+- Is the moat real today or theoretical at scale?
+- What would it cost a competitor to reach feature parity?
+
+**Test:** Ask churned customers why they left and whether a competitor could have kept them.
+
+### Hiring Plan
+
+**Common failures:**
+- Time-to-hire assumes standard recruiting cycle, not current market
+- Ramp time not modeled (3-6 months before full productivity)
+- Key hire dependency: plan only works if specific person is hired
+
+**Stress questions:**
+- What happens if the VP Sales hire takes 5 months, not 2?
+- What does execution look like if you only hire 70% of planned headcount?
+- Which single person, if they left tomorrow, would most damage the plan?
+- Is the plan achievable with current team if hiring freezes?
+
+**Test:** Model the plan with 0 net new hires. What still works?
+
+### Competitive Response
+
+**Common failures:**
+- Assumes incumbents won't respond (they will if you're winning)
+- Underestimates speed of response
+- Doesn't model resource asymmetry
+
+**Stress questions:**
+- If the market leader copies your product in 6 months, how does pricing change?
+- What's your response if a competitor raises $30M to attack your space?
+- Which of your customers have vendor relationships with your competitors?
+
+---
+
+## The Stress Test Output
+
+```
+ASSUMPTION: [Exact statement]
+SOURCE: [Where this came from — model, investor pitch, team gut feel]
+
+COUNTER-EVIDENCE
+• [Specific evidence that challenges this assumption]
+• [Comparable failure case]
+• [Data point that contradicts the assumption]
+
+DOWNSIDE MODEL
+• Bear case (-30%): [Impact on plan]
+• Stress case (-50%): [Impact on plan]
+• Catastrophic (-80%): [Impact on plan — does the business survive?]
+
+SENSITIVITY
+This assumption has [HIGH / MEDIUM / LOW] sensitivity.
+A 10% change → [X] change in outcome.
+
+HEDGE
+• Validation: [How to test this before betting on it]
+• Contingency: [Plan B if it's wrong]
+• Early warning: [Leading indicator to watch — and at what threshold to act]
+```

package/c-level/vpe-advisor/SKILL.md

@@ -0,0 +1,230 @@
+---
+name: "vpe-advisor"
+description: "VP of Engineering advisory for startups: delivery throughput (DORA 4 metrics + bottleneck identification), engineering hiring funnel (sourcing → screen → onsite → offer conversion + time-to-fill + pipeline gap), engineering team structure (squad/tribe/chapter design + tech-lead manager-trigger thresholds), and production discipline (on-call, deployment cadence, postmortem culture). Use when sprint velocity is dropping, eng hiring is broken, team structure is unclear, or deciding when to add a tech-lead manager. NOT a CTO skill (which owns architecture) — VPE owns delivery operations and how the team ships."
+license: MIT
+metadata:
+  version: 1.0.0
+  author: Alireza Rezvani
+  category: c-level
+  domain: vp-engineering-leadership
+  updated: 2026-05-13
+  python-tools: delivery_throughput_analyzer.py, eng_hiring_funnel_calculator.py, eng_team_structure_designer.py
+  frameworks: delivery-throughput, hiring-funnel, team-structure, production-discipline
+---
+
+# VP of Engineering Advisor
+
+Strategic engineering operations leadership for startup VPEs and founders without one. **Four decisions, no generic engineering survey:**
+
+1. **Are we delivering at the right throughput?** — DORA 4 metrics + bottleneck identification (where work waits)
+2. **How do we scale the eng hiring funnel?** — funnel math + pipeline gap + time-to-fill discipline
+3. **What's our team structure — and when do we add a tech-lead manager?** — squad/tribe/chapter design + manager-trigger
+4. **What's our production discipline?** — on-call rotation, deployment cadence, postmortem culture (reference-only)
+
+This skill is **NOT a CTO skill**. CTO owns *what to build* (architecture, scaling cliffs, build-vs-buy). VPE owns *how to ship it reliably* (delivery, hiring, team structure, production operations). At early stage these are often the same person; at scale they're distinct roles.
+
+This skill is **NOT a cs-engineering-lead replacement**. Engineering-lead owns day-to-day incident and on-call coordination. VPE owns the operating model that engineering-lead executes.
+
+## Keywords
+
+VPE, VP of Engineering, VP Engineering, engineering operations, delivery throughput, DORA, deployment frequency, lead time for changes, mean time to recovery, MTTR, change failure rate, cycle time, lead time, throughput, engineering hiring, eng hiring funnel, technical interview, take-home, pair programming, hiring pipeline, time-to-fill, cost-per-hire, ramp time, engineering team structure, squad, tribe, chapter, Spotify model, conway's law, tech lead, engineering manager, EM, span of control, hiring funnel conversion, eng comp, leveling, IC track, manager track, deployment cadence, on-call rotation, postmortem culture, blameless retro
+
+## Quick Start
+
+```bash
+# Decision A: DORA 4 metrics + bottleneck identification
+python scripts/delivery_throughput_analyzer.py                          # embedded sprint sample
+python scripts/delivery_throughput_analyzer.py path/to/sprint_metrics.json
+
+# Decision B: Hiring funnel health + pipeline gap
+python scripts/eng_hiring_funnel_calculator.py                          # embedded 3-quarter sample
+python scripts/eng_hiring_funnel_calculator.py path/to/funnel.json
+
+# Decision C: Team structure recommendation + manager-trigger
+python scripts/eng_team_structure_designer.py                           # embedded 25-engineer sample
+python scripts/eng_team_structure_designer.py path/to/team.json
+```
+
+## Key Questions (ask these first)
+
+- **What's your cycle time, and where does the work spend most of its time waiting?** (If you don't know, you can't improve it.)
+- **How long from commit to production?** (DORA "lead time for changes" — best predictor of overall team health.)
+- **What's the escape rate?** (Bugs found in production vs caught in CI/staging. > 15% = quality discipline broken.)
+- **When did the eng manager last write code?** (Manager-IC ratio is wrong if managers can't review code at all.)
+- **What's the hiring funnel conversion at each stage?** (Source → screen → onsite → offer → accept. The leakage is the answer.)
+- **What's the on-call rotation, and who's on it?** (If the same 3 people are always paged, the operating model is broken.)
+
+## Core Responsibilities
+
+### 1. Delivery Throughput (DORA Metrics)
+
+**The framework:** Google DORA's 4 key metrics (from "Accelerate", Forsgren/Humble/Kim 2018).
+
+| Metric | What it measures | Elite | High | Medium | Low |
+|---|---|---|---|---|---|
+| **Deployment Frequency** | How often code reaches prod | Multiple/day | Daily-weekly | Weekly-monthly | < monthly |
+| **Lead Time for Changes** | Commit → production | < 1 hour | 1 day-1 week | 1 week-1 month | > 1 month |
+| **Mean Time to Recovery (MTTR)** | Incident detection → resolved | < 1 hour | < 1 day | 1-7 days | > 7 days |
+| **Change Failure Rate** | % of deploys causing incidents | 0-15% | 16-30% | 16-45% | 46-60% |
+
+**Bottleneck identification — where does work wait?**
+
+Cycle time = (PR creation → first review) + (review → approval) + (approval → merge) + (merge → deploy). The longest segment is the bottleneck.
+
+Common bottlenecks:
+- **PR review queue** (waiting for human reviewers) — fix: reviewer rotation + SLA
+- **Test flakiness** (CI fails intermittently, re-runs needed) — fix: flaky-test budget + quarantine
+- **Deploy gates** (manual approval, change-control board) — fix: progressive delivery + feature flags
+- **Database migrations** (locking, scheduled windows) — fix: zero-downtime migration patterns
+
+**Run** `delivery_throughput_analyzer.py` with sprint data to get DORA verdict + top bottleneck.
+
+See `references/delivery_throughput.md` for the full DORA framework, anti-patterns, and what to fix first.
+
+### 2. Engineering Hiring Funnel
+
+**The trap:** "We can't find good engineers."
+
+The reality: the funnel has 4-6 stages, each with a conversion rate. Find which stage is leakiest; fix that one. "Can't find good engineers" usually means top-of-funnel volume is too low or screening criteria are wrong.
+
+**Standard funnel stages:**
+
+| Stage | Healthy conversion | What it measures |
+|---|---|---|
+| Applied → Sourcer screen | 30-50% | Resume quality |
+| Sourcer → Recruiter screen | 50-70% | Basic fit |
+| Recruiter → Hiring manager | 60-80% | Team fit |
+| Hiring manager → Technical interview | 70-85% | Technical baseline |
+| Technical → Onsite (full loop) | 30-50% | Technical depth |
+| Onsite → Offer | 25-40% | Final go/no-go |
+| Offer → Accept | 70-90% | Comp + close discipline |
+
+**Funnel math:** to hire N engineers, you need N / (product of all conversion rates) candidates at top of funnel.
+
+Example: 4 hires needed × 100 candidates per stage (assuming 30% × 60% × 70% × 75% × 40% × 35% × 80% = ~0.7% end-to-end) = ~570 candidates at top of funnel.
+
+**Run** `eng_hiring_funnel_calculator.py` with funnel data to compute conversion per stage, time-to-fill, and pipeline gap.
+
+See `references/engineering_hiring_funnel.md` for the full funnel framework, common leakage points, and sourcing channel diversification.
+
+### 3. Engineering Team Structure
+
+**The right question:** "How do we organize people so they can ship without coordination overhead?"
+
+**Three-axis model (adapted from Spotify, refined by reality):**
+
+- **Squad:** small autonomous team (5-9 engineers) owning a service or product area end-to-end
+- **Chapter:** functional discipline cutting across squads (backend chapter, frontend chapter, etc.) — for skill development, NOT for ownership
+- **Tribe:** group of related squads working toward a shared goal (e.g., "platform tribe" = 3 squads on infra)
+
+**When to evolve:**
+
+| Stage | Structure |
+|---|---|
+| 1-5 engineers | One team. No structure. |
+| 6-15 engineers | 2-3 informal pods around major work streams. Founder-CTO can still know everyone. |
+| 16-40 engineers | 4-6 squads. First eng manager hires. Chapter structure emerges for cross-squad skill alignment. |
+| 41-100 engineers | 2-3 tribes (clusters of squads). Director of engineering layer. Chapters are formal. |
+| 100+ engineers | Multiple tribes + group EM/director per tribe. VPE + director(s) + EMs + tech leads. |
+
+**Manager-trigger thresholds:**
+- 5-7 ICs without a manager = first EM hire (or internal promote)
+- 3+ EMs without a director = director hire
+- 8+ teams in one tribe = split the tribe
+
+**Run** `eng_team_structure_designer.py` with team profile for structure recommendation + manager-trigger.
+
+See `references/eng_team_structure.md` for the full framework, Conway's Law implications, and EM-vs-tech-lead split.
+
+### 4. Production Discipline
+
+Production discipline is the operating model that lets the team sleep. Four pillars:
+
+- **On-call rotation:** broad enough to avoid burnout (≥ 6 people per rotation; primary + secondary)
+- **Incident response:** runbooks, severity definitions, blameless postmortems
+- **Deployment cadence:** continuous deployment OR scheduled releases; both work; surprise releases don't
+- **SLO discipline:** every customer-facing service has documented SLOs + error budgets (pair with `engineering/slo-architect/`)
+
+See `references/production_discipline.md` for the full operating model.
+
+## Workflows
+
+### Workflow 1: Quarterly Delivery Health Review (4 hours)
+**Goal:** Diagnose throughput + identify top bottleneck.
+
+```bash
+# 1. Pull sprint metrics: deployment frequency, lead time, MTTR, change failure rate
+python ../../skills/vpe-advisor/scripts/delivery_throughput_analyzer.py sprint_metrics.json
+# 2. Review DORA verdict per metric
+# 3. Identify top bottleneck (longest wait stage)
+# 4. Cross-check with cs-cto-advisor on architectural causes
+# 5. Output: 90-day fix plan with one bottleneck owned by one engineer
+# 6. Log via /cs:decide
+```
+
+### Workflow 2: Hiring Funnel Diagnosis (1 day)
+**Goal:** Identify funnel leakage + compute pipeline gap for hiring target.
+
+```bash
+# 1. Pull funnel data from ATS for last 90 days
+python ../../skills/vpe-advisor/scripts/eng_hiring_funnel_calculator.py funnel.json
+# 2. Identify weakest conversion stage
+# 3. Compute pipeline volume needed for next quarter's hiring target
+# 4. Cross-check with cs-chro-advisor on comp/leveling competitiveness
+# 5. Cross-check with cs-cfo-advisor on cost-per-hire envelope
+# 6. Output: top-3 fixes + sourcing channel diversification plan
+```
+
+### Workflow 3: Team Structure Audit (1 day)
+**Goal:** Confirm team structure matches headcount + work streams.
+
+```bash
+# 1. Build team.json: headcount, work streams, manager count, IC distribution
+python ../../skills/vpe-advisor/scripts/eng_team_structure_designer.py team.json
+# 2. Check manager-trigger thresholds (5-7 IC rule)
+# 3. Identify squad sizes outside 5-9 range
+# 4. Cross-check with cs-cto-advisor on Conway's Law alignment
+# 5. Output: structure recommendations + manager hire plan
+```
+
+### Workflow 4: Production Discipline Audit (1 week)
+**Goal:** Confirm operating model can scale through current growth.
+
+1. Inventory: on-call coverage, incident frequency by severity, MTTR trend
+2. Confirm every customer-facing service has SLOs (pair with `engineering/slo-architect/`)
+3. Review last 5 postmortems — are they blameless? Are action items closed?
+4. Cross-check deployment cadence against DORA verdict
+5. Output: production-discipline maturity score + 90-day improvement plan
+
+## Output Standards
+
+```
+**Bottom Line:** [one sentence — decision and rationale]
+**The Decision:** [one of: throughput | hiring | structure | production]
+**The Evidence:** [numbers from the tool, not adjectives]
+**How to Act:** [3 concrete next steps]
+**Your Decision:** [the call only the founder/CTO can make]
+```
+
+## Adjacent Skills
+
+- `../cto-advisor/` — Architecture, scaling cliffs, tech debt strategy (CTO decides what to build; VPE decides how to ship)
+- `../chro-advisor/` — Hiring systems (ladders, bands, leveling rubrics company-wide); VPE owns eng-specific funnel execution
+- `../coo-advisor/` — Operating cadence company-wide; VPE owns eng-specific cadence
+- `../../../engineering/slo-architect/` — SLO design (tactical; VPE owns the policy that SLOs are required)
+- `../../../engineering/chaos-engineering/` — Chaos experiment design (tactical resilience)
+- `../../../engineering/feature-flags-architect/` — Progressive delivery (tactical deployment)
+- `../../../engineering/kubernetes-operator/` — K8s operator pattern (tactical infra)
+- `cs-engineering-lead` agent — Day-to-day incident + on-call coordination (VPE owns the operating model that engineering-lead executes)
+
+## References
+
+- [delivery_throughput.md](references/delivery_throughput.md) — Full DORA framework + 4 common bottlenecks + what to fix first + anti-patterns
+- [engineering_hiring_funnel.md](references/engineering_hiring_funnel.md) — 7-stage funnel + conversion benchmarks + common leakage + sourcing channel diversification + technical interview design
+- [eng_team_structure.md](references/eng_team_structure.md) — Squad/chapter/tribe model + headcount-to-structure map + Conway's Law + EM-vs-tech-lead split + span-of-control
+- [production_discipline.md](references/production_discipline.md) — On-call rotation design + incident response + blameless postmortem culture + deployment cadence + SLO discipline integration
+
+---
+
+**Version:** 1.0.0
+**Status:** Production Ready