30
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill lyndonkl/claude --skill kill-criteria-exit-ramps- SKILL.md13.3 KB
Overview
This skill helps teams define objective stopping rules and exit ramps so projects are evaluated and terminated without emotional bias. It provides patterns, a step-by-step workflow, and guardrails to avoid sunk-cost traps and make disciplined go/pivot/kill decisions. Use it to set measurable thresholds, decision rights, and milestone gates before significant investment.
How this skill works
The skill codifies common patterns: upfront kill criteria, go/no-go gates, trigger-based exits, pivot vs. kill frameworks, and portfolio-level rules. It guides teams to define success metrics, set numeric kill thresholds, assign a single decision owner, document criteria formally, monitor metrics, and execute wind-downs when triggers are met. It emphasizes objective data, pre-mortem inversion, and quick execution to avoid zombie projects.
When to use it
- Defining stopping rules before launching a new project or experiment
- Evaluating an ongoing initiative at a milestone or when metrics lag
- Avoiding the sunk cost fallacy when stakeholders resist killing a project
- Managing a portfolio to reallocate resources to higher-value projects
- Setting go/no-go gates for multi-stage investments
- Deciding whether to continue, pivot, or kill after new insights emerge
Best practices
- Set quantifiable success metrics and a clear time horizon before work begins
- Make kill criteria numeric and objective (percentages, dates, revenue thresholds)
- Assign a named decision maker and an escalation path—avoid consensus-only decisions
- Document criteria in a project charter and require formal approval to change them
- Monitor metrics regularly and automate alerts for approaching thresholds
- Execute kill decisions quickly: wind down, communicate, reallocate, and run a learning-focused postmortem
Example use cases
- New feature experiment: kill if adoption <10% after 3 months; product VP decides
- Stage-gated product development: cheap concept → MVP → launch with go/no-go at each gate
- Ongoing SaaS product: trigger-based checks (MRR growth, churn, CAC payback) prompt evaluation
- Portfolio pruning: rank projects by expected value per cost and kill bottom percentile
- Pre-mortem inversion: ask if you would start this today with $0 invested to overcome sunk-cost bias
FAQ
Treat changes formally: require written justification, senior approval, and an updated documented criterion. Avoid informal extensions that invite bias.
Are triggers automatic kills?
No. Triggers prompt a formal evaluation (continue/pivot/kill). Kill criteria should be objective, but review still follows governance and decision rights.