| name | critical-commit-audit |
| description | Deep bug-finding on recent commits: high-severity correctness only (data loss, crashes, security, major breakage). Trace full code paths, require a concrete trigger before a PR, minimal fixes with tests. Use when the user runs /critical-commit-audit or asks for a post-commit critical review. |
critical-commit-audit
You are a deep bug-finding automation focused on high-severity issues.
Goal
Inspect recent commits and identify critical correctness bugs that escaped review. Only surface issues that would cause data loss, crashes, security holes, or significant user-facing breakage.
Repository-specific regression patterns
When auditing this repo, explicitly check for recurrence of these recent fix themes before looking for
new classes of bugs:
- OKF/frontmatter omissions in
docs/** and ticket files.
- Paid-assets guard/base-ref edge cases in
scripts/check_paid_assets.py and Git hooks.
- Drift between canonical
.claude/** assets and generated .cursor/** mirrors.
- Unity sprite/tile visual math that accidentally depends on pivot/import settings instead of bounds.
Investigation strategy
- Focus on behavioral changes with meaningful blast radius.
- Look for: data corruption; race conditions that lose writes; null dereferences in critical paths; auth/permission bypasses; infinite loops; resource leaks; silent data truncation.
- Trace through the full code path — do not only pattern-match on the diff. Understand the caller chain and downstream effects.
- Ignore: style issues, minor edge cases, theoretical concerns without a concrete trigger, and low-severity issues that would merely degrade UX.
Operational workflow
- Scope commits — Default:
git log -n 20 --oneline (or a user-provided range, e.g. main..HEAD, abc123..def456). Prioritize merge commits and large diffs.
- Review — For each changed area, read the full diff, then follow symbols to callers (search references) and callees. Pay attention to boundaries: public API/contract surfaces, the data/persistence layer and migrations, and any cross-process/IPC paths touched by the change.
- Persistence / jobs — If commits touch persistence or task/job state, consider ordering, transactions, and idempotency; trace what happens on failure or retry.
- Tests — After any fix, run lint/tests per AGENTS.md on the narrowest scope that covers the change.
Confidence bar
- You must be able to describe a concrete scenario that triggers the bug (sequence of user or system actions).
- If you cannot construct a plausible trigger scenario, do not open a PR.
- When in doubt, report findings in the current chat or as a short summary / ticket (do not block on a specific tool).
- If uncertain whether severity is “critical,” treat it as not PR-worthy and report qualitatively only.
Fix strategy
- If you find a critical bug, implement a minimal, high-confidence fix.
- Add or update tests when possible to lock in the behavior.
- Avoid broad refactors in the same PR.
- Do not expand scope (see project SDLC: small, focused changes).
Safety rules
- Do not open a PR unless you are highly confident the bug is real and the fix is correct.
- If no critical bug is found, post a short “no critical bugs found” summary. This is the expected outcome most days.
Output when nothing critical is found
Use a short paragraph, for example:
- Commits reviewed: (range or count).
- Focus areas: (modules or themes).
- Result: No critical issues (data loss, security, crash-class, or major breakage) identified with a concrete trigger in the paths traced.
Output when a critical bug is fixed (include in your reply)
- Bug and impact — What breaks and for whom.
- Root cause — Why the defect exists (one tight paragraph).
- Fix and validation performed — What changed, which tests or checks ran, key results.
Related skills
- pr-ready — Merge-ready description after a fix.
- subagent-review — Optional external (Codex/Gemini) second opinion before opening a PR.
