Skip to main content
skill CX Codex

avoid-feature-creep — Claude Code skill: how to install

Keeps coding agent diffs strictly scoped to the user request. It flags unprompted refactors or extra parameters and moves them to a suggestions list.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add waynesutton/builder-skills --skill avoid-feature-creep -a claude-code
Open on GitHub

What avoid-feature-creep does

The skill enforces a clear rule: if a line in the diff cannot be justified by the original prompt, it does not belong in the diff. Coding agents often try to improve adjacent code or generalize logic on their own. Scope creep stops immediately.

Instead of discarding good ideas, the agent collects them during the run. It lists them under a Suggestions heading in the final summary or inside an Out of scope section in a PRD. Unasked code costs review time and invites bugs, which makes isolating extras from the diff a necessary safeguard.

The skill includes a checklist and signals to watch for. Common triggers include "while we are here" reasoning, extra config options, and error handling for edge cases nobody encountered. The user makes the call.

What it helps with

  • prevent coding agents from bloating diffs with unrequested edits
  • move adjacent refactors and extra flags into a suggestions list
  • keep PRD documents aligned with their initial problem statement
  • deliver the smallest workable patch that answers the task

Example prompts for the agent

  • Just do what I asked and put any extra ideas under Suggestions.
  • Add the deletedAt field to tasks and leave out the mutations for now.
  • Review this PRD against avoid-feature-creep and move extras to Out of scope.

How to install avoid-feature-creep

1Skills CLI (Vercel)

npx skills add waynesutton/builder-skills --skill avoid-feature-creep -a claude-code

2Manually: put the files in place

~/.claude/skills/avoid-feature-creep/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/avoid-feature-creep/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about avoid-feature-creep

How do I install avoid-feature-creep in Claude Code?

Run npx skills add waynesutton/builder-skills --skill avoid-feature-creep -a claude-code. You can also place the skill file directly at ~/.claude/skills/avoid-feature-creep/SKILL.md.

What does the avoid-feature-creep skill do?

It confines agent edits strictly to what you requested. Any side refactor, unused parameter, or speculative edge case is moved to a suggestions list instead of the diff.

Where do deferred changes go?

The agent appends them under a Suggestions heading in chat or the PR summary, or under Out of scope in a PRD document.

Source text

SKILL.md · Apache-2.0
---
name: avoid-feature-creep
description: Keeps a change scoped to what was asked. Flags extra features, refactors, and 'while we are here' edits, and moves them to a suggestions list instead of the diff. Use when a request is small and the agent is about to expand it, when a PRD grows beyond its problem statement, or when the user says 'just do what I asked'.
---

# Avoid feature creep

The request sets the scope. Everything the diff contains should trace back to a sentence in the ask. Anything else is a suggestion, not a change.

## The core rule

Build what was asked. Not what would be nice, not what a senior engineer would also do, not what the codebase "should" have. If a line of the diff cannot be justified by the request, it does not belong in the diff.

This applies to product scope and to code scope. A PRD that grows past its problem statement has the same disease as a bug fix that ships with a refactor.

## Signals that creep is starting

Stop when you notice any of these:

- "While we're here" or "might as well" appears in your reasoning
- Adding a config option, flag, or parameter for a case nobody asked about
- Refactoring code adjacent to the change because it looked untidy
- Adding a second feature to make the first one feel complete
- Adding error handling for edge cases the user has never hit
- Adding tests, types, or docs for code outside the change
- Generalizing a one off into a reusable abstraction
- Copying a competitor feature without a stated user need
- A PRD section titled "Future" or "Nice to have" that keeps getting longer
- The change touches a file the request never implied

Each of these might be a good idea. None of them are in scope unless the user says so.

## What to do instead

1. Finish the ask. Ship the smallest change that fully answers the request.
2. Collect the extras as you go. Do not act on them.
3. Put them in one place at the end:
   - In a chat or PR summary, under a `Suggestions` heading, one line each
   - In a PRD, under `Out of scope` with a one line reason
   - In a repo with a `prds/` folder, append to the relevant PRD's `Out of scope` section
4. Let the user pick. "The agent thought so" is not approval.

Suggestions are cheap to write and free to ignore. Unrequested code costs review time, adds bugs, and blurs what the change was for.

## Stakeholders, including agents

Every feature request has a source: a PM, an exec, a user, a developer scratching an itch, or an AI coding agent. Treat them all the same way. Log the request, weigh it against the current scope, and defer it unless it solves the problem the work was started for.

AI agents are stakeholders now. They have opinions and they push. Common agent driven creep:

- "Let me also add error handling for edge cases you haven't hit yet"
- "This would be cleaner with a refactor"
- "You should probably add tests for this"
- "I added types for these additional scenarios"

If you are the agent, catch yourself doing this and move it to the suggestions list. If you are working with an agent, state the scope at the start of the session and treat its extras like any other stakeholder ask.

Before adding anything, ask:

- Does this solve the problem the request named?
- What is the smallest version that works?
- What happens if we never build it?

If the first answer is no, it goes in suggestions.

## Before and after

Request: "Add a `deletedAt` field to tasks and hide deleted tasks from the list query."

Before, the creeping version:

- Added `deletedAt` to the schema
- Added a `by_user_and_deleted` index
- Rewrote `list` to use the index
- Added `softDelete`, `restore`, and `purgeDeleted` mutations
- Added a cron to purge after 30 days
- Renamed `list` to `listActive` and updated three call sites
- Added a `showDeleted` argument "for the admin view later"

After, the scoped version:

- Added `deletedAt: v.optional(v.number())` to the schema
- Added the index and pointed `list` at it so deleted rows never load

Summary sent with the change:

```
Done: deletedAt field and list query now skips deleted tasks.

Suggestions
- A softDelete mutation to set deletedAt (nothing sets it yet)
- A restore mutation
- A cron to purge rows older than 30 days
- An admin flag on list to include deleted rows
```

Two lines of diff answered the request. Four lines of suggestions preserved every idea. The user decides what happens next.

## PRDs

A PRD earns each section by pointing back to its problem statement. When a PRD grows:

- Reread the problem statement. Cut anything that does not serve it.
- Move cut items to `Out of scope` with one reason each.
- If the cut items form a coherent feature, that is a second PRD, not a bigger first one.

## Checklist

- [ ] Every changed file is implied by the request
- [ ] No new config options, flags, or parameters the request did not ask for
- [ ] No refactors of adjacent code
- [ ] No second feature added to round out the first
- [ ] No tests, types, or docs added for code outside the change
- [ ] Extras are listed under `Suggestions` in the summary or `Out of scope` in the PRD
- [ ] The summary says what was done in one line before the suggestions
- [ ] If the user said "just do what I asked", the diff contains only that

© waynesutton · Apache-2.0 · waynesutton/builder-skills

Similar skills

All skills for Agent setup: memory, context, orchestration →

From the same set14

convex-cron-jobs Sets up recurring jobs in convex/crons.ts and delayed execution with ctx.scheduler. Helps batch heavy mutations and debug failing queues in Convex. CX Codex +1 2,800installs convex-security-check Checks a Convex backend before merge for exposed functions, missing auth, weak validation, ownership gaps, and secrets in code. CX Codex +1 2,700installs convex-http-actions Adds HTTP endpoints in convex/http.ts: webhook receivers with signature checks, REST routes, CORS, streaming and file uploads. CX Codex +1 2,700installs convex-migrations Walks a live Convex schema change through six steps: optional field, batched backfill, validator flip, cleanup. Useful when npx convex dev rejects existing documents. CX Codex +1 2,600installs convex-file-storage Handles Convex file storage operations: upload URLs, blob persistence in actions, and serving with getUrl. Useful when building user uploads or fetching external assets. CX Codex +1 2,600installs convex-agents Guides agent setup with the @convex-dev/agent component. Useful when adding chat threads, tool calling for queries and mutations, or RAG to a Convex app. CX Codex +1 1,500installs convex-security-audit A skill that walks through a Convex app's security and writes up what it finds. Useful before a launch or after an incident. CX Codex +1 1,500installs convex-component-authoring Walks the agent through a reusable Convex component: its own schema, functions and a typed client wrapper. Handy when a feature moves into a package. CX Codex +1 1,200installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor