Evaluate

4. Output format

## Evaluation of [source description]

### [suggestion 1 summary]
Verdict: accept / accept with modification / reject / needs investigation
Reasoning: [cite specific codebase facts, not general opinions]
Action: [what to do, if accepted]

### [suggestion 2 summary]
...

## Summary
Accepted: N  |  Modified: N  |  Rejected: N  |  Needs investigation: N

Rules

• Be specific — "This doesn't apply" is not enough. Say WHY, citing files/code/decisions you know about.
• Separate intent from approach — A reviewer can be right about the problem and wrong about the solution.
• Don't reject based on effort — "That's a lot of work" is not a valid reason to reject. Only reject on technical grounds.
• Don't accept out of deference — External reviewer ≠ automatically correct. Your codebase context is the advantage here.
• Flag your own uncertainty — If you're not sure about something, say "needs investigation", don't guess.
• Preserve the user's judgment — You evaluate, the user decides. Present evidence, not directives.