Use when defining stopping rules for projects, avoiding sunk cost fallacy, setting objective exit criteria, deciding whether to continue/pivot/kill initiatives, or when users mention kill criteria, exit ramps, stopping rules, go/no-go decisions, project termination, sunk costs, or need disciplined decision-making about when to quit.
Provides frameworks for defining objective kill criteria, exit ramps, and stopping rules to avoid sunk cost fallacy. Use when users need to decide whether to continue, pivot, or kill projects, or mention kill criteria, exit ramps, stopping rules, or disciplined decision-making about when to quit.
/plugin marketplace add lyndonkl/claude/plugin install lyndonkl-thinking-frameworks-skills@lyndonkl/claudeThis skill inherits all available tools. When active, it can use any tool Claude has access to.
resources/evaluators/rubric_kill_criteria_exit_ramps.jsonresources/methodology.mdresources/template.mdKill criteria are pre-defined, objective conditions that trigger stopping a project, product, or initiative. Exit ramps are specific decision points where you evaluate whether to continue, pivot, or kill. This skill helps avoid sunk cost fallacy and opportunity cost by establishing discipline around quitting.
Use this skill when:
The hardest decision is often knowing when to quit. Kill criteria remove emotion and politics from stopping decisions.
When: Starting new project, experiment, or product
Process: (1) Define success metrics ("10% conversion"), (2) Set time horizon ("6 months"), (3) Establish kill criteria ("If <5% after 6 months, kill"), (4) Assign decision rights (specific person), (5) Document formally (signed PRD)
Example: New feature — Success: 20% adoption in 3 months, Kill: <10% adoption, Decision: Product VP makes call
When: Multi-stage projects with increasing investment
Structure: Stage 1 (cheap, concept) → Go/No-Go → Stage 2 (moderate, MVP) → Go/No-Go → Stage 3 (expensive, launch) → Go/No-Go
Example: Gate 1 (4wk, $10k): 15+ customer interviews show interest → GO. Gate 2 (3mo, $50k): 40% weekly active (got 25%) → NO-GO, kill
Benefit: Small investments first, kill before expensive stages
When: Ongoing projects with uncertain outcomes
Common triggers: Time-based ("not profitable by Month 18"), Metric-based ("churn >8% for 2 months"), Market-based ("competitor launches"), Resource-based ("budget overrun >30%"), Opportunity-based ("better option emerges")
Example: SaaS — Trigger 1: MRR growth <10%/mo for 3 months → Evaluate. Trigger 2: CAC payback >24mo → Evaluate. Trigger 3: Competitor raises >$50M → Evaluate
Note: Triggers prompt evaluation, not automatic kill
When: Project isn't working as planned — should you pivot or kill?
Framework:
Pivot if:
Kill if:
Example: Mobile app with low engagement
Decision: Pivot if hypothesis valid but execution wrong. Kill if hypothesis invalid.
When: Managing portfolio of projects, need to kill some to focus
Process:
Example: Company with 10 projects, capacity for 7
Principle: Opportunity cost matters more than sunk cost. "Almost done" doesn't justify continuing if better alternatives exist.
When: Team resists killing project due to past investment
Technique: Pre-mortem inversion
Example: Failed enterprise sales push
Trap: "We've invested so much, we can't quit now" → This is sunk cost fallacy Escape: Only future costs and benefits matter. Past is gone.
Use this structured approach when defining or applying kill criteria:
□ Step 1: Define success metrics and time horizon
□ Step 2: Establish objective kill criteria
□ Step 3: Assign decision rights and governance
□ Step 4: Set milestone gates or trigger points
□ Step 5: Document formally (signed agreement)
□ Step 6: Monitor metrics regularly
□ Step 7: Evaluate at gates/triggers
□ Step 8: Execute kill decision (if triggered)
Step 1: Define success metrics and time horizon (details) Specify quantifiable success criteria (e.g., "20% conversion") and evaluation period (e.g., "6 months post-launch").
Step 2: Establish objective kill criteria (details) Set numeric thresholds that trigger stop decision (e.g., "If <10% conversion after 6 months"). Make criteria objective, not subjective.
Step 3: Assign decision rights and governance (details) Name specific person who makes kill decision. Define escalation process. Avoid "team consensus" (leads to paralysis).
Step 4: Set milestone gates or trigger points (details) For multi-stage projects: define go/no-go gates. For ongoing projects: define triggers that prompt evaluation.
Step 5: Document formally (details) Write kill criteria in PRD, project charter, or investment memo. Get stakeholders to sign/approve before launch (prevents moving goalposts).
Step 6: Monitor metrics regularly (details) Track metrics weekly/monthly. Dashboard with kill criteria thresholds clearly marked. Automate alerts when approaching thresholds.
Step 7: Evaluate at gates/triggers (details) When gate or trigger hit, conduct formal evaluation. Use pre-mortem inversion: "Would we start this today?" Decide: continue, pivot, or kill.
Step 8: Execute kill decision (details) If kill triggered: communicate decision, wind down project, reallocate resources, conduct postmortem. Execute quickly (avoid zombie projects).
Danger: Defining kill criteria after project starts leads to moving goalposts
Guardrail: Write kill criteria in initial project document, before emotional/financial investment. Get stakeholder sign-off.
Red flag: "We'll figure out when to stop as we go" — this leads to sunk cost trap
Danger: Subjective criteria ("team feels it's not working") are easy to ignore
Guardrail: Use quantifiable metrics (numbers, dates, milestones). "5% conversion" not "low adoption". "6 months" not "reasonable time".
Test: Could two people independently evaluate criteria and reach same conclusion? If not, too subjective.
Danger: "Team decides" or "we'll discuss" leads to paralysis (everyone has sunk cost)
Guardrail: Name specific person who makes kill decision. Define what data they need. Escalation path for overrides.
Example: "Product VP makes kill decision based on 6-month metrics. Can be overridden only by CEO with written justification."
Danger: When kill criteria approached, team lowers bar or extends timeline
Guardrail: Kill criteria are fixed at launch. Changes require formal process (written justification, senior approval, new document).
Red flag: "Let's give it another 3 months" when 6-month criteria not met
Danger: "We've invested $2M, can't stop now" — sunk cost fallacy
Guardrail: Use pre-mortem inversion: "If starting today with $0 invested, would we do this?" Only future matters.
Principle: Past costs are gone. Only question: "Is future investment better here or elsewhere?"
Danger: Projects that should be killed linger, draining resources ("zombie projects")
Guardrail: Kill decision → immediate wind-down. Announce within 1 week, reallocate team within 1 month.
Red flag: Project in "wind-down" for >3 months — this is zombie mode, not killing
Danger: Continuing project because "almost done" even if better opportunities exist
Guardrail: Portfolio thinking. Ask: "Is this the best use of these resources?" If not, kill even if 90% done.
Principle: Opportunity cost of not pursuing better option often exceeds benefit of finishing current project
Danger: Kill decisions seen as "failure", teams avoid them
Guardrail: Normalize killing projects. Celebrate disciplined stopping. Postmortem focuses on learning, not blame.
Culture: "We killed 3 projects this quarter" = good (freed resources for winners), not bad (failures)
Before launching project, answer:
| Gate | Investment | Timeline | Success Criteria | Decision |
|---|---|---|---|---|
| Gate 1: Concept | $10k | 4 weeks | 15+ customer interviews showing strong interest | GO / NO-GO |
| Gate 2: MVP | $50k | 3 months | 40% weekly active users (50 beta users) | GO / NO-GO |
| Gate 3: Launch | $200k | 6 months | 10% conversion, <$100 CAC | GO / NO-GO |
| Factor | Pivot | Kill |
|---|---|---|
| Customer pain | Real but solution wrong | No pain, nice-to-have |
| Market size | Large enough | Too small |
| Learning rate | High (new insights) | Low (stuck) |
| Burn rate | Sustainable | Too high |
| Team belief | Believes with changes | Doesn't believe |
| Opportunity cost | Pivot is best option | Better options exist |
Context: SaaS launched "Advanced Analytics", kill criteria: <15% adoption after 3 months
Result: 12% adoption → Killed feature, reallocated 2 engineers to core. Saved 6 months maintenance.
Context: B2B SaaS, pivot trigger: <10 customers by Month 12
Result: 7 customers → Pivoted to self-serve SMB. Hit 200 SMB customers in 6 months, 4× faster growth.
Context: 8 R&D projects, capacity for 5. Ranked by EV/Cost: A(3.5), B(2.8), C(2.5), D(2.1), E(1.8), F(1.5), G(1.2), H(0.9)
Decision: Killed F, G, H despite F being "80% done". Top 3 projects shipped 4 months earlier.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.