Wrong feature

A requirement you cancelled comes back

你已经取消的需求又回来了

You changed direction mid-session, and the old instruction resurfaces in later code or output.

Applies to: Claude Code · Cursor · Codex · Copilot agent

Symptom

"Actually, don't add caching." Three steps later the diff has a cache layer, or the summary describes the old plan.

Why it happens

Both the old and new instructions stay in context, and long sessions get compacted. Without an explicit record of what was superseded, the earlier, more detailed instruction can win. agent-failure-modes names this AFM-6 Zombie Requirement.

Example

Illustrative.

text

You (turn 3):  Add a Redis cache for /products.
You (turn 9):  Drop the cache idea, the data must always be fresh.
Agent (turn 15): "Done. /products now reads through the Redis cache with a 60s TTL."

Copy-paste fixes

Pick the files for the agents you use. Snippets are in English so they work in any repo.

Rules

Claude Code: add to CLAUDE.md

CLAUDE.md

## Track decisions explicitly
- Keep a short `DECISIONS.md` (or a "Decisions" section in the task file) during long tasks.
  When the user changes direction, write `SUPERSEDED: <old instruction> -> <new instruction>`.
- Before the final summary, re-read that list and check the diff against the latest decisions only.
- If two instructions conflict and neither is marked superseded, ask.

Rules

Codex, Copilot coding agent and others: add to AGENTS.md

AGENTS.md

## Track decisions explicitly
- Keep a short `DECISIONS.md` (or a "Decisions" section in the task file) during long tasks.
  When the user changes direction, write `SUPERSEDED: <old instruction> -> <new instruction>`.
- Before the final summary, re-read that list and check the diff against the latest decisions only.
- If two instructions conflict and neither is marked superseded, ask.

Cursor rule

Cursor: project rule

.cursor/rules/zombie-requirement.mdc

---
description: "AgentFails: A requirement you cancelled comes back"
alwaysApply: true
---

## Track decisions explicitly
- Keep a short `DECISIONS.md` (or a "Decisions" section in the task file) during long tasks.
  When the user changes direction, write `SUPERSEDED: <old instruction> -> <new instruction>`.
- Before the final summary, re-read that list and check the diff against the latest decisions only.
- If two instructions conflict and neither is marked superseded, ask.

Skill

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.

Sources and credit

Improve this pattern on GitHub Hit this and the fix didn't work? Tell us