Shipped a feature you never asked for
交付了一个你从没要过的功能
A bug-fix PR also adds a metrics middleware, a feature-flag client, a settings page or a CLI option.
Applies to: Claude Code · Cursor · Codex · Copilot agent
Symptom
New behavior in the diff that no line of the request asks for. It may work fine, but now you own it, test it and maintain it.
Why it happens
Agents generalize and anticipate needs. agent-review's canonical AR028 example is a "fix login bug" PR that also adds metrics middleware and a feature-flag client. The dev.to diff-budget author fixed it with a parking lot, a file where ideas go instead of the diff.
Example
From the agent-review taxonomy (AR028).
textPR title: "Fix login bug"
+ src/middleware/metrics.ts (new)
+ src/lib/featureFlags.ts (new)
src/auth/login.ts (the actual 3-line fix)
Copy-paste fixes
Pick the files for the agents you use. Snippets are in English so they work in any repo.
Claude Code: add to CLAUDE.md
CLAUDE.md## Build only what was asked
- Implement exactly the requested behavior. No extra options, endpoints, settings, flags,
middleware, telemetry or UI that the request doesn't mention.
- Good ideas go to FOLLOWUPS.md with a one-line rationale, not into this change.
- In your summary, map every new behavior to the request line it serves.
Codex, Copilot coding agent and others: add to AGENTS.md
AGENTS.md## Build only what was asked
- Implement exactly the requested behavior. No extra options, endpoints, settings, flags,
middleware, telemetry or UI that the request doesn't mention.
- Good ideas go to FOLLOWUPS.md with a one-line rationale, not into this change.
- In your summary, map every new behavior to the request line it serves.
Cursor: project rule
.cursor/rules/unrequested-feature.mdc---
description: "AgentFails: Shipped a feature you never asked for"
alwaysApply: true
---
## Build only what was asked
- Implement exactly the requested behavior. No extra options, endpoints, settings, flags,
middleware, telemetry or UI that the request doesn't mention.
- Good ideas go to FOLLOWUPS.md with a one-line rationale, not into this change.
- In your summary, map every new behavior to the request line it serves.
FOLLOWUPS.md parking lot
The parking-lot idea is from the dev.to diff-budget post: blocked ideas get written down, not lost and not shipped.
FOLLOWUPS.md## Parking lot: <task id>
- <file or area>: <what you noticed>. Suggested task: <bug fix | feature | refactor>, <priority>.
Fresh-context review skill (subagent reviews the diff, not the chat)
Follows the habit Anthropic describes in its code-review post: verify first, then have a subagent review the diff with fresh context. Named review-diff to avoid clashing with built-in or popular /code-review skills.
.claude/skills/review-diff/SKILL.md---
name: review-diff
description: Review the current diff with fresh context before a PR. Use after /verify passes.
---
# Review the diff
Start a subagent that has NOT seen this conversation. Give it only:
- the original request (one paragraph, verbatim),
- the output of `git diff origin/main...HEAD`,
- the names of the test/build commands.
Ask it to report, with file:line for each finding:
1. **Wrong feature**: does the diff do what the request asked? Quote the request line each change serves.
2. **Bugs**: logic errors, missing edge cases (empty, null, boundary), unhandled errors,
unawaited promises, invented APIs or packages, swallowed exceptions.
3. **Overreach**: changes no request line needs (refactors, renames, formatting, dependency or
config edits, public API changes, weakened tests).
4. **Evidence gaps**: claims in the PR description that no command output supports.
Then fix real findings, or list them under "Known issues" in the PR. Do not argue with the reviewer
in the PR text; either fix or explain in one line.