debugging loops

7 loops in this category.

Sentry error triage loop

/looploopreponew

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.

prompt
→ Claude
/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
debuggingmedium risk

Memory leak hunt

/goalloopreponew

Drive a suspected memory leak to ground: reproduce growth under a repeated workload, capture heap snapshots, and fix the retention until memory stays flat.

prompt
→ Claude
/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

/loopnew

Loop until the user enters a number that passes your validation criteria.

prompt
→ Claude
/loop untill the user enteres a valid number
debugginglow risk
source ↗

Take a ticket to reviewer-ready

/loopForward Futurenew

Turn a ticket or bug report into a proven root cause, a minimal patch, and a clean handoff a reviewer can trust.

prompt
→ Claude
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

Ralph the bug backlog

/ralphGeoffrey Huntleynew

Work a triaged bug list one fix per fresh-context iteration: reproduce first, fix minimally, prove it with a regression test, and log root-cause patterns to guardrails.

prompt
→ Claude
/loop fresh context each iteration: read bugs.json and .ralph/guardrails.md, take the top open bug, write a failing test that reproduces it before touching any code, then apply the smallest fix that makes the test pass with the rest of the suite green, and mark the bug fixed; if you cannot reproduce it, mark it needs-info with your findings instead; append recurring root-cause patterns to .ralph/guardrails.md; stop when bugs.json is clear or after 25 turns
debugginghigh risk

Sweep production errors to root cause

/loopForward Futurenew

Trace actionable production errors to their root cause, verify the fix, open a PR, and stop cleanly when nothing needs action.

prompt
→ Claude
Review our production logs for errors. If you find an actionable issue, trace it to its root cause, fix it, verify the fix, and open a pull request. If no actionable errors are present, stop without making changes.
debugginghigh risk

Rewrite every user-facing error

/loopForward Futurenew

Inventory user-visible errors, replace internal or confusing text, and prove each reachable error state reads clearly.

prompt
→ Claude
Find and improve every user-visible error message within [repository, product, or named scope]. If no scope is supplied, use the user-facing surfaces in the current repository and state any exclusions before editing. Inventory error strings in source code, surfaced API or client errors, and reachable browser states. Record each one in a CSV with its location, trigger, current copy, user risk, proposed replacement, implementation status, and verification result. Rank the errors by user harm. Rewrite one coherent group at a time using plain language and a useful recovery step when one exists. Do not expose provider names, stack traces, internal identifiers, or implementation details. After each change, run the relevant tests, exercise the affected state in a real browser when possible, and search again for raw or internal error text. Do not mark an unreachable state as verified. Stop when every row is verified or explicitly blocked. Finish with the CSV, changed files, test evidence, browser evidence, and blocked items.
debuggingmedium risk