aigroup-workflow 1.0.0 → 1.1.0

package/skills/jarvis/engineering-team/docs/skills/c-level-advisor/executive-mentor-hard-call.md

@@ -1,168 +0,0 @@
----
-title: "/em:hard-call — Framework for Decisions With No Good Options — Agent Skill for Executives"
-description: "/em -hard-call — Framework for Decisions With No Good Options. Agent skill for Claude Code, Codex CLI, Gemini CLI, OpenClaw."
----
-
-# /em:hard-call — Framework for Decisions With No Good Options
-
-<div class="page-meta" markdown>
-<span class="meta-badge">:material-account-tie: C-Level Advisory</span>
-<span class="meta-badge">:material-identifier: `hard-call`</span>
-<span class="meta-badge">:material-github: <a href="https://github.com/alirezarezvani/claude-skills/tree/main/c-level-advisor/executive-mentor/skills/hard-call/SKILL.md">Source</a></span>
-</div>
-
-<div class="install-banner" markdown>
-<span class="install-label">Install:</span> <code>claude /plugin install c-level-skills</code>
-</div>
-
-
-**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 that customers love. Pivoting. Shutting down.
-
-These decisions don't have a right answer. They have a less wrong answer. This framework helps you find it.
-
----
-
-## Why These Decisions Are Hard
-
-Not because the data is unclear. Often, the data is clear. They're hard because:
-
-1. **Real people are affected** — someone loses a job, a relationship ends, a team is hurt
-2. **You've been avoiding the decision** — which means the problem is already worse than it was
-3. **Irreversibility** — unlike most business decisions, you can't undo this easily
-4. **You have skin in the game** — your judgment about the right call is clouded by your feelings about it
-
-The longer you avoid a hard call, the worse the situation usually gets. The company that needed a 10% cut 6 months ago now needs a 25% cut. The co-founder conversation that should have happened at month 4 is happening at month 14.
-
-**Most hard decisions are late decisions.**
-
----
-
-## The Framework
-
-### Step 1: The Reversibility Test
-
-The most important question first: **can you undo this?**
-
-- **Reversible** — try it, learn, adjust (fire the vendor, kill the feature, change the strategy)
-- **Partially reversible** — painful to undo but possible (restructure, change co-founder roles)
-- **Irreversible** — cannot be undone (layoff a person, shut down a product with customer lock-in, close a legal entity)
-
-For irreversible decisions, the bar for certainty is higher. You must do more due diligence before acting. Not because you might be wrong — but because you can't take it back.
-
-**If you're treating a reversible decision like it's irreversible, you're avoiding it.**
-
-### Step 2: The 10/10/10 Framework
-
-Ask three questions about each option:
-
-- **10 minutes from now**: How will you feel immediately after making this decision?
-- **10 months from now**: What will the impact be? Will the problem be solved?
-- **10 years from now**: When you look back, will this have been the right call?
-
-The 10-minute feeling is usually the least reliable guide. The 10-year view usually clarifies what the right call actually is.
-
-**Most hard decisions look obvious at 10 years. The question is whether you can tolerate the 10-minute pain.**
-
-### Step 3: The Andy Grove Test
-
-Andy Grove's test for strategic decisions: "If we got replaced tomorrow and a new CEO came in, what would they do?"
-
-A fresh set of eyes, no emotional investment in the current path, no sunk cost. What's the obvious right call from the outside?
-
-If the answer is clear to an outsider, the question becomes: why haven't you done it yet?
-
-### Step 4: Stakeholder Impact Mapping
-
-For each option, map who's affected and how:
-
-| Stakeholder | Option A Impact | Option B Impact | Their reaction |
-|-------------|----------------|----------------|----------------|
-| Affected employees | | | |
-| Remaining team | | | |
-| Customers | | | |
-| Investors | | | |
-| You | | | |
-
-This isn't about finding the option that hurts nobody — there isn't one. It's about understanding the full picture before you decide.
-
-### Step 5: The Pre-Announcement Test
-
-Before making the decision: write the announcement. The email to the team, the message to the customer, the conversation you'll have.
-
-**If you can't write that announcement, you're not ready to make the decision.**
-
-Writing it forces you to confront the reality of what you're doing. It also surfaces whether your reasoning holds under examination. "We're making this change because…" — does that sentence ring true?
-
-### Step 6: The Communication Plan
-
-Hard decisions almost always get harder if communication is bad. The decision itself is not the only thing that matters — how it's done matters enormously.
-
-For every hard call, 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 you'll say** (honest, direct, compassionate — see `references/hard_things.md`)
-- **What they can ask** (be ready for every question)
-- **What comes next** (give them a clear picture of what happens after)
-
----
-
-## Decision-Specific Frameworks
-
-### Firing a Co-Founder
-See `references/hard_things.md — Co-Founder Conflicts` for full framework.
-
-Key questions to answer first:
-- Is this a performance problem or a values/culture problem? (Different conversations)
-- Have you been explicit — not hinted, but direct — about the problem?
-- What does the cap table look like and what are the legal implications?
-- Is there a role that works better for them, or is this a full exit?
-- Who needs to know (board, team, investors) and in what order?
-
-**The rule:** If you've been thinking about this for more than 3 months, you already know the answer. The question is when, not whether.
-
-### Layoffs
-Key questions:
-- Is this a one-time reset or the beginning of a longer decline? (One reset is recoverable. Serial layoffs kill culture.)
-- Are you cutting deep enough? (Insufficient layoffs are worse than no layoffs — two rounds destroys trust.)
-- Who owns the announcement and is it direct and honest?
-- What's the severance and is it fair?
-- How do you prevent the best people from leaving after?
-
-**The rule:** Cut once, cut deep, cut with dignity. Uncertainty is worse than clarity.
-
-### Pivoting
-Key questions:
-- Is this a true pivot (new direction) or an optimization (same direction, different tactic)?
-- What are you keeping and what are you abandoning?
-- Do you have evidence the new direction works, or are you running from failure?
-- How do you tell current customers who bought the old vision?
-- What does this do to the board's confidence?
-
-**The rule:** Pivots should be pulled by evidence of new opportunity, not pushed by failure of the current path.
-
-### Killing a Product Line
-Key questions:
-- What happens to customers currently using it?
-- What's the migration path?
-- What do the people who built it do?
-- Is "kill it" the right call or is "sell it" or "spin it out" better?
-- What's the narrative — internally and externally?
-
----
-
-## The Avoiding-It Test
-
-You know you've been avoiding a hard call if:
-- You've thought about it every week for more than a month
-- You're hoping the situation will "resolve itself"
-- You're waiting for more data that you'll never feel is enough
-- You've had the conversation in your head many times but not in real life
-- Other people around you have noticed the problem
-
-**The cost of delay is almost always higher than the cost of the decision.**
-
-Every month you wait, the problem compounds. The co-founder who's not working out becomes more entrenched. The product line that needs to die consumes more resources. The person who needs to be let go affects the people around them.
-
-Make the call. Make it clearly. Make it with dignity.

package/skills/jarvis/engineering-team/docs/skills/c-level-advisor/executive-mentor-postmortem.md

@@ -1,204 +0,0 @@
----
-title: "/em:postmortem — Honest Analysis of What Went Wrong — Agent Skill for Executives"
-description: "/em -postmortem — Honest Analysis of What Went Wrong. Agent skill for Claude Code, Codex CLI, Gemini CLI, OpenClaw."
----
-
-# /em:postmortem — Honest Analysis of What Went Wrong
-
-<div class="page-meta" markdown>
-<span class="meta-badge">:material-account-tie: C-Level Advisory</span>
-<span class="meta-badge">:material-identifier: `postmortem`</span>
-<span class="meta-badge">:material-github: <a href="https://github.com/alirezarezvani/claude-skills/tree/main/c-level-advisor/executive-mentor/skills/postmortem/SKILL.md">Source</a></span>
-</div>
-
-<div class="install-banner" markdown>
-<span class="install-label">Install:</span> <code>claude /plugin install c-level-skills</code>
-</div>
-
-
-**Command:** `/em:postmortem <event>`
-
-Not blame. Understanding. The failed deal, the missed quarter, the feature that flopped, the hire that didn't work out. What actually happened, why, and what changes as a result.
-
----
-
-## Why Most Post-Mortems Fail
-
-They become one of two things:
-
-**The blame session** — someone gets scapegoated, defensive walls go up, actual causes don't get examined, and the same problem happens again in a different form.
-
-**The whitewash** — "We learned a lot, we're going to do better, here are 12 vague action items." Nothing changes. Same problem, different quarter.
-
-A real post-mortem is neither. It's a rigorous investigation into a system failure. Not "whose fault was it" but "what conditions made this outcome predictable in hindsight?"
-
-**The purpose:** extract the maximum learning value from a failure so you can prevent recurrence and improve the system.
-
----
-
-## The Framework
-
-### Step 1: Define the Event Precisely
-
-Before analysis: describe exactly what happened.
-
-- What was the expected outcome?
-- What was the actual outcome?
-- When was the gap first visible?
-- What was the impact (financial, operational, reputational)?
-
-Precision matters. "We missed Q3 revenue" is not precise enough. "We closed $420K in new ARR vs $680K target — a $260K miss driven primarily by three deals that slipped to Q4 and one deal that was lost to a competitor" is precise.
-
-### Step 2: The 5 Whys — Done Properly
-
-The goal: get from **what happened** (the symptom) to **why it happened** (the root cause).
-
-Standard bad 5 Whys:
-- Why did we miss revenue? Because deals slipped.
-- Why did deals slip? Because the sales cycle was longer than expected.
-- Why? Because the customer buying process is complex.
-- Why? Because we're selling to enterprise.
-- Why? That's just how enterprise sales works.
-
-→ Conclusion: Nothing to do. It's just enterprise.
-
-Real 5 Whys:
-- Why did we miss revenue? Three deals slipped out of quarter.
-- Why did those deals slip? None of them had identified a champion with budget authority.
-- Why did we progress deals without a champion? Our qualification criteria didn't require it.
-- Why didn't our qualification criteria require it? When we built the criteria 8 months ago, we were in SMB, not enterprise.
-- Why haven't we updated qualification criteria as ICP shifted? No owner, no process for criteria review.
-
-→ Root cause: Qualification criteria outdated, no owner, no review process.
-→ Fix: Update criteria, assign owner, add quarterly review.
-
-**The test for a good root cause:** Could you prevent recurrence with a specific, concrete change? If yes, you've found something real.
-
-### Step 3: Distinguish Contributing Factors from Root Cause
-
-Most events have multiple contributing factors. Not all are root causes.
-
-**Contributing factor:** Made it worse, but isn't the core reason. If removed, the outcome might have been different — but the same class of problem would recur.
-
-**Root cause:** The fundamental condition that made the outcome probable. Fix this, and this class of problem doesn't recur.
-
-Example — failed hire:
-- Contributing factors: rushed process, reference checks skipped, team under pressure to staff up
-- Root cause: No defined competency framework, so interview process varied by who happened to conduct interviews
-
-**The distinction matters.** If you address only contributing factors, you'll have a different-looking but structurally identical failure next time.
-
-### Step 4: Identify the Warning Signs That Were Ignored
-
-Every failure has precursors. In hindsight, they're obvious. The value of this step is making them obvious prospectively.
-
-Ask:
-- At what point was the negative outcome predictable?
-- What signals were visible at that point?
-- Who saw them? What happened when they raised them?
-- Why weren't they acted on?
-
-**Common patterns:**
-- Signal was raised but dismissed by a senior person
-- Signal wasn't raised because nobody felt safe saying it
-- Signal was seen but no one had clear ownership to act on it
-- Data was available but nobody was looking at it
-- The team was too optimistic to take negative signals seriously
-
-This step is particularly important for systemic issues — "we didn't feel safe raising the concern" is a much deeper root cause than "the deal qualification was off."
-
-### Step 5: Distinguish What Was in Control vs. Out of Control
-
-Some failures happen despite correct decisions. Some happen because of incorrect decisions. Knowing the difference prevents both overcorrection and undercorrection.
-
-- **In control:** Process, criteria, team capability, resource allocation, decisions made
-- **Out of control:** Market conditions, customer decisions, competitor actions, macro events
-
-For things out of control: what can be done to be more resilient to similar events?
-For things in control: what specifically needs to change?
-
-**Warning:** "It was outside our control" is sometimes used to avoid accountability. Be rigorous.
-
-### Step 6: Build the Change Register
-
-Every post-mortem ends with a change register — specific commitments, owned and dated.
-
-**Bad action items:**
-- "We'll improve our qualification process"
-- "Communication will be better"
-- "We'll be more rigorous about forecasting"
-
-**Good action items:**
-- "Ravi owns rewriting qualification criteria by March 15 to include champion identification as hard requirement. New criteria reviewed in weekly sales standup starting March 22."
-- "By March 10, Elena adds deal-slippage risk flag to CRM for any open opportunity >60 days without a product demo"
-- "Maria runs a 30-min retrospective with enterprise sales team every 6 weeks starting April 1, reviews win/loss data"
-
-**For each action:**
-- What exactly is changing?
-- Who owns it?
-- By when?
-- How will you verify it worked?
-
-### Step 7: Verification Date
-
-The most commonly skipped step. Post-mortems are useless if nobody checks whether the changes actually happened and actually worked.
-
-Set a verification date: "We'll review whether qualification criteria have been updated and whether deal slippage rate has improved at the June board meeting."
-
-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]
-[Date]: ...
-
-5 WHYS
-1. [Why did X happen?] → Because [Y]
-2. [Why did Y happen?] → Because [Z]
-3. [Why did Z happen?] → Because [A]
-4. [Why did A happen?] → Because [B]
-5. [Why did B happen?] → Because [ROOT CAUSE]
-
-ROOT CAUSE: [One clear sentence]
-
-CONTRIBUTING FACTORS
-• [Factor] — how it contributed
-• [Factor] — how it contributed
-
-WARNING SIGNS MISSED
-• [Signal visible at what date] — why it wasn't acted on
-
-WHAT WAS IN CONTROL: [List]
-WHAT WASN'T: [List]
-
-CHANGE REGISTER
-| Action | Owner | Due Date | Verification |
-|--------|-------|----------|-------------|
-| [Specific change] | [Name] | [Date] | [How to verify] |
-
-VERIFICATION DATE: [Date of check-in]
-```
-
----
-
-## The Tone of Good Post-Mortems
-
-Blame is cheap. Understanding is hard.
-
-The goal isn't to establish that someone made a mistake. The goal is to understand why the system produced that outcome — so the system can be improved.
-
-"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 first version fires or shames someone. The second version builds a more resilient organization.
-
-Both might be true simultaneously. The distinction is: which one actually prevents recurrence?

package/skills/jarvis/engineering-team/docs/skills/c-level-advisor/executive-mentor-stress-test.md

@@ -1,215 +0,0 @@
----
-title: "/em:stress-test — Business Assumption Stress Testing — Agent Skill for Executives"
-description: "/em -stress-test — Business Assumption Stress Testing. Agent skill for Claude Code, Codex CLI, Gemini CLI, OpenClaw."
----
-
-# /em:stress-test — Business Assumption Stress Testing
-
-<div class="page-meta" markdown>
-<span class="meta-badge">:material-account-tie: C-Level Advisory</span>
-<span class="meta-badge">:material-identifier: `stress-test`</span>
-<span class="meta-badge">:material-github: <a href="https://github.com/alirezarezvani/claude-skills/tree/main/c-level-advisor/executive-mentor/skills/stress-test/SKILL.md">Source</a></span>
-</div>
-
-<div class="install-banner" markdown>
-<span class="install-label">Install:</span> <code>claude /plugin install c-level-skills</code>
-</div>
-
-
-**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]
-```