review (gstack)
- Engineering
Reads a finished code change just before it lands and flags what should block the merge — correctness, risk, missed cases — on the actual diff. It reviews written code at merge time, not an architecture plan before building and not a running failure.
A situation it fits
A finished pull request is sitting in the queue; you want someone to read the actual changed lines right before it merges and flag anything that should block it — a broken edge case, a risky change, a missed test.
3 scenarios in the bank answer to review (gstack). The rest are in the game.
Skills it gets confused with
These share a family with review (gstack), which is another way of saying they are the ones you might reach for by mistake.
- health (gstack)Produces a standing dashboard of a codebase's overall quality — complexity, coverage, duplication, hot spots — to show where the whole project is trending. It measures the codebase in aggregate over time, not a single plan, a single diff, or a single bug.
- investigate (gstack)Chases a bug or failure to its actual root cause through systematic evidence-gathering, rather than patching the first symptom. It is the diagnose-why-this-breaks step, distinct from reviewing a plan, reviewing a diff, or reporting overall code-quality metrics.
- plan-eng-review (gstack)Reviews a proposed technical plan the way an engineering manager would — is the architecture sound, are the tradeoffs right, what will bite later — before any code is written. It judges the approach on paper, unlike a pre-merge review that reads a finished diff or a debugger that chases a live bug.
Knowing what review (gstack) does is the easy half. Telling it apart from the others under time pressure is the game.
Today's sessionreview (gstack) is part of garrytan/gstack. Licence: MIT. The description above was written for this game, not taken from the skill.