Preview toolbar as the primary interaction surface — adaptive "Ask Claude…" + Pin baseline buttons #43
Notifications
Due Date
No due date set.
Blocks
#41 Open Cowriting Review Panel from the markdown file/tab right-click menu
benstull/vscode-cowriting-plugin
#42 Ask Claude to Edit Document — whole-document edit from body (no selection) + tab right-click
benstull/vscode-cowriting-plugin
Reference: benstull/vscode-cowriting-plugin#43
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Make the rendered review preview the primary interaction surface: its toolbar
(home of the existing annotations on/off checkbox) gains a single adaptive
"Ask Claude…" button — Edit Selection when text is selected in the preview,
Edit Document when nothing is selected — and a "Pin baseline" button, so a
writer drives the whole inner loop from the preview without leaving it.
Problem / pain
The plugin's interactions are scattered across surfaces and inconsistently
reachable: "Ask Claude to Edit Selection" is only a selection-gated editor
context-menu item, whole-document editing doesn't exist yet, and "Pin Review
Baseline to Now" is registered but unreachable from any UI (palette-hidden
since #34 removed its two-pane host, no menu, no keybinding). The one control the
writer does love — the annotations on/off checkbox in the preview — proves
the preview toolbar is the natural home for these gestures, but it stands alone.
A writer reviewing in the preview has to jump back to the editor and hunt through
menus/palette to act.
Who feels it
Writers using the rendered preview as their review surface — the plugin's central
workflow — who want to read, ask Claude to edit, and reset the baseline all in one
place, mouse-first.
Desired outcome / value
The preview becomes a self-contained cockpit for the inner loop. From its
toolbar a writer can toggle annotations (today), ask Claude to edit (selection or
whole document, via one button that adapts to what's selected), and pin a fresh
baseline — no context-switching to the editor or command palette. Consolidates
the interaction model around the surface the writer already prefers.
Acceptance — "done right"
checkbox:
with a selection in the preview it reads "Ask Claude to Edit
Selection" and scopes the edit to that selection's source range; with no
selection it reads "Ask Claude to Edit Document" and scopes to the whole
document.
document state (invokes the existing
cowriting.pinDiffBaselinebehavior),giving that orphaned command a real home.
preview as they do today.
the file/tab right-click (#41 / #42) opens the review preview window (and,
for the Ask-Claude entry, lands the writer on the preview where the action
completes) — the menus are gateways into the preview, not a separate surface.
(markdown / authorable).
flips with preview selection state and produces the right-scoped proposal, Pin
baseline empties the change-marks, and a right-click entry opens the preview.
Scope / non-goals
baseline button) beside the existing annotations checkbox; wiring those controls
to the existing edit seam, attribution, and baseline commands; making the
#41/#42 right-click entries open the preview.
F6 baseline store; no removal of the native context-menu entries (they coexist
as gateways); no multi-file/batch editing; the Explorer tree itself stays as-is
(entry is via #41/#42's menus).
Assumptions · constraints · dependencies
so "Edit Selection" must map a selection in the rendered preview back to a
source markdown range. This is the main thing the design step must settle;
a sensible fallback is to ship the document-level button first and add
selection-awareness second.
toggle, the F3 attribution + F4 propose/accept inner loop, and the F6 baseline
store (
cowriting.pinDiffBaseline, currently unreachable — this feature givesit UI).
#42 (right-click → Ask Claude to Edit) — those become the menu gateways that
open this preview; this feature is the in-preview control surface they lead to.
Also resolves the pin-baseline reachability gap surfaced this session.
Source / signal
Self-originated — capture session vscode-cowriting-plugin-0035 (operator ask:
"Can we set it up so all interactions — Ask Claude to Edit Selection / Edit
Document, annotations off/on, Pin new baseline — are via the preview window? I
like the annotations checkbox up there; make the others buttons, with one
'Ask Claude…' button that changes depending on whether some of the markdown
preview is selected"). Coexistence + right-click-opens-preview confirmed in
session.
Priority (WSJF)
Value (high — defines the product's primary interaction model around the surface
the writer prefers) · Time-criticality (med) · Opportunity-enablement (high —
unifies edit/annotate/baseline and unlocks the stranded pin command) ÷ Size
(medium, dominated by the preview-selection → source-range mapping) → strong
score.
priority/P1.Decomposition
cowriting.pinDiffBaseline(immediate win — gives the orphaned command a home).Solution notes (optional — NOT a design)
A natural sequencing: land Pin-baseline and the document-level Ask-Claude button
first (both are straightforward webview→command wiring), then tackle the
preview-selection→source mapping that makes the button selection-aware. The
toolbar already renders the annotations checkbox, so the buttons join an existing
host rather than introducing a new chrome. Non-binding — the design step owns the
selection-mapping approach and the exact toolbar layout.
Shipped to
mainvia PR #44 (session 0037). The preview toolbar is now the primary interaction surface: Pin baseline + a single adaptive Ask-Claude button (Edit Selection ⇆ Edit Document), block-level selection→source mapping (INV-36), document edits diffed into per-hunk F4 proposals (INV-37), the editor/title gateway, and the unhidden pinDiffBaseline. 208 unit + 9/9 F11 host E2E green. Live smoke: docs/MANUAL-SMOKE-F11.md.