Why Your Code Isn’t Ready to Merge Yet: The Hidden Risks Behind the ‘Done’ Feeling

In software development the most dangerous moment is not when errors appear but when you think the work is finished.

Two essential skills: /review and /investigate

/review

prevents accidents by performing a pre‑landing structural audit of the diff; it checks for hidden production‑risk patterns such as SQL safety, race conditions, LLM trust boundaries, enum completeness, and more. It also runs a scope‑drift detection step that compares the branch’s intended scope (TODOs.md, PR description, commit messages) with the actual changes, flagging scope creep, missing requirements or unfinished parts. /investigate is used when a problem has already manifested. It follows a disciplined root‑cause workflow: collect symptoms, trace the code path, examine recent changes, attempt reproduction, formulate a verifiable hypothesis, validate it, then fix and add regression tests. It locks the debugging scope to the affected module and stops after three failed hypotheses.

When to run each skill

Feature branch is essentially complete.

Tests pass but you want to be sure nothing is missing.

Just before opening a PR or merging. /review answers “Does this change carry hidden risk?” while /investigate answers “Why is this bug happening?”

Common misconceptions

Thinking /review is just another diff glance – it actually looks for structural risks that tests may miss.

Treating /investigate as an AI “fix‑it‑quickly” tool – it is first a diagnosis, then a fix, and it will not proceed without a proven root cause.

Running /investigate when the cause is already clear – in that case a direct fix with regression testing is preferable.

Confusing /review with /ship – the former is a pre‑landing quality gate, the latter handles final delivery automation.

Why the disciplined approach matters in the AI era

AI can generate patches at high speed, but without a structured investigation it can lead to a low‑quality “whack‑a‑mole” debugging loop. The /review and /investigate skills force developers to pause, collect evidence, and verify hypotheses before changing code, preventing hidden concurrency, trust‑boundary, or scope‑drift bugs that often surface only in production.

Next articles will cover browser‑related skills such as /browse, /setup-browser-cookies, and /qa.