Avoid Feature Creep
Keep MVP and AI product scope tight by rejecting nice-to-haves while planning features and reviewing what to ship next.
Overview
avoid-feature-creep is an agent skill most often used in Validate (also Build and Idea) that prevents scope expansion so MVPs and AI products stay shippable.
Install
npx skills add https://github.com/waynesutton/convexskills --skill avoid-feature-creepWhat is this skill?
- Guards against expanding scope while planning software, apps, and AI-powered products
- Explicit triggers for MVP planning, feature lists, and scope reviews
- Pairs with Convex-style indie shipping where backend scope can balloon quickly
- Decision-oriented framing for what to defer versus what blocks launch
- Use during active build checkpoints when new ideas threaten the current milestone
Adoption & trust: 1.1k installs on skills.sh; 402 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your MVP or AI product keeps absorbing new features and you risk never shipping a focused first version.
Who is it for?
Indie founders and Convex builders doing MVP scoping, sprint planning, or mid-build feature reviews.
Skip if: Teams that already have a frozen spec and only need implementation—or situations where exploratory brainstorming without constraints is the goal.
When should I use this skill?
Planning features, reviewing scope, building MVPs, or managing product scope for software, apps, and AI-powered products.
What do I get? / Deliverables
You leave scope reviews with explicit deferrals and a smaller must-ship set aligned to the current milestone.
- Prioritized must-ship versus deferred feature decisions
- Documented scope boundaries for the active milestone
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Feature-creep decisions bite hardest before full build commitment, so Validate/scope is the canonical shelf for cutting scope. The skill targets scoping, MVP boundaries, and feature review—not implementation details or growth metrics.
Where it fits
Trim a launch checklist down to the smallest feature set that proves demand.
Reject parallel AI features mid-sprint so the current Convex milestone still ships on time.
Compare two product directions and defer the broader vision until the first wedge is live.
How it compares
A scope-discipline workflow skill—not a feature generator or a technical architecture template.
Common Questions / FAQ
Who is avoid-feature-creep for?
Solo builders and small teams shipping software or AI products who need a lightweight guardrail against expanding scope during planning and build.
When should I use avoid-feature-creep?
In Validate when defining MVP scope, in Build/pm when reviewing a growing backlog, and in Idea when competing feature ideas threaten a single clear bet.
Is avoid-feature-creep safe to install?
It is process guidance with no inherent runtime risk; still review the skill text and Security Audits panel on this Prism page before installing any skill from the repo.
SKILL.md
READMESKILL.md - Avoid Feature Creep
interface: icon_small: "./assets/small-logo.svg" icon_large: "./assets/large-logo.png" <svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg"> <g clip-path="url(#clip0_3_23)"> <g clip-path="url(#clip1_3_23)"> <path d="M10.0643 12.5735C12.3769 12.3166 14.5572 11.0843 15.7577 9.02756C15.1892 14.1148 9.62646 17.3302 5.08583 15.356C4.66743 15.1746 4.30728 14.8728 4.06013 14.4848C3.03973 12.8825 2.7043 10.8437 3.18626 8.99344C4.56327 11.37 7.3632 12.8267 10.0643 12.5735Z" fill="#F3B01C"/> <path d="M3.1018 7.50072C2.16436 9.66714 2.12376 12.2034 3.27303 14.2907C-0.771507 11.2479 -0.72737 4.7362 3.2236 1.72378C3.58904 1.44535 4.02333 1.2801 4.47881 1.25494C6.3519 1.15614 8.25501 1.88006 9.58963 3.22909C6.87799 3.25604 4.23695 4.99308 3.1018 7.50072Z" fill="#8D2676"/> <path d="M10.8974 3.89562C9.52924 1.98794 7.38779 0.68921 5.04156 0.649695C9.57686 -1.40888 15.1555 1.92867 15.7629 6.86314C15.8194 7.32119 15.7452 7.78824 15.5421 8.20138C14.6948 9.92223 13.1236 11.2569 11.2876 11.7508C12.6328 9.25579 12.4668 6.20748 10.8974 3.89562Z" fill="#EE342F"/> </g> </g> <defs> <clipPath id="clip0_3_23"> <rect width="16" height="16" fill="white"/> </clipPath> <clipPath id="clip1_3_23"> <rect width="16" height="16" fill="white"/> </clipPath> </defs> </svg> --- name: avoid-feature-creep description: Prevent feature creep when building software, apps, and AI-powered products. Use this skill when planning features, reviewing scope, building MVPs, managing backlogs, or when a user says "just one more feature." Helps developers and AI agents stay focused, ship faster, and avoid bloated products. --- # Avoid Feature Creep for Agents Stop building features nobody needs. This skill helps you ship products that solve real problems without drowning in unnecessary complexity. Feature creep kills products. It delays launches, burns budgets, exhausts teams, and creates software nobody wants to use. The most successful products do fewer things well. ## The Core Problem Feature creep is the gradual accumulation of features beyond what your product needs to deliver value. It happens slowly, then all at once. **Warning signs you're in trouble:** - Release scope keeps growing without clear user value - You're copying competitor features without validating need - Stakeholders keep adding "just one more thing" - The codebase is getting harder to maintain - Users complain the product is confusing or bloated - You haven't shipped in months **What it costs:** - Development time on features 80% of users never touch - Increased bug surface area - Team burnout and context switching - Delayed time-to-market - Technical debt that compounds - User confusion and abandonment ## Decision Framework Before adding ANY feature, run through this checklist: ``` 1. VALIDATE THE PROBLEM □ Does this solve a real, validated user pain point? □ Have we talked to actual users about this need? □ What evidence supports building this? 2. CHECK ALIGNMENT □ Does this support the core product vision? □ Would this delay our current release? □ What are we NOT building if we build this? 3. MEASURE IMPACT □ How will we know if this feature succeeds? □ What KPIs will change? □ Can we quantify the value (time saved, revenue, retention)? 4. ASSESS COMPLEXITY □ What's the true cost (build + test + maintain + document)? □ Does this add dependencies or technical debt? □ Can we ship a simpler version first? 5. FINAL GUT CHECK □ Would we delay launch by a month for this feature? □ Is this a differentiator or just table stakes? □ Would removing this harm the core experience? ``` If you can't answer YES to questions 1-3 with evidence, do not build the feature. ## Scope Management Rules **Rule 1: Define and Defend Your MVP** Write down exactly what "done" means before you start. Document what you're NOT building. Reference this constantly. ```markdown ## MVP Scope Document Template ### Core Problem [O