From evanflow
Guides code review processes: self-review before requesting feedback, framing PRs with goals and risks, processing feedback by challenging disagreements, grouping fixes, and verifying changes.
npx claudepluginhub evanklem/evanflow --plugin evanflowThis skill uses the workspace's default tool permissions.
See `evanflow` meta-skill.
Enforces strict 6-step protocol for processing code review feedback: read fully, restate, verify against codebase, evaluate architecture fit, technical response or pushback, implement one-by-one.
Guides code review: rigorous feedback reception, subagent reviews after tasks/features, verification before completion claims. For subagent dev and PRs.
Guides code review practices: receiving technical feedback, requesting subagent reviews for PRs/features, and verification gates before completion claims or merges.
Share bugs, ideas, or general feedback.
See evanflow meta-skill.
Before asking anyone to look:
tsc, lint, test)State explicitly:
A reviewer can't help you find what you didn't flag.
Don't start fixing the first comment until you've read every comment. Patterns matter — three comments on similar code might mean a structural issue, not three separate fixes.
For any feedback that feels wrong:
docs/adr/ already address this?"If after grilling you still disagree, respond with reasoning, not capitulation. Performative agreement that ships bad code is worse than respectful disagreement.
Batch similar feedback into single edits. Don't make 17 separate one-line changes.
Run the quality checks. Don't push a "review fixes" commit that breaks the build.
evanflow-improve-architecture or evanflow-debugevanflow-brainstorming to realign