Loop 016
The ticket-to-PR-ready loop
A bounded engineering workflow that turns a ticket, failing behavior, or customer complaint into a proven root cause, minimal patch, and reviewer-ready handoff.
Ready-to-use prompt
Copy the loop
Take this ticket, bug report, failing behavior, or customer complaint and turn it into a review-ready patch. Define the failure clearly and reproduce it in the smallest possible environment. Isolate the root cause and confirm it with evidence, not inference. Implement the smallest credible fix, then verify the before-and-after behavior. If verification fails, return to the root cause and iterate. If the issue cannot be reproduced after two serious attempts, say so clearly. Do not silently expand scope; split broader refactors or separate problems into named follow-ups. Finish with the failure summary, reproduction steps, root cause, fix summary, files changed, verification proof, risks, follow-ups, suggested PR title, and PR description draft.
Verify / stop
The failure is fixed, verified, and ready for review.
The same behavior reproduces before the fix, no longer reproduces afterward, and the handoff explains the evidence in under two minutes.
Context and guidance When to use it, steps, safety notes, and related loops
Use this when
Use this when a real but loosely written ticket, bug report, or customer complaint needs to become a bounded engineering change with enough proof for a fast review.
How to run it
- State the expected and actual behavior, then reproduce the failure in the smallest representative environment.
- Trace the behavior to a root cause and confirm the causal link with evidence.
- Implement the smallest credible fix, avoiding unrelated cleanup or hidden refactors.
- Repeat the original reproduction, run relevant regression checks, and package the result for review.
Why it works
The loop closes the gap between something being wrong and a reviewer being able to trust the patch. Reproduction, evidence, bounded scope, and a structured handoff remove the detective work from review.
Implementation note
Match the proof to the failure: screenshots or recordings for UI issues, tests or logs for backend behavior, benchmark deltas for performance, and sanitized traces for integrations.