Verified against ChatGPT · 2026-07-28
Run an iterative code review loop in Canvas without losing earlier fixes
Structures Canvas's code mode as a repeatable review-fix-verify loop with inline suggestions, so successive rounds build on the last accepted state instead of silently reintroducing an already-fixed issue.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are running an iterative code review loop inside ChatGPT's Canvas, in code mode. Each round reviews the current state of the file in Canvas, proposes fixes as inline suggestions, and waits for a decision to accept or reject each one individually before moving to the next round. CODE IN CANVAS A 180-line Python module that validates and normalizes incoming webhook payloads before writing them to a queue. REVIEW FOCUS FOR THIS ROUND Error handling around malformed JSON payloads — round 1 already covered the schema-validation logic. ALREADY-FIXED ISSUES FROM PRIOR ROUNDS Round 1 fixed: missing required-field check on "event_type", and a bare except that swallowed all exceptions. RUNTIME OR TEST CONTEXT pytest suite exists for the schema validator; malformed-JSON handling currently has zero test coverage. LOOP RULES Review only the current state of the file as it exists in Canvas right now — do not silently reintroduce or re-flag something in the already-fixed list unless there's a specific reason to believe it regressed, and if so, say so explicitly and point to exactly where, rather than re-flagging it as if it were a fresh discovery. Scope this round's review to what's named in the review focus — if a real issue outside that focus is noticed, list it separately as "noticed but out of scope for this round" rather than fixing it unasked, since accepting or rejecting fixes one at a time only works if each round's changes are predictable and bounded. Propose each fix as a distinct, individually reviewable suggestion rather than one combined patch — a null-check fix should be acceptable without being forced to also accept an unrelated variable rename bundled into the same suggestion. For each fix, state the specific failure it prevents — an input, a state, a sequence of calls that would break without it — not a general code-quality justification like "improves readability," since a fix justified only by taste is harder to evaluate quickly than one justified by a concrete failure case. If test or runtime context was given, verify a proposed fix doesn't just move the failure to a different reported symptom — silencing an exception is not the same as fixing what threw it, and a fix that makes a test pass by weakening its assertion instead of fixing the underlying code is a regression dressed as a fix. OUTPUT FORMAT For each proposed fix: 1) exact location, 2) the specific failure it prevents, quoted or described concretely, 3) the fix itself as a Canvas-reviewable suggestion. End the round with a short list of anything noticed but explicitly left out of scope, and a one-line status of the already-fixed list — confirmed still holding, or flagged as regressed with exactly where.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Canvas's code mode persists the file's actual current state across the conversation and supports inline, individually acceptable suggestions rather than a single monolithic rewrite, so a review loop that doesn't explicitly instruct scoping per round loses that mechanical advantage — the model's default instinct when asked to "review this code" is still to produce one large combined diff, which defeats the individually-reviewable design Canvas actually offers. Explicitly tracking already-fixed issues addresses a specific and common regression in multi-round review loops: without a memory of what was already accepted, a fresh review pass over the current file state can re-flag an issue that was already fixed in an earlier round, because the model is pattern-matching against "things that look like a bug" in isolation each time rather than diffing against what was already resolved — re-flagging a fixed issue erodes trust in the loop fast, since it looks like the earlier fix didn't actually work. Requiring a concrete failure case for every fix, rather than a taste-based justification, is what makes each suggestion fast to evaluate individually — a reviewer deciding whether to accept one inline suggestion at a time needs a specific, checkable reason, and "improves readability" gives nothing to verify, while "breaks on a payload where event_type is missing" is something that can be tested in ten seconds. The check against a fix that merely relocates the failure — silencing an exception instead of fixing its cause, weakening a test assertion instead of fixing the code the test checks — targets a documented failure mode where a model under pressure to "make the error go away" satisfies the letter of the request while leaving the actual defect in place, which is worse than not fixing it at all because it looks resolved on the surface.
Verified against
ChatGPT GPT-5.1 (Canvas) · 2026-07-28
Changelog
- 2026-07-28 — Initial publish, verified against ChatGPT GPT-5.1 Canvas code mode.
Building this for real?
This is a free starting point. If you'd rather have what Scult builds built and running for your business, that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
