Verified against Cursor · 2026-07-20
Write intent-first comments that steer what Cursor Tab predicts next
A commenting-style brief — for the top of a file or a project-wide note — that shapes forward-looking intent comments for Cursor Tab's predictive multi-line completion, and enforces consistent terminology, so its suggestions match your next step more often instead of guessing from indentation and generic patterns alone.
The prompt
Ready to copy — highlighted parts are example details you can swap.
COMMENT STYLE FOR THIS FILE — Form validation helpers for the signup flow Write comments as forward-looking intent statements immediately above the line they describe, not as after-the-fact descriptions of code already written. State what happens next before writing it — that's what a predictive completion actually reads to guess the following lines; a comment describing code that already exists has nothing left to predict. NAMING CONVENTIONS TO FOLLOW SO COMPLETIONS MATCH THEM Boolean validators are named isX (isValidEmail, isStrongPassword); error messages are named xError (emailError). EXAMPLES OF THE COMMENT STYLE TO MATCH // check password length before checking character variety const hasMinLength = password.length >= 8 TERMS THIS FILE USES FOR RECURRING CONCEPTS — do not introduce a synonym "validate" (not "check" or "verify") for input-rule checks; "field" (not "input" or "control") for a single form value. RULES - One comment per logical step, not one per line — a comment on every line is noise a completion model has to parse through rather than a clean forward signal. - Name the next variable or function before it appears — e.g. "// validate email" immediately before assigning to isValidEmail — so a completion suggesting isValidEmail is reading stated intent, not guessing from indentation and surrounding shape alone. - Don't leave a bare TODO with no reason attached; a TODO with nothing after it gives a completion model nothing to extend correctly and it will either ignore it or guess badly. - Keep the file's existing terms consistent with the glossary above — don't introduce a synonym for a concept the file already names something else, since a completion model weights whichever term appeared most recently and most frequently in the file when ranking a multi-line continuation. - When a completion's suggestion diverges from what you actually meant, don't just overwrite it silently — add or adjust the comment above it so the next similar completion in this file gets it right too, treating a wrong suggestion as a signal about the comment, not just a one-off to dismiss.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Tab's multi-line predictive completion is conditioned heavily on nearby text, comments included, so a comment stating forward intent — "next: validate email format" — gives it a much stronger signal for the next few lines than a comment that only describes code already written, which is backward-looking and useless to a forward predictor: by the time that comment exists, there's nothing left to predict from it. Keeping naming and terminology consistent within a file matters for the same mechanical reason from a different angle: Tab weights recently-seen and frequently-seen tokens in the same file heavily when ranking multi-line continuations, so introducing a synonym for a concept the file already names something else — calling it emailValid in one spot and isValidEmail in another — makes the two compete for the completion's attention instead of the second reinforcing the first, which measurably degrades how often the suggested continuation matches what you'd actually type next. TERMINOLOGY_GLOSSARY stated up front, rather than left implicit in whatever terms happen to already be in the file, matters specifically in a file being actively written or extended, where the "existing" vocabulary a completion model would otherwise infer from is still thin or inconsistent early on — an explicit glossary gives Tab a stable target from the first line rather than one that has to accumulate enough examples in the file before it stabilizes on its own. The final rule — treating a wrong suggestion as a signal about the comment rather than a one-off to silently dismiss — closes a compounding gap: every time a bad completion gets accepted-then-fixed without adjusting the comment above it, the same ambiguous comment is still there to produce the same wrong guess the next time a similar line is written, so the file's completion accuracy never actually improves within a session even though every individual mistake was corrected.
What you get back
// validate email format before checking domain allowlist const isValidEmail = EMAIL_REGEX.test(email)
// check against the blocked-domain list only if the format already passed const isAllowedDomain = isValidEmail && !BLOCKED_DOMAINS.includes(getDomain(email)) // ^ Tab suggested this exact line unprompted after the comment above, reusing // isValidEmail and the isX naming convention rather than inventing emailOk.
Verified against
Cursor 2.2 · 2026-07-20
Changelog
- 2026-07-20 — Initial publish, verified against Cursor 2.2 Tab multi-line completion.
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
