avoid-feature-creep

Name: avoid-feature-creep
Author: waynesutton

1.2kinstalls31forks

How to install avoid-feature-creep?

waynesutton/convexskills/avoid-feature-creep

$npx -y skills add waynesutton/convexskills --skill avoid-feature-creep

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Avoid Feature Creep for Agents
2
3	Stop building features nobody needs. This skill helps you ship products that solve real problems without drowning in unnecessary complexity.
4
5	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.
6
7	## The Core Problem
8
9	Feature creep is the gradual accumulation of features beyond what your product needs to deliver value. It happens slowly, then all at once.
10
11	Warning signs you're in trouble:
12	- Release scope keeps growing without clear user value
13	- You're copying competitor features without validating need
14	- Stakeholders keep adding "just one more thing"
15	- The codebase is getting harder to maintain
16	- Users complain the product is confusing or bloated
17	- You haven't shipped in months
18
19	What it costs:
20	- Development time on features 80% of users never touch
21	- Increased bug surface area
22	- Team burnout and context switching
23	- Delayed time-to-market
24	- Technical debt that compounds
25	- User confusion and abandonment
26
27	## Decision Framework
28
29	Before adding ANY feature, run through this checklist:
30
31	```
32	1. VALIDATE THE PROBLEM
33	□ Does this solve a real, validated user pain point?
34	□ Have we talked to actual users about this need?
35	□ What evidence supports building this?
36
37	2. CHECK ALIGNMENT
38	□ Does this support the core product vision?
39	□ Would this delay our current release?
40	□ What are we NOT building if we build this?
41
42	3. MEASURE IMPACT
43	□ How will we know if this feature succeeds?
44	□ What KPIs will change?
45	□ Can we quantify the value (time saved, revenue, retention)?
46
47	4. ASSESS COMPLEXITY
48	□ What's the true cost (build + test + maintain + document)?
49	□ Does this add dependencies or technical debt?
50	□ Can we ship a simpler version first?
51
52	5. FINAL GUT CHECK
53	□ Would we delay launch by a month for this feature?
54	□ Is this a differentiator or just table stakes?
55	□ Would removing this harm the core experience?
56	```
57
58	If you can't answer YES to questions 1-3 with evidence, do not build the feature.
59
60	## Scope Management Rules
61
62	Rule 1: Define and Defend Your MVP
63
64	Write down exactly what "done" means before you start. Document what you're NOT building. Reference this constantly.
65
66	```markdown
67	## MVP Scope Document Template
68
69	### Core Problem
70	[One sentence describing the user problem]
71
72	### Success Criteria
73	[How we know we've solved it]
74
75	### In Scope (v1)
76	- Feature A: [brief description]
77	- Feature B: [brief description]
78
79	### Explicitly Out of Scope
80	- Feature X: Deferred to v2
81	- Feature Y: Will not build unless [condition]
82	- Feature Z: Not our problem to solve
83
84	### Non-Negotiables
85	- Ship by [date]
86	- Budget: [hours/dollars]
87	- Core user: [specific persona]
88	```
89
90	Rule 2: Use Version Control for Scope
91
92	Treat scope like code. Track changes. Require approval for additions.
93
94	```bash
95	# Create a scope document and track it
96	git add SCOPE.md
97	git commit -m "Initial MVP scope definition"
98
99	# Any scope changes require explicit commits
100	git commit -m "SCOPE CHANGE: Added feature X - approved by [stakeholder] - impact: +2 weeks"
101	```
102
103	Rule 3: The 48-Hour Rule
104
105	When someone requests a new feature, wait 48 hours before adding it to the backlog. Most "urgent" requests feel less urgent after reflection.
106
107	Rule 4: Budget-Based Scoping
108
109	Every feature has a cost. When something new comes in, something else must go out.
110
111	"Yes, we can add that. Which of these three features should we cut to make room?"
112
113	## Saying No
114
115	Saying no to features is a skill. Here are templates:
116
117	To stakeholders:
118	> "That's an interesting idea. Based on our user research, it doesn't solve our core user's top three problems. Let's add it to the v2 consideration list and revisit after we validate the MVP."
119
120	To executives:
121	> "I understand the value this could bring. If we add this, we'll delay launch by [X weeks] and deprioritize [Y feature]. Here are the trade-offs - which path should we take?"
122
123	To users:
124	> "Thanks for the feedback. We're focused on [core problem] right now. I've logged this for future consideration. Can you tell me more about why this would be valuable?"
125
126	To yourself:
127	> "Is this scratching my own itch or solving a real user problem? Would I bet the release date on this?"
128
129	To AI agents (Claude, Opus, Codex, Ralph, Cursor):
130	> "Stop. Before we add this feature, answer: Does this solve the core user problem we defined at the start of this session? If not, add it to a DEFERRED.md file and stay focused on the current scope."
131
132	When working with AI coding agents:
133	- State your scope constraints at the start of every session

People who liked this also viewed

6 picks

Type

avoid-feature-creep

1.2kinstalls31forks

View on GitHub

How to install avoid-feature-creep?

waynesutton/convexskills/avoid-feature-creep

$npx -y skills add waynesutton/convexskills --skill avoid-feature-creep

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Avoid Feature Creep for Agents
2
3	Stop building features nobody needs. This skill helps you ship products that solve real problems without drowning in unnecessary complexity.
4
5	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.
6
7	## The Core Problem
8
9	Feature creep is the gradual accumulation of features beyond what your product needs to deliver value. It happens slowly, then all at once.
10
11	Warning signs you're in trouble:
12	- Release scope keeps growing without clear user value
13	- You're copying competitor features without validating need
14	- Stakeholders keep adding "just one more thing"
15	- The codebase is getting harder to maintain
16	- Users complain the product is confusing or bloated
17	- You haven't shipped in months
18
19	What it costs:
20	- Development time on features 80% of users never touch
21	- Increased bug surface area
22	- Team burnout and context switching
23	- Delayed time-to-market
24	- Technical debt that compounds
25	- User confusion and abandonment
26
27	## Decision Framework
28
29	Before adding ANY feature, run through this checklist:
30
31	```
32	1. VALIDATE THE PROBLEM
33	□ Does this solve a real, validated user pain point?
34	□ Have we talked to actual users about this need?
35	□ What evidence supports building this?
36
37	2. CHECK ALIGNMENT
38	□ Does this support the core product vision?
39	□ Would this delay our current release?
40	□ What are we NOT building if we build this?
41
42	3. MEASURE IMPACT
43	□ How will we know if this feature succeeds?
44	□ What KPIs will change?
45	□ Can we quantify the value (time saved, revenue, retention)?
46
47	4. ASSESS COMPLEXITY
48	□ What's the true cost (build + test + maintain + document)?
49	□ Does this add dependencies or technical debt?
50	□ Can we ship a simpler version first?
51
52	5. FINAL GUT CHECK
53	□ Would we delay launch by a month for this feature?
54	□ Is this a differentiator or just table stakes?
55	□ Would removing this harm the core experience?
56	```
57
58	If you can't answer YES to questions 1-3 with evidence, do not build the feature.
59
60	## Scope Management Rules
61
62	Rule 1: Define and Defend Your MVP
63
64	Write down exactly what "done" means before you start. Document what you're NOT building. Reference this constantly.
65
66	```markdown
67	## MVP Scope Document Template
68
69	### Core Problem
70	[One sentence describing the user problem]
71
72	### Success Criteria
73	[How we know we've solved it]
74
75	### In Scope (v1)
76	- Feature A: [brief description]
77	- Feature B: [brief description]
78
79	### Explicitly Out of Scope
80	- Feature X: Deferred to v2
81	- Feature Y: Will not build unless [condition]
82	- Feature Z: Not our problem to solve
83
84	### Non-Negotiables
85	- Ship by [date]
86	- Budget: [hours/dollars]
87	- Core user: [specific persona]
88	```
89
90	Rule 2: Use Version Control for Scope
91
92	Treat scope like code. Track changes. Require approval for additions.
93
94	```bash
95	# Create a scope document and track it
96	git add SCOPE.md
97	git commit -m "Initial MVP scope definition"
98
99	# Any scope changes require explicit commits
100	git commit -m "SCOPE CHANGE: Added feature X - approved by [stakeholder] - impact: +2 weeks"
101	```
102
103	Rule 3: The 48-Hour Rule
104
105	When someone requests a new feature, wait 48 hours before adding it to the backlog. Most "urgent" requests feel less urgent after reflection.
106
107	Rule 4: Budget-Based Scoping
108
109	Every feature has a cost. When something new comes in, something else must go out.
110
111	"Yes, we can add that. Which of these three features should we cut to make room?"
112
113	## Saying No
114
115	Saying no to features is a skill. Here are templates:
116
117	To stakeholders:
118	> "That's an interesting idea. Based on our user research, it doesn't solve our core user's top three problems. Let's add it to the v2 consideration list and revisit after we validate the MVP."
119
120	To executives:
121	> "I understand the value this could bring. If we add this, we'll delay launch by [X weeks] and deprioritize [Y feature]. Here are the trade-offs - which path should we take?"
122
123	To users:
124	> "Thanks for the feedback. We're focused on [core problem] right now. I've logged this for future consideration. Can you tell me more about why this would be valuable?"
125
126	To yourself:
127	> "Is this scratching my own itch or solving a real user problem? Would I bet the release date on this?"
128
129	To AI agents (Claude, Opus, Codex, Ralph, Cursor):
130	> "Stop. Before we add this feature, answer: Does this solve the core user problem we defined at the start of this session? If not, add it to a DEFERRED.md file and stay focused on the current scope."
131
132	When working with AI coding agents:
133	- State your scope constraints at the start of every session

People who liked this also viewed

6 picks

Type