evanflow-review

Name: evanflow-review
Author: evanklem

419stars18forks

How to install evanflow-review?

evanklem/evanflow/evanflow-review

$npx -y skills add evanklem/evanflow --skill evanflow-review

Installs into the current project.

Summary

Code review — both giving and receiving feedback. Verifying observed behavior over performative agreement. Use when reviewing a PR, requesting review on completed work, or processing review feedback you received.

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: Review
2
3
4	## Vocabulary
5
6	See `evanflow` meta-skill.
7
8	## When to Use
9
10	- Completed work, want a review pass before integration
11	- Reviewing someone else's PR
12	- Received review feedback and need to process it (especially if you disagree)
13
14	## Two Halves
15
16	### A. Requesting Review (giving work to be reviewed)
17
18	#### 1. Self-review first
19
20	Before asking anyone to look:
21
22	- Run the project's quality checks (`tsc`, `lint`, `test`)
23	- Re-read the diff with fresh eyes
24	- Check the diff matches the spec/plan — no scope creep
25	- Look for: leftover console.logs, commented-out code, unused imports, secrets accidentally committed
26	- Apply the deletion test to new modules: do they earn their existence?
27
28	#### 2. Frame the review request
29
30	State explicitly:
31
32	- Goal: what behavior changed
33	- Approach: why this approach (link to spec/plan)
34	- Risk areas: where you most want a critical eye
35	- Verification done: what you tested locally; what's untested
36	- Open questions: things you're unsure about
37
38	A reviewer can't help you find what you didn't flag.
39
40	### B. Receiving Review
41
42	#### 1. Read all feedback first
43
44	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.
45
46	#### 2. Embedded Grill — Challenge feedback you disagree with
47
48	For any feedback that feels wrong:
49
50	- "Is the reviewer working from a wrong assumption? What context might they be missing?"
51	- "Does the project's CLAUDE.md or `docs/adr/` already address this?"
52	- "Would the suggested change make a different test pass that currently doesn't exist?"
53	- "Is this a stylistic preference or a correctness issue?"
54
55	If after grilling you still disagree, respond with reasoning, not capitulation. Performative agreement that ships bad code is worse than respectful disagreement.
56
57	#### 3. Group changes
58
59	Batch similar feedback into single edits. Don't make 17 separate one-line changes.
60
61	#### 4. Verify after each batch
62
63	Run the quality checks. Don't push a "review fixes" commit that breaks the build.
64
65	## Hard Rules
66
67	- Verify before claiming a fix is done. Run the test that the reviewer flagged.
68	- Don't capitulate to feedback you can't justify. If you can't articulate WHY the change is right, don't make it.
69	- Don't agree-and-defer. "Good catch, will fix later" with no follow-up is debt.
70	- Never auto-commit, never auto-stage, never auto-finish. When review fixes are done, report what was done and STOP. The user decides when to commit.
71
72	## Hand-offs
73
74	- Review accepted, changes complete → report what was done and STOP. Await user direction.
75	- Review surfaced a deeper issue → `evanflow-improve-architecture` or `evanflow-debug`
76	- Review surfaced wrong assumptions about intent → `evanflow-brainstorming` to realign

People who liked this also viewed

6 picks

Type

evanflow-review

419stars18forks

View on GitHub

How to install evanflow-review?

evanklem/evanflow/evanflow-review

$npx -y skills add evanklem/evanflow --skill evanflow-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: Review
2
3
4	## Vocabulary
5
6	See `evanflow` meta-skill.
7
8	## When to Use
9
10	- Completed work, want a review pass before integration
11	- Reviewing someone else's PR
12	- Received review feedback and need to process it (especially if you disagree)
13
14	## Two Halves
15
16	### A. Requesting Review (giving work to be reviewed)
17
18	#### 1. Self-review first
19
20	Before asking anyone to look:
21
22	- Run the project's quality checks (`tsc`, `lint`, `test`)
23	- Re-read the diff with fresh eyes
24	- Check the diff matches the spec/plan — no scope creep
25	- Look for: leftover console.logs, commented-out code, unused imports, secrets accidentally committed
26	- Apply the deletion test to new modules: do they earn their existence?
27
28	#### 2. Frame the review request
29
30	State explicitly:
31
32	- Goal: what behavior changed
33	- Approach: why this approach (link to spec/plan)
34	- Risk areas: where you most want a critical eye
35	- Verification done: what you tested locally; what's untested
36	- Open questions: things you're unsure about
37
38	A reviewer can't help you find what you didn't flag.
39
40	### B. Receiving Review
41
42	#### 1. Read all feedback first
43
44	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.
45
46	#### 2. Embedded Grill — Challenge feedback you disagree with
47
48	For any feedback that feels wrong:
49
50	- "Is the reviewer working from a wrong assumption? What context might they be missing?"
51	- "Does the project's CLAUDE.md or `docs/adr/` already address this?"
52	- "Would the suggested change make a different test pass that currently doesn't exist?"
53	- "Is this a stylistic preference or a correctness issue?"
54
55	If after grilling you still disagree, respond with reasoning, not capitulation. Performative agreement that ships bad code is worse than respectful disagreement.
56
57	#### 3. Group changes
58
59	Batch similar feedback into single edits. Don't make 17 separate one-line changes.
60
61	#### 4. Verify after each batch
62
63	Run the quality checks. Don't push a "review fixes" commit that breaks the build.
64
65	## Hard Rules
66
67	- Verify before claiming a fix is done. Run the test that the reviewer flagged.
68	- Don't capitulate to feedback you can't justify. If you can't articulate WHY the change is right, don't make it.
69	- Don't agree-and-defer. "Good catch, will fix later" with no follow-up is debt.
70	- Never auto-commit, never auto-stage, never auto-finish. When review fixes are done, report what was done and STOP. The user decides when to commit.
71
72	## Hand-offs
73
74	- Review accepted, changes complete → report what was done and STOP. Await user direction.
75	- Review surfaced a deeper issue → `evanflow-improve-architecture` or `evanflow-debug`
76	- Review surfaced wrong assumptions about intent → `evanflow-brainstorming` to realign

People who liked this also viewed

6 picks

Type