claude-code-arcane 1.0.0

package/skills/executive-mentor/skills/challenge/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: challenge
+description: "Pre-mortem plan analysis sub-skill. Systematically finds weaknesses in any plan before reality does — extracts assumptions, rates confidence, maps dependencies."
+argument-hint: ""
+category: "clevel-advisors"
+user-invocable: false
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# /em:challenge — Pre-Mortem Plan Analysis
+
+**Command:** `/em:challenge <plan>`
+
+Systematically finds weaknesses in any plan before reality does. Not to kill the plan — to make it survive contact with reality.
+
+## The Core Idea
+
+Most plans fail for predictable reasons. Not bad luck — bad assumptions. The pre-mortem technique: **imagine it's 12 months from now and this plan failed spectacularly. Now work backwards. Why?**
+
+## The Challenge Framework
+
+### Step 1: Extract Core Assumptions
+For each section of the plan, ask: What has to be true for this to work?
+
+**Common assumption categories:** Market (size, growth, willingness to pay), Execution (team capacity, velocity), Customer (they have the problem, they'll pay), Competitive (incumbents won't respond), Financial (burn rate, revenue timing), Dependencies (partner will deliver).
+
+### Step 2: Rate Each Assumption
+- **Confidence:** High (verified with data) / Medium (directionally right) / Low (untested) / Unknown
+- **Impact if wrong:** Critical (plan fails) / High (major delay) / Medium (significant rework) / Low (manageable)
+
+### Step 3: Map Vulnerabilities
+**Vulnerability = Low confidence + High impact.** These are the bets you're making.
+
+### Step 4: Find the Dependency Chain
+Does assumption B depend on A being true first? What's the critical path with zero slack?
+
+### Step 5: Test the Reversibility
+For each critical vulnerability: if wrong at month 3, can you pivot? Is money already spent? Commitments made?
+
+## Output Format
+
+```
+CORE ASSUMPTIONS (extracted)
+1. [Assumption] — Confidence: [H/M/L/?] — Impact if wrong: [Critical/High/Medium/Low]
+
+VULNERABILITY MAP
+Critical risks (act before proceeding):
+• [#N] [Assumption] — WHY it might be wrong — WHAT breaks if it is
+
+DEPENDENCY CHAIN
+[Assumption A] → depends on → [Assumption B] → which enables → [Assumption C]
+Weakest link: [X]
+
+REVERSIBILITY ASSESSMENT
+• Reversible bets: [list]
+• Irreversible commitments: [list — treat with extreme care]
+
+KILL SWITCHES
+• Continue if: ...
+• Kill/pivot if: ...
+
+HARDENING ACTIONS
+1. [Specific validation to do before proceeding]
+2. [Alternative approach to consider]
+3. [Contingency to build into the plan]
+```
+
+## Challenge Patterns by Plan Type
+
+**Product Roadmap:** Does the velocity estimate account for real team capacity? What if the anchor feature takes 3x longer?
+
+**Go-to-Market:** What's the actual ICP conversion rate, not the hoped-for one? Is "land and expand" a real motion or a hope?
+
+**Hiring Plan:** What happens if the key hire takes 4 months to find? Does the plan account for ramp time?
+
+**Fundraising Plan:** Have you modeled the timeline if it takes 6 months, not 3? What assumptions break if you raise 50% of target?
+
+## Deliverable
+
+The output is not permission to stop. It's a vulnerability map. Unknown risks are dangerous. Known risks are manageable.

package/skills/executive-mentor/skills/hard-call/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: hard-call
+description: "Framework for decisions with no good options sub-skill. Covers reversibility testing, stakeholder impact mapping, and communication planning for layoffs, pivots, and firings."
+argument-hint: ""
+category: "clevel-advisors"
+user-invocable: false
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# /em:hard-call — Framework for Decisions With No Good Options
+
+**Command:** `/em:hard-call <decision>`
+
+For the decisions that keep you up at 3am. Firing a co-founder. Laying off 20% of the team. Killing a product customers love. These decisions don't have a right answer — they have a less wrong answer.
+
+## Why These Decisions Are Hard
+
+Not because the data is unclear. They're hard because: real people are affected, you've been avoiding the decision, it's irreversible, and your judgment is clouded by your feelings.
+
+**Most hard decisions are late decisions.** The longer you avoid, the worse it gets.
+
+## The Framework
+
+### Step 1: The Reversibility Test
+- **Reversible** — try it, learn, adjust
+- **Partially reversible** — painful to undo but possible
+- **Irreversible** — cannot be undone (higher bar for certainty)
+
+**If you're treating a reversible decision like it's irreversible, you're avoiding it.**
+
+### Step 2: The 10/10/10 Framework
+- **10 minutes from now**: How will you feel?
+- **10 months from now**: Will the problem be solved?
+- **10 years from now**: Will this have been the right call?
+
+### Step 3: The Andy Grove Test
+"If we got replaced tomorrow and a new CEO came in, what would they do?" If the answer is clear to an outsider, the question is: why haven't you done it yet?
+
+### Step 4: Stakeholder Impact Mapping
+Map who's affected and how for each option. This isn't about finding the option that hurts nobody — there isn't one.
+
+### Step 5: The Pre-Announcement Test
+Write the announcement. If you can't write it, you're not ready to make the decision. Writing it forces you to confront the reality.
+
+### Step 6: The Communication Plan
+- **Who needs to know first** (the person directly affected, before anyone else)
+- **How you'll tell them** (in person when possible, never via email for personal impact)
+- **What comes next** (give them a clear picture)
+
+## Decision-Specific Frameworks
+
+**Firing a Co-Founder:** Is this performance or values? Have you been explicit about the problem? What do the cap table and legal implications look like? See `references/hard_things.md`.
+
+**Layoffs:** Cut once, cut deep, cut with dignity. Two rounds destroys trust.
+
+**Pivoting:** Pivots should be pulled by evidence of new opportunity, not pushed by failure.
+
+**Killing a Product Line:** What happens to customers? What's the migration path? Is "sell it" or "spin it out" better than killing?
+
+## The Avoiding-It Test
+
+You're avoiding a hard call if: you've thought about it every week for a month, you're hoping it resolves itself, you've had the conversation in your head but not in real life.
+
+**The cost of delay is almost always higher than the cost of the decision.**

package/skills/executive-mentor/skills/postmortem/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: postmortem
+description: "Honest post-mortem analysis sub-skill. Rigorous investigation of system failures using 5 Whys, root cause vs contributing factors, and owned change registers."
+argument-hint: ""
+category: "clevel-advisors"
+user-invocable: false
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# /em:postmortem — Honest Analysis of What Went Wrong
+
+**Command:** `/em:postmortem <event>`
+
+Not blame. Understanding. The failed deal, the missed quarter, the feature that flopped. What actually happened, why, and what changes as a result.
+
+## Why Most Post-Mortems Fail
+
+**The blame session** — someone gets scapegoated, actual causes don't get examined, same problem recurs.
+
+**The whitewash** — "We learned a lot, here are 12 vague action items." Nothing changes.
+
+A real post-mortem is a rigorous investigation into a system failure. Not "whose fault" but "what conditions made this outcome predictable in hindsight?"
+
+## The Framework
+
+### Step 1: Define the Event Precisely
+Expected outcome vs actual outcome. When was the gap first visible? Quantified impact.
+
+### Step 2: The 5 Whys — Done Properly
+Get from the symptom to the root cause. **Test for a good root cause:** Could you prevent recurrence with a specific, concrete change?
+
+### Step 3: Distinguish Contributing Factors from Root Cause
+Contributing factors made it worse but aren't the core reason. Fix only contributing factors and you'll have a structurally identical failure next time.
+
+### Step 4: Identify Warning Signs That Were Ignored
+At what point was the negative outcome predictable? Who saw it? Why wasn't it acted on?
+
+### Step 5: In Control vs. Out of Control
+For things in control: what specifically needs to change? For things out of control: how to be more resilient?
+
+### Step 6: Build the Change Register
+**Bad action items:** "We'll improve our qualification process"
+**Good action items:** "Ravi owns rewriting qualification criteria by March 15 to include champion identification as hard requirement."
+
+For each action: What exactly changes? Who owns it? By when? How to verify it worked?
+
+### Step 7: Verification Date
+Set a date to check whether changes actually happened and worked. Without this, post-mortems are theater.
+
+## Post-Mortem Output Format
+
+```
+EVENT: [Name and date]
+EXPECTED: [What was supposed to happen]
+ACTUAL: [What happened]
+IMPACT: [Quantified]
+
+TIMELINE
+[Date]: [What happened or was visible]
+
+5 WHYS
+1. [Why?] → Because [Y]
+2-5. [chain to ROOT CAUSE]
+
+ROOT CAUSE: [One clear sentence]
+CONTRIBUTING FACTORS: [with how they contributed]
+WARNING SIGNS MISSED: [signal + why not acted on]
+
+CHANGE REGISTER
+| Action | Owner | Due Date | Verification |
+|--------|-------|----------|-------------|
+
+VERIFICATION DATE: [Date of check-in]
+```
+
+## The Tone of Good Post-Mortems
+
+"The salesperson didn't qualify the deal properly" is blame. "Our qualification framework hadn't been updated when we moved upmarket, and no one owned keeping it current" is understanding. The second version builds a more resilient organization.

package/skills/executive-mentor/skills/stress-test/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: stress-test
+description: "Business assumption stress testing sub-skill. Takes any assumption and breaks it before the market does — revenue projections, market size, competitive moat, hiring velocity."
+argument-hint: ""
+category: "clevel-advisors"
+user-invocable: false
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# /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. **The most dangerous assumptions are the ones everyone agrees on.** 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 TAM for B2B spend management in German SMEs is 2.3B EUR." The more specific, the more testable.
+
+### Step 2: Find the Counter-Evidence
+For every assumption, actively search for evidence that it's wrong. Who has tried this and failed? What data contradicts this? What's the base rate?
+
+### Step 3: Model the Downside
+
+| 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?**
+
+### Step 4: Calculate Sensitivity
+If this one assumption changes, how much does the outcome change? High sensitivity = the assumption is a key lever.
+
+### Step 5: Propose the Hedge
+- **Validation hedge** — test before betting (pilot, customer conversation, experiment)
+- **Contingency hedge** — if wrong, what's plan B?
+- **Early warning hedge** — leading indicator that tells you it's breaking before it's too late
+
+## Stress Test Patterns
+
+See `references/patterns-by-type.md` for detailed patterns covering: Revenue Projections, Market Size, Competitive Moat, Hiring Plan, and Competitive Response.
+
+## The Stress Test Output
+
+```
+ASSUMPTION: [Exact statement]
+SOURCE: [Where this came from]
+
+COUNTER-EVIDENCE
+• [Specific evidence that challenges this assumption]
+• [Comparable failure case]
+
+DOWNSIDE MODEL
+• Bear case (-30%): [Impact on plan]
+• Stress case (-50%): [Impact on plan]
+• Catastrophic (-80%): [Does the business survive?]
+
+SENSITIVITY
+This assumption has [HIGH / MEDIUM / LOW] sensitivity.
+A 10% change → [X] change in outcome.
+
+HEDGE
+• Validation: [How to test before betting]
+• Contingency: [Plan B if wrong]
+• Early warning: [Leading indicator to watch — and threshold to act]
+```

package/skills/executive-mentor/skills/stress-test/references/patterns-by-type.md

@@ -0,0 +1,73 @@
+# 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?

package/skills/experiment-designer/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: experiment-designer
+description: "Plan product experiments, write testable hypotheses, estimate sample size, prioritize tests with ICE scoring, and interpret A/B outcomes with practical statistical rigor."
+argument-hint: ""
+category: "agile"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# Experiment Designer
+
+Design, prioritize, and evaluate product experiments with clear hypotheses and defensible decisions.
+
+## When To Use
+
+Use this skill for:
+- A/B and multivariate experiment planning
+- Hypothesis writing and success criteria definition
+- Sample size and minimum detectable effect planning
+- Experiment prioritization with ICE scoring
+- Reading statistical output for product decisions
+
+## Core Workflow
+
+1. Write hypothesis in If/Then/Because format
+- If we change `[intervention]`
+- Then `[metric]` will change by `[expected direction/magnitude]`
+- Because `[behavioral mechanism]`
+
+2. Define metrics before running test
+- Primary metric: single decision metric
+- Guardrail metrics: quality/risk protection
+- Secondary metrics: diagnostics only
+
+3. Estimate sample size
+- Baseline conversion or baseline mean
+- Minimum detectable effect (MDE)
+- Significance level (alpha) and power
+
+Use:
+```bash
+python3 scripts/sample_size_calculator.py --baseline-rate 0.12 --mde 0.02 --mde-type absolute
+```
+
+4. Prioritize experiments with ICE
+- Impact: potential upside
+- Confidence: evidence quality
+- Ease: cost/speed/complexity
+
+ICE Score = (Impact * Confidence * Ease) / 10
+
+5. Launch with stopping rules
+- Decide fixed sample size or fixed duration in advance
+- Avoid repeated peeking without proper method
+- Monitor guardrails continuously
+
+6. Interpret results
+- Statistical significance is not business significance
+- Compare point estimate + confidence interval to decision threshold
+- Investigate novelty effects and segment heterogeneity
+
+## Hypothesis Quality Checklist
+
+- [ ] Contains explicit intervention and audience
+- [ ] Specifies measurable metric change
+- [ ] States plausible causal reason
+- [ ] Includes expected minimum effect
+- [ ] Defines failure condition
+
+## Common Experiment Pitfalls
+
+- Underpowered tests leading to false negatives
+- Running too many simultaneous changes without isolation
+- Changing targeting or implementation mid-test
+- Stopping early on random spikes
+- Ignoring sample ratio mismatch and instrumentation drift
+- Declaring success from p-value without effect-size context
+
+## Statistical Interpretation Guardrails
+
+- p-value < alpha indicates evidence against null, not guaranteed truth.
+- Confidence interval crossing zero/no-effect means uncertain directional claim.
+- Wide intervals imply low precision even when significant.
+- Use practical significance thresholds tied to business impact.
+
+See:
+- `references/experiment-playbook.md`
+- `references/statistics-reference.md`
+
+## Tooling
+
+### `scripts/sample_size_calculator.py`
+
+Computes required sample size (per variant and total) from:
+- baseline rate
+- MDE (absolute or relative)
+- significance level (alpha)
+- statistical power
+
+Example:
+```bash
+python3 scripts/sample_size_calculator.py \
+  --baseline-rate 0.10 \
+  --mde 0.015 \
+  --mde-type absolute \
+  --alpha 0.05 \
+  --power 0.8
+```

package/skills/experiment-designer/references/experiment-playbook.md

@@ -0,0 +1,70 @@
+# Experiment Playbook
+
+## Experiment Types
+
+### A/B Test
+- Compare one control versus one variant.
+- Best for high-confidence directional decisions.
+
+### Multivariate Test
+- Test combinations of multiple factors.
+- Useful for interaction effects, requires larger traffic.
+
+### Holdout Test
+- Keep a percentage unexposed to intervention.
+- Useful for measuring incremental lift over broader changes.
+
+## Metric Design
+
+### Primary Metric
+- One metric that decides ship/no-ship.
+- Must align with user value and business objective.
+
+### Guardrail Metrics
+- Prevent local optimization damage.
+- Examples: error rate, latency, churn proxy, support contacts.
+
+### Diagnostic Metrics
+- Explain why change happened.
+- Do not use as decision gate unless pre-specified.
+
+## Stopping Rules
+
+Define before launch:
+- Fixed sample size per group
+- Minimum run duration (to capture weekday/weekend behavior)
+- Guardrail breach thresholds (pause criteria)
+
+Avoid:
+- Continuous peeking with fixed-horizon inference
+- Changing success metric mid-test
+- Retroactive segmentation without correction
+
+## Novelty and Primacy Effects
+
+- Novelty effect: short-term spike due to newness, not durable value.
+- Primacy effect: early exposure creates bias in user behavior.
+
+Mitigation:
+- Run long enough for behavior stabilization.
+- Check returning users and delayed cohorts separately.
+- Re-run key tests when stakes are high.
+
+## Pre-Launch Checklist
+
+- [ ] Hypothesis complete (If/Then/Because)
+- [ ] Metric definitions frozen
+- [ ] Instrumentation validated
+- [ ] Randomization and assignment verified
+- [ ] Sample size and duration approved
+- [ ] Rollback plan documented
+
+## Post-Test Readout Template
+
+1. Hypothesis and scope
+2. Experiment setup and quality checks
+3. Primary metric effect size + confidence interval
+4. Guardrail status
+5. Segment-level observations (pre-registered only)
+6. Decision: ship, iterate, or reject
+7. Follow-up experiments

package/skills/experiment-designer/references/statistics-reference.md

@@ -0,0 +1,56 @@
+# Statistics Reference for Product Managers
+
+## p-value
+
+The p-value is the probability of observing data at least as extreme as yours if there were no true effect.
+
+- Small p-value means data is less consistent with "no effect".
+- It does not tell you the probability that the variant is best.
+
+## Confidence Interval (CI)
+
+A CI gives a plausible range for the true effect size.
+
+- Narrow interval: more precise estimate.
+- Wide interval: uncertain estimate.
+- If CI includes zero (or no-effect), directional confidence is weak.
+
+## Minimum Detectable Effect (MDE)
+
+The smallest effect worth detecting.
+
+- Set MDE by business value threshold, not wishful optimism.
+- Smaller MDE requires larger sample size.
+
+## Statistical Power
+
+Power is the probability of detecting a true effect of at least MDE.
+
+- Common target: 80% (0.8)
+- Higher power increases sample requirements.
+
+## Type I and Type II Errors
+
+- Type I (false positive): claim effect when none exists (controlled by alpha).
+- Type II (false negative): miss a real effect (controlled by power).
+
+## Practical Significance
+
+An effect can be statistically significant but too small to matter.
+
+Always ask:
+- Does the effect clear implementation cost?
+- Does it move strategic KPIs materially?
+
+## Power Analysis Inputs
+
+For conversion experiments (two proportions):
+- Baseline conversion rate
+- MDE (absolute points or relative uplift)
+- Alpha (e.g., 0.05)
+- Power (e.g., 0.8)
+
+Output:
+- Required sample size per variant
+- Total sample size
+- Approximate runtime based on traffic volume