Challenge
Run a pre-mortem on any plan with /em:challenge so assumptions and dependencies surface before you commit time, money, or reputation.
Overview
Challenge is a journey-wide agent skill that runs pre-mortem plan analysis—usable whenever a solo builder needs to stress-test assumptions before committing resources.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill challengeWhat is this skill?
- Pre-mortem frame: imagine failure 12 months out and work backwards to root causes
- Command entry: /em:challenge with a plan argument for systematic weakness surfacing
- Targets bad assumptions, underestimated complexity, and unexamined external dependencies
- Explicit trigger when feedback is one-sidedly positive or excitement should trigger scrutiny
- Goal is to strengthen the plan for contact with reality, not to kill it by default
- Pre-mortem horizon fixed at 12 months in the documented core technique
Adoption & trust: 1.4k installs on skills.sh; 17.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to commit significant resources to a plan but have not systematically imagined how it could fail twelve months from now.
Who is it for?
Founders and PMs with a written plan who want structured pushback before funding meetings, big hires, or multi-dependency roadmaps.
Skip if: Purely operational firefighting with no plan artifact, or cases where a formal pre-mortem already happened with diverse stakeholders and documented mitigations.
When should I use this skill?
Before significant resource commitment, before presenting to a board or investors, when feedback has been one-sidedly positive, or when there is pressure to move fast and figure it out later.
What do I get? / Deliverables
You get a backward-looking failure narrative that exposes assumptions, dependencies, and execution risks so you can harden the plan before boards, investors, or heavy build spend.
- Structured list of assumed failure reasons and weak points traced from the 12-month pre-mortem
- Actionable plan revisions or validation steps implied by surfaced risks
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Challenge a market-entry thesis before you treat competitor gaps as proven demand.
Pre-mortem a MVP scope doc to catch dependencies you assumed would align on their own.
Stress-test a multi-quarter roadmap right before locking sprint commitments and contractor spend.
Imagine a launch post-mortem as a failure story to surface timing and readiness gaps before go-live.
Challenge a retention or pricing change plan when excitement is high but evidence is thin.
How it compares
Use structured pre-mortem critique instead of only asking the model for encouragement or a generic pros-and-cons list.
Common Questions / FAQ
Who is challenge for?
Solo builders and small teams who own product or company plans and want a repeatable /em:challenge ritual before high-stakes commitments.
When should I use challenge?
Before significant resource commitment (Validate scope), before board or investor decks (Validate or Launch), when entering a big Build bet with external dependencies, or when Ship/Launch timelines feel optimistic under move-fast pressure.
Is challenge safe to install?
It is a planning methodology skill without mandated shell or network calls; review the Security Audits panel on this Prism page like any third-party skill package.
SKILL.md
READMESKILL.md - Challenge
# /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. Overestimated demand. Underestimated complexity. Dependencies nobody questioned. Timing that made sense in a spreadsheet but not in the real world. The pre-mortem technique: **imagine it's 12 months from now and this plan failed spectacularly. Now work backwards. Why?** That's not pessimism. It's how you build something that doesn't collapse. --- ## When to Run a Challenge - Before committing significant resources to a plan - Before presenting to the board or investors - When you notice you're only hearing positive feedback about the plan - When the plan requires multiple external dependencies to align - When there's pressure to move fast and "figure it out later" - When you feel excited about the plan (excitement is a signal to scrutinize harder) --- ## The Challenge Framework ### Step 1: Extract Core Assumptions Before you can test a plan, you need to surface everything it assumes to be true. For each section of the plan, ask: - What has to be true for this to work? - What are we assuming about customer behavior? - What are we assuming about competitor response? - What are we assuming about our own execution capability? - What external factors does this depend on? **Common assumption categories:** - **Market assumptions** — size, growth rate, customer willingness to pay, buying cycle - **Execution assumptions** — team capacity, velocity, no major hires needed - **Customer assumptions** — they have the problem, they know they have it, they'll pay to solve it - **Competitive assumptions** — incumbents won't respond, no new entrant, moat holds - **Financial assumptions** — burn rate, revenue timing, CAC, LTV ratios - **Dependency assumptions** — partner will deliver, API won't change, regulations won't shift ### Step 2: Rate Each Assumption For every assumption extracted, rate it on two dimensions: **Confidence level (how sure are you this is true):** - **High** — verified with data, customer conversations, market research - **Medium** — directionally right but not validated - **Low** — plausible but untested - **Unknown** — we simply don't know **Impact if wrong (what happens if this assumption fails):** - **Critical** — plan fails entirely - **High** — major delay or cost overrun - **Medium** — significant rework required - **Low** — manageable adjustment ### Step 3: Map Vulnerabilities The matrix of Low/Unknown confidence × Critical/High impact = your highest-risk assumptions. **Vulnerability = Low confidence + High impact** These are not problems to ignore. They're the bets you're making. The question is: are you making them consciously? ### Step 4: Find the Dependency Chain Many plans fail not because any single assumption is wrong, but because multiple assumptions have to be right simultaneously. Map the chain: - Does assumption B depend on assumption A being true first? - If the first thing goes wrong, how many downstream things break? - What's the critical path? What has zero slack? ### Step 5: Test the Reversibility For each critical vulnerability: if this assumption turns out to be wrong at month 3, what do you do? - Can you pivot? - Can you cut scope? - Is money already spent? - Are commitments already made? The less reversible, the more rigorously you need to