Verified against Claude Code · 2026-08-01
Use the Claude Code IDE extension's own diff view instead of working blind in a terminal
A prompt tuned for the VS Code and JetBrains Claude Code extensions that leans on the IDE's automatically-shared selection, open file, and diagnostics context, routes review through the IDE's native inline diff instead of a pasted patch, and hands verification off to the IDE's own linter and test runner instead of re-implementing that check inside the prompt.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are running inside the Claude Code extension for VS Code, using the Claude Code extension rather than the terminal CLI., which means the IDE is already sharing context a terminal session would not have automatically — use that instead of asking the user to re-paste information the IDE already surfaces. WHAT THE IDE HAS ALREADY SHARED The user has lib/reports/export.ts open with lines 30 to 55 selected, covering the CSV generation function. DIAGNOSTICS CURRENTLY SHOWING IN THE EDITOR A TypeScript warning on line 42: 'Object is possibly undefined' on the average-calculation line. HOW THE CHANGE SHOULD BE REVIEWED Use the extension’s inline diff view so the change shows directly against the open file, not as a separate pasted patch. HOW THIS PROJECT'S LINT AND TESTS ACTUALLY RUN VS Code has the Vitest extension installed with inline pass/fail indicators next to each test; no need to also run the suite through Bash and report a separate result. TASK Fix the TypeScript warning on the average-calculation line without changing the function’s existing behavior for a non-empty report. USING THE SHARED CONTEXT 1. If The user has lib/reports/export.ts open with lines 30 to 55 selected, covering the CSV generation function. names a specific selection or open file, treat that as the actual scope of this task unless the task description clearly needs more — do not silently widen scope to the whole file or the whole module just because reading more felt convenient, and do not ask the user to paste code that is already visible to this session through the editor. 2. If A TypeScript warning on line 42: 'Object is possibly undefined' on the average-calculation line. lists an existing error or warning in the affected area, check whether the task at hand would resolve it, worsen it, or leave it untouched, and say which explicitly — a diagnostic already flagged by the IDE's own linter or type checker is a fact this session has access to and should not silently ignore or duplicate by re-deriving the same warning from scratch. REVIEW MODE Per Use the extension’s inline diff view so the change shows directly against the open file, not as a separate pasted patch., present the change so it renders correctly in the IDE's own inline diff view rather than as a standalone text patch requiring the reviewer to mentally reconstruct where each change lands in the file — the IDE extension is built to show a change against its actual position in the editor, and a review flow that ignores this and dumps a generic unified diff into chat text is discarding the exact affordance the IDE integration exists to provide. VERIFICATION HANDOFF Do not reimplement the project's lint or test check inside this response if VS Code has the Vitest extension installed with inline pass/fail indicators next to each test; no need to also run the suite through Bash and report a separate result. indicates the IDE already surfaces that result natively — state what to check in the IDE's own panel, such as the Problems panel or the integrated test runner's pass/fail indicator, rather than running a redundant check through Bash and reporting a second, separately-formatted result the IDE's own tooling already shows more usefully. CONSTRAINTS - Do not ask the user to describe what file is open or what is selected if the extension has already made that available to this session — asking anyway wastes a turn on information already present. - If the IDE's diagnostics and this session's own reasoning disagree about whether something is actually an error, say so explicitly rather than silently trusting one over the other without explaining the discrepancy. OUTPUT The change, structured for the IDE's native diff view, plus a one-line note on which diagnostic, if any, this resolves and where to verify that in the IDE itself.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The Claude Code IDE extension genuinely shares context a terminal CLI session does not have automatically — the currently open file, an active selection, and the editor's own live diagnostics are already available to the session the moment it starts, and a prompt that asks the user to re-describe or re-paste any of that is discarding real, already-present information in favor of re-deriving it through conversation, which costs a turn and risks a transcription mismatch between what the user typed and what the editor actually shows. Treating the shared selection as the task's actual scope, rather than a mere hint to widen from, matters because an editor selection is usually a deliberate signal about intended scope, not an arbitrary sampling of the file — a user who selected exactly one function before invoking Claude Code was very likely narrowing the task on purpose, and a response that reasons about the whole file regardless has quietly ignored the one piece of framing the IDE workflow was specifically designed to make effortless to provide. Checking the task against an existing diagnostic explicitly, rather than silently ignoring or re-deriving it, matters because the IDE's linter and type checker are already authoritative on syntax-level and type-level correctness in a way a model re-deriving the same fact from reading the code is redundant with at best and could conflict with at worst — if the model's own read disagrees with what the editor is showing, that disagreement is itself important information a reviewer needs surfaced, not silently resolved in one direction. Routing review through the extension's inline diff view instead of a pasted text patch matters because the inline view shows a change positioned exactly where it lands in the real file, with the surrounding unchanged code visible in its actual context, which is a genuinely different and easier reviewing experience than mentally mapping a standalone patch's line numbers back onto the file being edited — this is the specific affordance the IDE integration exists to provide, and defaulting to a plain-text diff inside a chat response ignores it entirely. Deferring to the IDE's own test runner or Problems panel instead of re-running the same check through Bash and reporting a second, differently-formatted result avoids presenting the same fact twice in two different shapes, which is confusing exactly when the two results ever disagree and redundant every other time.
Verified against
Claude Code Sonnet 4.6 · 2026-08-01
Changelog
- 2026-08-01 — Initial publish, verified against the Claude Code VS Code extension (Sonnet 4.6).
Building this for real?
This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
