Sentry error triage loop
Every 30 minutes, pull the newest unresolved Sentry issues, match each stack trace to the code, and draft a root-cause note and suggested fix per issue.
/loop 30m list the newest unresolved Sentry issues for this project, and for each new one: locate the stack trace in the codebase, write a short root-cause hypothesis and suggested fix as a comment on the issue, and flag anything that looks like a regression from the last release
claude-code
Implementation note
Requires Sentry access via MCP or CLI token. It comments and hypothesizes but does not change code, keeping it safe to run against production error streams.
More debugging loops
Memory leak hunt
Drive a suspected memory leak to ground: reproduce growth under a repeated workload, capture heap snapshots, and fix the retention until memory stays flat.
/goal heap usage stays flat (within 5%) across 500 repetitions of the failing workload in the leak-repro script — capture heap snapshots before and after, identify what is being retained and by which reference chain, fix the leak, and re-run the repro to confirm; stop after 10 turns
debuggingmedium risk
Keep asking for valid input
Loop until the user enters a number that passes your validation criteria.
/loop untill the user enteres a valid number
debugginglow risk
Take a ticket to reviewer-ready
Turn a ticket or bug report into a proven root cause, a minimal patch, and a clean handoff a reviewer can trust.
Take a ticket, bug report, failing behavior, or customer complaint and turn it into a review-ready patch. Reproduce the failure in the smallest representative environment, prove the root cause, make the smallest credible fix, and rerun the original reproduction plus relevant regression tests. If the issue cannot be reproduced after two serious attempts, say so. Do not fold unrelated refactors into the patch. Finish with the cause, changed files, before-and-after proof, risks, and pull-request summary.
debugginghigh risk