Verified against Cursor · 2026-08-01
Get an accurate architecture explanation out of Cursor's Ask mode without it trying to fix anything
A read-only Ask-mode brief that asks for an explanation of how a system actually works today, with explicit instructions to distinguish observed behavior from inferred intent and to flag anything that looks broken rather than silently proposing a fix, since Ask mode is for understanding, not editing.
The prompt
Ready to copy — highlighted parts are example details you can swap.
[Ask mode — read-only, no edits should be proposed or made] Explain how the following actually works today, based on reading the code, not on how it's supposed to work according to any comment, doc, or variable name that might be aspirational or stale. SYSTEM OR FLOW TO EXPLAIN How a user session gets refreshed — the full path from an expired access token to a new one being issued, including what happens if the refresh itself fails. AUDIENCE AND DEPTH A new engineer on the team who knows general web auth concepts but has never read this specific codebase — assume no familiarity with this repo's specific file layout. SPECIFIC QUESTIONS TO ANSWER What triggers the refresh — is it proactive (before expiry) or reactive (only after a 401)? What happens to in-flight requests during a refresh? Is there a retry limit? RULES - Base every claim on what the code actually does, traced through its real call path — not on what a comment, function name, or doc claims it does. If a comment and the code's actual behavior disagree, point out the disagreement explicitly rather than reporting the comment's version as fact. - Distinguish clearly between "this is what happens" (observed, traced through the code) and "this is presumably why" (inferred, your best read of intent). Label the second kind of claim as inference, since it can be wrong in a way the first kind can't. - If you notice something that looks like a bug, a race condition, or a dead code path while tracing this, name it as an observation at the end, clearly separated from the explanation itself — but do not propose a fix or edit anything. That's outside what this pass is for. - If the explanation would require reading a file outside what's been indexed or referenced, say exactly what's missing rather than filling the gap with a plausible-sounding guess about what it probably does. Structure the answer as: a short summary first, then the detailed trace, then any observations, clearly under their own heading.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Ask mode is deliberately restricted from proposing or making edits, which matters here for a reason beyond safety: a chat mode that can edit tends to shift from explaining toward fixing the moment it notices something questionable, because "here's what's happening, and here's how I'd improve it" is the model's default framing for describing code once it spots an issue, and that framing quietly turns a comprehension task into a stealth refactor proposal nobody asked for. Requiring the explanation to trace actual code behavior rather than report what a comment or function name claims addresses a specific and common documentation-drift problem: comments and names describe intent at the time they were written, and intent is exactly the thing that goes stale first when code changes underneath it without every comment being updated to match, so a model explaining "how it works" from comments alone will confidently report a version of the system that hasn't been true since the last unrelated bug fix touched the same function. Separating observed behavior from inferred intent, and labeling the second explicitly, matters because a model reasoning about why code is structured a certain way is doing something categorically different from tracing what it does — the first is a hypothesis about a decision someone made, potentially long gone from the team, and presenting it with the same confidence as a traced execution path misleads a reader who has no way to tell the two apart from the prose alone. Requiring observations about apparent bugs to be named but not acted on gives Ask mode's read-only constraint a legitimate outlet: without it, a model that notices a real race condition while explaining the flow has nowhere to put that observation except by drifting into the fix-oriented framing the mode is supposed to avoid, or by suppressing a genuinely useful finding entirely to stay strictly on-topic.
Verified against
Cursor 2.2 · 2026-08-01
Changelog
- 2026-08-01 — Initial publish, verified against Cursor 2.2 Ask mode.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
