Selection Driven Prompt

What it is. A selection driven prompt starts with the user selecting an object in the main interface then opens a prompt surface that already carries that selection as structured context. The model receives both the natural language instruction and a direct reference to the selected item whether it is a canvas region, a code block, highlighted document text, or a database record. The selection appears inside the prompt surface as a visible chip or thumbnail complete with preview, confidence indicator, and controls to adjust or dismiss it. This removes the translation tax that forces users to describe what they already pointed at.

The pattern integrates with every part of a real prompt surface. The attachment slot holds the live selection. Inline tool toggles sit beside it so the user arms edit mode or variant mode before sending. The streaming output region highlights exactly what changed in the original selection. Revision controls treat each update as a branch that keeps the selection pinned. In 2026 tools that ship this correctly turn vague commands into surgical ones. Cursor, v0, Notion AI, and Linear all raised the bar here. The visible binding becomes the primary trust signal. The user sees the exact context before hitting send instead of hoping the model guessed right.

This is one of the six core patterns in the prompt surfaces library because it attacks context loss at the root. Older interfaces made users paste screenshots, repeat file names, or write long descriptions that burned tokens and introduced errors. Selection driven prompt replaces all of that with a direct handoff. The surface treats the selection as a first class primitive not an afterthought. When executed well it composes with scoped prompt for nested targets, memory chips for session rules, and approval gated tool calls for risky edits. The entire component starts to feel like architecture instead of a bolted on chat box.

What it isnt. A selection driven prompt is not highlighting something and then typing into a generic chat window that might remember the highlight. It is not pasting a screenshot into a blank textarea and hoping the model understands the image. It is not a system that drops the binding on the first regenerate or converts the selection to flat text inside the system prompt. Those versions waste context and destroy precision.

It is also not the same as a scoped prompt. Scoped prompt uses tokens like the at symbol after the surface opens. Selection driven prompt begins with the selection and opens the surface in response. Confusing the two produces half implementations where the chip looks correct but the backend sends stale data. Any surface that hides the binding, offers no preview, or forces the user to re describe the target on turn two has failed the pattern completely. It has simply added theater on top of a 2022 textarea.

Concrete example. Open v0 in 2025 and generate a SaaS dashboard. Draw a marquee around the analytics chart. The prompt surface slides up from the canvas edge with a coral chip labeled Analytics Chart already attached. The chip shows a thumbnail of the current chart, a small confidence meter, and buttons to expand or crop the selection. The designer types update this chart to a bar style with brand colors and add a tooltip that shows exact values. She hits send. The model revises only the selected chart while the rest of the dashboard stays untouched. The streaming output renders live on canvas and the prompt surface stays open for the next selection. Total time from selection to updated chart is under ten seconds.

Notion AI shipped an early version in 2024. Highlight six paragraphs across two columns in a product requirements document. Invoke AI. The surface opens with each paragraph represented as linked chips. Choose Extract user stories from the suggestion row and the model pulls only from the bound blocks. No copy paste. No re explanation of which text mattered. Linear AI does the same inside an issue. Select three comments plus the acceptance criteria then open the composer. The prompt surface auto binds the current issue plus the selection so the instruction rewrite these comments to be more actionable lands with perfect context.

Cursor took the pattern to code in 2025. Select a React hook that keeps causing infinite loops. The composer opens with the full function pinned at the top plus the two components that consume it. The prompt change this to useReducer and update the callers produces deterministic output because the model never had to guess which hook or which callers. Each of these examples shows the same truth. When the product already knows what the user clicked it is malpractice to make them describe it again.

When to use / when not to. Use selection driven prompt whenever users manipulate discrete visible objects inside complex files or canvases. Deploy it in design tools for layer groups, code editors for functions, document editors for text blocks, and data tools for query results. It delivers maximum value during tight iteration loops where the user evaluates a change then refines the same object again. Pair it with the full prompt surface anatomy including visible model pickers, stop buttons during streaming, and branching history. Run the seven question audit from the parent article. A surface that passes all seven after adding selection binding feels like a 2026 primitive.

The pattern also shines when combined with the other five named patterns. Add inline tool toggles so the user chooses between edit in place and generate new variant. Surface a memory chip that carries project brand guidelines across every selection. Gate destructive changes behind an approval step that shows the exact diff before execution. Teams that ship five or more of these patterns together win the UX bar that Cursor and Claude set in 2024 and 2025.

Do not use selection driven prompt for open ended exploratory work that has no clear target. High level strategy prompts, broad research questions, and initial brainstorming sessions need strong empty states and suggestion systems instead. Skip it in mobile interfaces where precise selection creates too much friction. Never ship it if your backend cannot maintain stable object references across multiple turns. A broken binding that silently sends stale data creates worse outcomes than no binding at all because it trains users to trust a lie. Avoid forcing it in dense interfaces where overlapping selections become ambiguous. Test every implementation against the six failure modes in the prompt surfaces article. If the surface still behaves like an empty rectangle after a selection is made then redesign before you ship.

Stop making users describe in words what they have already pointed at with their cursor.