investigate (gstack)
- Engineering
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.
A situation it fits
Every morning at 3am the user-auth DB connection pool empties and the service sputters until the on-call engineer slaps on a quick hot-fix before breakfast.
3 scenarios in the bank answer to investigate (gstack). The rest are in the game.
Skills it gets confused with
These share a family with investigate (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.
- 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.
- review (gstack)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.
Knowing what investigate (gstack) does is the easy half. Telling it apart from the others under time pressure is the game.
Today's sessioninvestigate (gstack) is part of garrytan/gstack. Licence: MIT. The description above was written for this game, not taken from the skill.