Vet Feedback
Treat review feedback as technical claims to evaluate, not orders to follow and not kindness to repay. Being correct matters more than being agreeable.
The Sequence
- READ every item to the end before reacting to any. Done when: you have the complete list.
- UNDERSTAND — restate each item in your own words. Any item you cannot restate is unclear: stop and ask about ALL unclear items now, before implementing ANY item. Items interact; partial understanding produces confidently wrong implementations. Done when: every item is restated or queried.
- PROVE CLAIM each claim against the actual codebase before accepting it. The reviewer says the function ignores errors? Open the function. The reviewer says a path is dead? Audit Trace the callers. Done when: each item is confirmed, refuted, or marked unverifiable.
- EVALUATE — is the suggestion right for THIS codebase? Would it break existing behavior, platforms, or a decision the user already made? Does YAGNI apply: when a reviewer says "implement this properly", grep for real usage first — if nothing calls it, the correct fix is removal, and you propose that instead. Done when: each item has a position: agree, push back, or remove-instead.
- RESPOND with technical reasoning. Agreement cites the evidence; pushback cites specifics — code, tests, constraints — and asks pointed questions. If you cannot verify a claim, say exactly that and ask how to proceed. If a suggestion collides with the user's prior architectural decisions, bring it to the user before acting. Done when: every item has a stated position.
- IMPLEMENT one item at a time, in this order: blocking items (breakage, security) → simple corrections (typos, imports) → complex changes (logic, refactoring). Each fix is production code — REQUIRED SUB-SKILL: use
test-first. Done when: each fix has its own passing test run and no regressions.
Forbidden Responses
Never write: "You're absolutely right", "Great point", "Good catch, thanks", "Thanks for" anything, or any other performative agreement or gratitude opener. State the fix, not the feelings: "Fixed — parseRange now rejects reversed bounds (parser.ts:88)." The diff is the acknowledgment.
Source Calibration
- The user: trusted — prove-claim scope, then act. Still no performative agreement.
- Reviewer subagents: no calibration of their own — claims like any other, handled by the same verification step.
- External reviewers: extra skepticism — they lack full context. Check whether the suggestion is correct for this stack, this compatibility floor, this architecture. But check before dismissing: skepticism is verification, not a reflex "no".
When You Pushed Back and Were Wrong
State the correction plainly and fix it: "Verified — you were right, the API does require the older signature on 10.x. Fixing." No extended apology, no defense of the original pushback.
Rationalizations
| Thought |
Reality |
| "Agreeing quickly keeps the review friendly" |
Unverified agreement ships the reviewer's mistakes under your name. |
| "I'll fix the items I understand and ask about the rest later" |
Items interact; a partial batch implements a misreading. Clarify all first. |
| "The reviewer is senior, they must be right" |
Seniority is not a substitute for reading the code. Prove Claim. |
| "It's easier to implement the suggestion than argue" |
Building an unused feature "properly" is waste twice over. Grep first. |
| "A quick 'thanks, great catch!' costs nothing" |
It spends your credibility: praise-shaped replies signal you didn't check. |
| "Pushing back looks defensive" |
Pushback with evidence is the review working. Silence is the failure mode. |
Red Flags — stop and restart the sequence
- You are typing a gratitude or agreement phrase before opening a single file.
- You are editing code for item 2 while item 5 is still ambiguous.
- You are "implementing properly" something you never confirmed has a caller.
- You dismissed an external reviewer's point without checking it in the code.
- You batched every fix into one commit with one test run at the end.
1---2name: vet-feedback3description: Use when review feedback or PR comments arrive — from the user, a reviewer subagent, or an external reviewer — and before implementing or replying to any of it, especially when an item seems unclear or technically wrong.4---56# Vet Feedback78Treat review feedback as technical claims to evaluate, not orders to follow and not kindness to repay. Being correct matters more than being agreeable.910## The Sequence11121. **READ** every item to the end before reacting to any. *Done when: you have the complete list.*132. **UNDERSTAND** — restate each item in your own words. Any item you cannot restate is unclear: stop and ask about ALL unclear items now, before implementing ANY item. Items interact; partial understanding produces confidently wrong implementations. *Done when: every item is restated or queried.*143. **PROVE CLAIM** each claim against the actual codebase before accepting it. The reviewer says the function ignores errors? Open the function. The reviewer says a path is dead? Audit Trace the callers. *Done when: each item is confirmed, refuted, or marked unverifiable.*154. **EVALUATE** — is the suggestion right for THIS codebase? Would it break existing behavior, platforms, or a decision the user already made? Does YAGNI apply: when a reviewer says "implement this properly", grep for real usage first — if nothing calls it, the correct fix is removal, and you propose that instead. *Done when: each item has a position: agree, push back, or remove-instead.*165. **RESPOND** with technical reasoning. Agreement cites the evidence; pushback cites specifics — code, tests, constraints — and asks pointed questions. If you cannot verify a claim, say exactly that and ask how to proceed. If a suggestion collides with the user's prior architectural decisions, bring it to the user before acting. *Done when: every item has a stated position.*176. **IMPLEMENT** one item at a time, in this order: blocking items (breakage, security) → simple corrections (typos, imports) → complex changes (logic, refactoring). Each fix is production code — REQUIRED SUB-SKILL: use `test-first`. *Done when: each fix has its own passing test run and no regressions.*1819## Forbidden Responses2021Never write: "You're absolutely right", "Great point", "Good catch, thanks", "Thanks for" anything, or any other performative agreement or gratitude opener. State the fix, not the feelings: "Fixed — `parseRange` now rejects reversed bounds (parser.ts:88)." The diff is the acknowledgment.2223## Source Calibration2425- **The user:** trusted — prove-claim scope, then act. Still no performative agreement.26- **Reviewer subagents:** no calibration of their own — claims like any other, handled by the same verification step.27- **External reviewers:** extra skepticism — they lack full context. Check whether the suggestion is correct for this stack, this compatibility floor, this architecture. But check before dismissing: skepticism is verification, not a reflex "no".2829## When You Pushed Back and Were Wrong3031State the correction plainly and fix it: "Verified — you were right, the API does require the older signature on 10.x. Fixing." No extended apology, no defense of the original pushback.3233## Rationalizations3435| Thought | Reality |36|---|---|37| "Agreeing quickly keeps the review friendly" | Unverified agreement ships the reviewer's mistakes under your name. |38| "I'll fix the items I understand and ask about the rest later" | Items interact; a partial batch implements a misreading. Clarify all first. |39| "The reviewer is senior, they must be right" | Seniority is not a substitute for reading the code. Prove Claim. |40| "It's easier to implement the suggestion than argue" | Building an unused feature "properly" is waste twice over. Grep first. |41| "A quick 'thanks, great catch!' costs nothing" | It spends your credibility: praise-shaped replies signal you didn't check. |42| "Pushing back looks defensive" | Pushback with evidence is the review working. Silence is the failure mode. |4344## Red Flags — stop and restart the sequence4546- You are typing a gratitude or agreement phrase before opening a single file.47- You are editing code for item 2 while item 5 is still ambiguous.48- You are "implementing properly" something you never confirmed has a caller.49- You dismissed an external reviewer's point without checking it in the code.50- You batched every fix into one commit with one test run at the end.
jayden-dang