Wrong feature

Swapped in its own approach, then "You're absolutely right"

换成了自己的方案，被指出后立刻说“你说得完全对”

You name the approach you want. The agent proposes or builds a different one, and when you point that out it agrees instantly instead of explaining or re-checking.

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

Symptom

The plan or diff uses a familiar alternative (a provider-specific link, a library you didn't pick, a pattern from another codebase) instead of the one you asked for. Your correction gets "You're absolutely right" and a rewrite, with no account of why it deviated.

Why it happens

In a reply to Thorsten Ball's "Why are you still using pull requests?" post, @StanleyMasinde_ describes recommending an ICS attachment on event emails, so any mail client can add the event to the calendar; the agent suggested a Google Calendar intent link instead, and on correction answered "you're absolutely right to point that out". His point: review now matters for business logic, not syntax. Thorsten Ball replied that his team also catches bugs, just not via PRs. Others in the thread report the same reflex: agents "agree with me all the time" (@adebola_io), and "when confronted all models agree they did mistakes" (@danielh164). Agreement is cheap, so it is not evidence that the agent understood the requirement.

Example

Paraphrased from @StanleyMasinde_'s post; the code is illustrative.

text

Asked:  attach an .ics file to event emails so mail clients can add it to the calendar
Agent:  adds a "Add to Google Calendar" intent link (works for one provider only)
You:    "I asked for an ICS attachment."
Agent:  "You're absolutely right to point that out!"  (rewrites, no explanation)

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

## Use the approach the user named
- If the user named an approach, format, library or protocol, use exactly that one.
- If you think another approach is better, say so before writing code: name both, give the
  trade-off in one or two lines, and wait for the user to choose. Do not substitute silently.
- When the user corrects you, do not just agree. State what you did, what was asked, why they
  differ, and what you will change. Then re-check the rest of the change for the same mistake.
- In your summary, list every place where your implementation differs from what was asked.

Rules

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

AGENTS.md

## Use the approach the user named
- If the user named an approach, format, library or protocol, use exactly that one.
- If you think another approach is better, say so before writing code: name both, give the
  trade-off in one or two lines, and wait for the user to choose. Do not substitute silently.
- When the user corrects you, do not just agree. State what you did, what was asked, why they
  differ, and what you will change. Then re-check the rest of the change for the same mistake.
- In your summary, list every place where your implementation differs from what was asked.

Cursor rule

Cursor: project rule

.cursor/rules/swapped-approach-then-agreed.mdc

---
description: "AgentFails: Swapped in its own approach, then 'You're absolutely right'"
alwaysApply: true
---

## Use the approach the user named
- If the user named an approach, format, library or protocol, use exactly that one.
- If you think another approach is better, say so before writing code: name both, give the
  trade-off in one or two lines, and wait for the user to choose. Do not substitute silently.
- When the user corrects you, do not just agree. State what you did, what was asked, why they
  differ, and what you will change. Then re-check the rest of the change for the same mistake.
- In your summary, list every place where your implementation differs from what was asked.

Template

SPEC.md acceptance checks (written and approved before code)

Teammates annotate this file (or the mockup/artifact) instead of reviewing a big PR. Each check should separate the reading you mean from the reading you don't.

SPEC.md

# Spec: <feature name>

## Goal (one sentence, in the user's words)

## Out of scope
- <things a reasonable agent might also do, but must not>

## Acceptance checks (each one runnable)
- [ ] Given <input>, when <action>, then <exact observable result>
- [ ] Example that rules out the wrong reading: <input> -> <expected>, NOT <plausible wrong output>
- [ ] Command that proves it: `<test or curl command>`

## Open questions (agent must ask, not assume)
- <question>

## Approved by: <name> on <date>

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