智能体审查说“可以合并”（却漏掉了问题）

## Treat agent review as one signal, not a gate
- Never report a change as "reviewed" because review agents approved it. Say which reviewers ran,
  on which model, and what they did not check (architecture, whether the change is needed).
- For review, use a fresh context that sees only the request and the diff, and if possible a
  different model family from the one that wrote the code.
- Every finding needs file:line, severity and a way to verify it. Drop findings you can't verify.
- Stop after one fix round per finding. If a new round only finds new low-severity items,
  report them instead of fixing them, and hand the decision to a human.
- Always ask: does this change need to exist, and does it reuse what is already in the codebase?

## Treat agent review as one signal, not a gate
- Never report a change as "reviewed" because review agents approved it. Say which reviewers ran,
  on which model, and what they did not check (architecture, whether the change is needed).
- For review, use a fresh context that sees only the request and the diff, and if possible a
  different model family from the one that wrote the code.
- Every finding needs file:line, severity and a way to verify it. Drop findings you can't verify.
- Stop after one fix round per finding. If a new round only finds new low-severity items,
  report them instead of fixing them, and hand the decision to a human.
- Always ask: does this change need to exist, and does it reuse what is already in the codebase?

---
description: "AgentFails: Agent review said 'good to go' (and missed it)"
alwaysApply: true
---

## Treat agent review as one signal, not a gate
- Never report a change as "reviewed" because review agents approved it. Say which reviewers ran,
  on which model, and what they did not check (architecture, whether the change is needed).
- For review, use a fresh context that sees only the request and the diff, and if possible a
  different model family from the one that wrote the code.
- Every finding needs file:line, severity and a way to verify it. Drop findings you can't verify.
- Stop after one fix round per finding. If a new round only finds new low-severity items,
  report them instead of fixing them, and hand the decision to a human.
- Always ask: does this change need to exist, and does it reuse what is already in the codebase?

---
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.

---
name: verify
description: Verify the current change before calling it done. Use before every commit, PR, or "done" message.
---

# Verify

Run every step and paste the real output. Never summarize a step you did not run.

1. **Scope**: run `git diff --stat` and `git status --short`. For every changed file, say which part
   of the request needs it. Any file you cannot justify gets reverted, or listed under
   "Unrequested changes" for the user to decide.
2. **Build and types**: `npm run build` (or the project's build command).
3. **Tests**: `npm test`. Report pass/fail counts. If a test was edited, skipped or deleted,
   say so explicitly with the reason.
4. **Behavior**: exercise the changed behavior once for real (a curl, a CLI run, a screenshot)
   and show what happened.
5. **Report** in this format:
   - Requested: <one line>
   - Changed files: <list, each with its reason>
   - Checks run: <command -> result>
   - Not done / unsure: <list, or "none">