Live Pair

/live-pair — Interactive pair-programming with a live instance

Launch the extension. Show the user what's there. Listen for feedback. Edit, rebuild, refresh, show the result. Repeat until the user says done. The user drives; the agent implements. No sweep, no dispatch, no findings doc — just a tight feedback loop.

This is pair programming with a live UI. One message in → one change (or batch) out → one screenshot back.

When to use vs other skills

Pick /live-pair for:

• Redesigning a panel in real time
• Tightening copy / labels across a surface
• Exploring layout or interaction alternatives
• Hands-on UX work: "move this here, shrink that, try a different color"
• Small creative sessions where the user wants to see every change immediately

Pick something else for:

• Systematic audit of a feature → /live-exercise
• Performance measurement + tuning → /live-perf
• Code-only review (no running extension) → /review / /deep-review / /ux-review

Prerequisites

• vscode-inspector MCP connected (auto-discovered via .mcp.json)
• Build currently passes (pnpm run build:quick) — a broken build kills the rhythm
• User is present and responsive — this skill is interactive, not queueable

Interaction model

• Scope: any interactive code change — UI tweaks, extension host, RPC, models. Not artificially constrained to CSS/copy.
• Granularity: one batch per user message. If the user says "move the button AND change the color," do both before rebuild+refresh. Separate messages → separate iterations.
• Structural bugs: flag before patching (see protocol below). Never silently pivot from "pair" to "debug."
• Record-keeping: ephemeral. Conversation is the log; git diff is the source of truth. No findings.md, no iteration-log.md.
• Dispatch: never. This skill uses the Edit tool directly. Parallel fix agents don't fit an interactive rhythm.

Rebuild-scope auto-detection

Infer rebuild strategy from which files got edited — full matrix in /live-inspect § Rebuilding After Code Changes. Bias toward webview-only when possible (build:webviews + the view's .refresh command, no extension reload) — it's much faster than extension-host rebuilds (rebuild_and_reload). For contributions.json / commands / keybindings / package.json changes use build:quick + full reload and warn the user: command registrations may need a fresh session.

The loop

1. Invocation / target selection

• If invoked with a target (/live-pair the home view, /live-pair the compose panel), use it.

• If no target given, ask once:

  "What are we iterating on? Name the feature/view or describe what we're working on."

• Read goals.md if present for context — not as a spec (this skill is user-driven, not goal-compliant).

2. Launch & present current state

1. launch VS Code (skip if already running in this session).

2. execute_command to open the target view.

3. list_webviews + wait_for_webview to confirm Lit hydration.

4. screenshot { target: "webview", webview_title: "<name>" }. If multiple webviews are open and titles are empty/ambiguous, target by webview_url (URL substring like "commitDetails") or webview_index from list_webviews instead — same params on every webview-targeting tool.

5. Present to the user: one sentence on what's on screen + attached screenshot. Invite feedback:

   "What would you like to change?"

3. Iteration round (repeat)

1. Receive user feedback (chat message).
2. Classify the feedback:
   • Single tweak → plan one change.
   • Multiple related tweaks in one message → plan one batch.
   • Structural bug / non-trivial correctness issue → flag before editing (see protocol).
   • Vague ("make it cleaner") → interpret best-guess, make the change, show it. Don't ask clarifying questions — iteration IS the answer. Refine next round.
3. Edit — Edit tool, directly. No dispatch.
4. Rebuild — infer scope per the matrix above. Run the minimal build.
5. Refresh:
   • Webview-only: execute_command gitlens.views.<name>.refresh
   • Extension host: handled by rebuild_and_reload
6. Screenshot new state.
7. Summarize — one sentence on what changed (not what's visible). Attach screenshot. Invite next feedback.

Example round summary:

Moved Share to the top-right and tightened the empty-state copy. Screenshot attached. What's next?

4. Structural-bug flag protocol

If the user's feedback implies a structural or correctness issue (not a visual/copy/layout tweak), flag before patching:

"This looks like a structural issue rather than a tweak. The fix involves [brief reason — data flow, state, RPC contract, etc.], which is better handled under /live-exercise's sweep discipline. Want me to:

1. Delegate to /live-exercise for a proper audit (exits this pair session), or
2. Patch it inline and keep iterating here (lighter ceremony, less rigor)?"

Wait for the user to choose. Don't default.

Signals that feedback is structural:

• "This should fetch X" (data model / RPC)
• "Why isn't it updating when Y changes" (subscription / state)
• "It hangs on Z" (async / concurrency)
• "It crashes when…" (error handling / correctness)
• "The API for this should be different" (architecture)

Signals that feedback is a tweak (stay in /live-pair):

• "Move this," "change this color," "tighten this copy," "swap these two," "make this bigger," "hide this when empty"

5. Build failure handling

If rebuild fails, stop iterating. A broken build kills the rhythm.

1. Read the build error (command output).
2. Show it to the user with a short diagnosis (one line: "TypeScript error in X — missing import").
3. Propose a fix direction (one sentence).
4. Wait for user guidance. Don't charge ahead with another edit. Don't try to "work around" a broken build.
5. Once fixed and build passes, summarize + screenshot + resume the rhythm.

6. Exit

User signals done via "done," "that's it," "ship it," "looks good," "stop," or similar.

On exit:

1. git diff --stat — show the summary (files changed, line counts).

2. Offer to commit:

   "Ready to commit these changes? Suggested message: [derived from conversation]. Or do you want to review the diff first, or continue iterating?"

3. If the user accepts, use /commit. If not, leave the working tree as-is.

4. teardown VS Code session (or leave running if the user prefers).

Pitfalls

Red flags — pause the loop

• About to make a structural change without flagging it to the user
• About to rebuild extension host when a webview refresh would cover it
• Build is failing and you're queuing the next edit instead of fixing the build
• About to summarize a round without a new screenshot
• Proactively "also fixing" things the user didn't ask about
• Interpreting a non-trivial bug as a tweak because it's easier to stay in the rhythm
• Session >30 rounds with zero commits — suggest checkpoint

Tripwires for "dropping the interactive rhythm"

Any of these in your reasoning = stop, don't break the pair dynamic.

• "I already know this will work, skip the screenshot"
• "I'll batch across messages for efficiency"
• "I'll interpret vague feedback and also add improvements they'd probably want"
• "The user won't mind if I fix this adjacent bug too"
• "The build's broken but the change is still good — moving on"
• "This looks structural but I'll just fix it inline quickly"

These all break the contract. The contract: user drives, one message = one change (or batch), every change ends with evidence (screenshot + diff).

Rationalizations to resist

Before declaring "live-pair complete"

Before reporting, confirm you have:

1. Ended every round with a fresh screenshot — no "done, trust me"
2. Flagged every structural-bug detection before patching
3. Kept the build green — no in-flight broken builds when ending
4. Offered a commit before teardown (user can decline)
5. Summarized succinctly — changes not visible, not descriptions of the screenshot

Output artifacts

• None by default. The conversation is the log.
• Working tree with the iterated changes (committed or staged, per user choice at exit)
• Final git diff summary shown at exit

Related skills

REQUIRED BACKGROUND:

• /live-inspect — primitive MCP tools (launch, screenshot, execute_command, rebuild_and_reload, refresh commands)

Related:

• /live-exercise — agent-driven audit counterpart; delegate here on structural issues
• /live-perf — agent-driven perf counterpart; delegate here on "this feels slow"
• /commit — exit-time commit of the session
• /simplify — code-quality cleanup if iteration accumulated drift