# Live Pair

> Use when you want to iterate on a feature interactively with the user watching a running instance — pair-programming rhythm for UI-heavy work, redesigns, copy tightening, layout exploration, or any "let me just show you what I want" session. Not for systematic audit (/live-exercise) or perf-tuning (/live-perf).

- Skill: `gitkraken/live-pair` (Agent Skill)
- Install (CLI): `npx skillmds@latest add gitkraken/live-pair`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gitkraken/live-pair/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: gitkraken (https://skillmd.com/u/gitkraken)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gitkraken/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

| Skill            | Driver                            | Change pattern                 | Output               | Exit                        |
| ---------------- | --------------------------------- | ------------------------------ | -------------------- | --------------------------- |
| `/review`        | Static                            | —                              | Review findings      | Diff reviewed               |
| `/deep-review`   | Static                            | —                              | Correctness findings | Diff reviewed               |
| `/ux-review`     | Static                            | —                              | UX findings vs goals | Diff reviewed               |
| `/live-inspect`  | Tool primitive                    | —                              | Ad-hoc observations  | —                           |
| `/live-exercise` | **Agent** (sweeps + classifies)   | Parallel dispatch, batch       | findings / decisions | Three-way convergence       |
| `/live-perf`     | **Agent** (measures + classifies) | Parallel dispatch, batch       | baseline / findings  | Measured + conventions done |
| `/live-pair`     | **User** (conversational)         | **One batch per user message** | **Ephemeral (chat)** | **User says "done"**        |

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

| Pitfall                                      | Mitigation                                                                                                          |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Scope creep                                  | User drives. Don't proactively add "and I also noticed…" tweaks. Stay on the message.                               |
| Stale webview state                          | Always refresh via `.refresh` command or `rebuild_and_reload`. Never trust a tweak landed without a new screenshot. |
| Build failure ignored                        | Stop. Fix build first. Everything else blocks.                                                                      |
| Over-summarizing                             | User can see the screenshot. Describe what _changed_, not what's visible.                                           |
| Under-summarizing subtle change              | 4px padding tweak? Call it out in text — the eye may miss it.                                                       |
| Hidden-state changes                         | Commands / package.json / keybindings need full reload. Flag before touching.                                       |
| Structural bug treated as tweak              | Flag early per protocol. Don't silently pivot.                                                                      |
| Extension-host rebuild when webview would do | Check what files you edited. Webview-only edit → webview-only rebuild.                                              |
| Parallel dispatch impulse                    | Never. One change at a time (batched within a message). Dispatch doesn't fit interactive rhythm.                    |
| No verification between rounds               | Every round ends with a new screenshot. Never "I made the change, moving on."                                       |
| Session drift without checkpoint             | If >30 rounds without a commit, pause and suggest a checkpoint commit.                                              |

## 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

| Excuse                                             | Reality                                                                                        |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| "User asked for X but Y is obviously better"       | They didn't ask for Y. Do X, show it, let them decide on Y next round.                         |
| "I know the change worked, skip screenshot"        | User can't see what you can't show. Always refresh + screenshot.                               |
| "I'll batch across messages for speed"             | Breaks the feedback rhythm. One message in → one change + show out.                            |
| "Structural issue, I'll just fix it quickly"       | Flag per protocol. Don't silently pivot from pair to debug.                                    |
| "Build is failing but I can work around it"        | No. Restore the build first.                                                                   |
| "Vague feedback — let me ask clarifying questions" | Iteration IS the clarification. Interpret, show, refine next round. Don't slow the rhythm.     |
| "I should propose options first"                   | Just make the change. The cost of a miss is one round. Options-mode is for bigger decisions.   |
| "I'll add a small improvement while I'm there"     | No. Stay on the message. If you noticed something, mention it in the summary and let them ask. |

## 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