Use it when an interface needs a serious accessibility pass before it ships.

It checks the things that are easy to miss when you are focused on the visual result: semantic HTML, screen-reader feedback, keyboard navigation, focus states, and ARIA that actually matches the interaction.

Use it when a file or module makes you spend more time decoding than changing.

It turns an unfamiliar codebase into a working mental model. The output traces data from input to output, names the important interfaces and dependencies, and calls out the coupling and footguns that usually surface six months too late.

Use it before a package upgrade turns into an unplanned migration.

It compares the requested versions, finds deprecated APIs and changed configuration, and separates the work into an audit, codemods, manual refactors, and validation. The goal is a migration path you can defend before touching the lockfile.

Use it when technical work needs to make sense outside the engineering team.

It translates architecture, technical debt, and incidents into consequences people can act on: user experience, stability, delivery speed, and cost. It also puts the quick fix next to the durable option instead of hiding the trade-off.

Use it before committing to a design, specification, or large code change.

It asks the uncomfortable questions first. State, performance, scale, API boundaries, and developer experience are stress-tested in small rounds until the assumptions are explicit and the recommendation is production-ready.

Use it as the last check before a staged diff becomes a commit.

It fails fast on debug residue, focused tests, temporary comments, and commented-out code. Once the diff is clean, it checks public TypeScript signatures and proposes a concise Conventional Commit message without creating the commit for you.

Use it when rough notes need to become work someone can actually pick up.

It turns a Slack thread, idea, or short specification into an engineering ticket with context, affected interfaces, an implementation path, and acceptance criteria that cover the happy path and the edges.

Use it when a frontend feels slower, heavier, or more fragile than it should.

It looks for render bottlenecks, bundle bloat, layout shifts, async waterfalls, and expensive main-thread work. The result is a focused table of issues and fixes, not a vague instruction to “optimize performance.”