Skills › Visual Explainer › visual-explainer › diff-review.md

diff-review.md

25 lines · plugins/visual-explainer/commands/diff-review.md at 9d5f880

1---

2name: diff-review

3description: Generate a visual diff review for code changes, with each fix to accept or leave in the page

4---

6Load the visual-explainer skill and make a visual diff review.

8Scope: read `$@` as a branch, commit, range, PR, or `HEAD`. If it is empty, compare the working tree with `main`/`master`.

10Gather before you draw: diff stats, name-status, the full changed files and the code paths around them, public API or type changes, tests, dependency or config changes, and commit messages. Every claim cites a path or `file:line`. Do not invent a rationale.

12Typical sections; merge, reorder, drop, or add as the content needs:

14| Section | Figure |

15|---|---|

16| Verdict | one sentence + merge/blocked chip + `<ve-stack>` of lines added and removed |

17| What changed | file map with added/modified/deleted chips; `<ve-bars>` of lines per file |

18| Behavior | before/after of the same SVG, edges added or removed highlighted; a changed state machine or queue replays one event per step (`references/motion.md`); a machine read from code is walked before and after, showing a rule the diff newly breaks or a state it makes unreachable (`references/machines.md`) |

19| Risks | severity-chip table: correctness, tests, API, security, performance |

20| Coupling | small SVG of what depends on the changed code |

21| Fixes | each risk worth acting on: `<ve-ask id="r1" q="Fix the unchecked null in parse()?">` (then `r2`, …; the risk in a few words) with `<ve-opt value="fix" default note="the fix in one line">Fix</ve-opt>` and `<ve-opt value="leave">Leave as is</ve-opt>` |

23Colors: red = removed or before · green = added or after · amber = risk · blue = context. Deliver with the skill's rules and hand over in one line.

25When the reply arrives: on a branch the user owns, apply only the fixes the reader picked; a question they left alone is not a yes. On someone else's PR, draft review comments for them and do not post them.

Load the visual-explainer skill and make a visual diff review.

Scope: read $@ as a branch, commit, range, PR, or HEAD. If it is empty, compare the working tree with main/master.

Gather before you draw: diff stats, name-status, the full changed files and the code paths around them, public API or type changes, tests, dependency or config changes, and commit messages. Every claim cites a path or file:line. Do not invent a rationale.

Typical sections; merge, reorder, drop, or add as the content needs:

Section	Figure
Verdict	one sentence + merge/blocked chip + `<ve-stack>` of lines added and removed
What changed	file map with added/modified/deleted chips; `<ve-bars>` of lines per file
Behavior	before/after of the same SVG, edges added or removed highlighted; a changed state machine or queue replays one event per step (`references/motion.md`); a machine read from code is walked before and after, showing a rule the diff newly breaks or a state it makes unreachable (`references/machines.md`)
Risks	severity-chip table: correctness, tests, API, security, performance
Coupling	small SVG of what depends on the changed code
Fixes	each risk worth acting on: `<ve-ask id="r1" q="Fix the unchecked null in parse()?">` (then `r2`, …; the risk in a few words) with `<ve-opt value="fix" default note="the fix in one line">Fix</ve-opt>` and `<ve-opt value="leave">Leave as is</ve-opt>`

Colors: red = removed or before · green = added or after · amber = risk · blue = context. Deliver with the skill's rules and hand over in one line.

When the reply arrives: on a branch the user owns, apply only the fixes the reader picked; a question they left alone is not a yes. On someone else's PR, draft review comments for them and do not post them.

Raw lines 1 to 25