---
name: lisa-product-walkthrough
description: "Methodology for evaluating the live product when planning work or evaluating a PRD. Reading a PRD or a mock without seeing the current product produces tickets that misjudge the change — this skill grounds the analysis in what actually exists today. Driving the product is owned by the `use-the-product` core (which detects the product type — DOM web, HTTP/API, canvas game, CLI, IaC — resolves the per-environment mutation policy from .lisa.config.json so production is never mutated by accident, and explores through the project's personas when defined); this skill adds the planning lens. Invoke from notion-to-tracker (Phase 2b live-product walkthrough), jira-create, and any PRD intake flow whose work touches existing user-facing surfaces."
allowed-tools: ["Skill", "Bash", "Read", "mcp__plugin_playwright_playwright__browser_navigate", "mcp__plugin_playwright_playwright__browser_snapshot", "mcp__plugin_playwright_playwright__browser_take_screenshot", "mcp__plugin_playwright_playwright__browser_click", "mcp__plugin_playwright_playwright__browser_type", "mcp__plugin_playwright_playwright__browser_select_option", "mcp__plugin_playwright_playwright__browser_fill_form", "mcp__plugin_playwright_playwright__browser_press_key", "mcp__plugin_playwright_playwright__browser_hover", "mcp__plugin_playwright_playwright__browser_navigate_back", "mcp__plugin_playwright_playwright__browser_resize", "mcp__plugin_playwright_playwright__browser_tabs", "mcp__plugin_playwright_playwright__browser_console_messages", "mcp__plugin_playwright_playwright__browser_network_requests", "mcp__plugin_playwright_playwright__browser_wait_for", "mcp__plugin_playwright_playwright__browser_close"]
---

# Live Product Walkthrough

Reading a PRD or a mock without seeing the current product produces tickets that misjudge the change. This skill defines how to evaluate the live product *before* planning tickets, so the work is grounded in what actually exists today.

**How you drive the product is owned by the `use-the-product` core skill** — it detects the product type (web / API / game / CLI / IaC), resolves the target environment and its **mutation policy** from `.lisa.config.json`, and discovers the project's **personas**. A walkthrough is read-leaning: prefer the policy's **read-only** actions, and only mutate when both the policy allows it (`full`) and a flow genuinely can't be understood without it. This skill adds the **planning lens** below.

## When to invoke

Always run a walkthrough when the work touches user-facing surfaces:

- The PRD describes a change to an existing screen, flow, or interaction
- The PRD adds something *next to* existing functionality (entry points, navigation, related surfaces)
- A mock or prototype implies a re-style or re-flow of something currently shipped
- The change is a "bug" framed as a fix to current behavior — you must see the current behavior before reasoning about the fix

Skip when the work is purely internal (type-only, doc-only) or affects a surface that does not yet exist in production / dev.

## 1. Plan the walkthrough

Before driving anything, list the surfaces the change will touch:

- Which screens/routes/endpoints are involved (current and new)?
- Which user roles need to be exercised (admin / customer / etc.)?
- Which states matter (signed-out, signed-in, empty, populated, error, loading)?
- For a DOM web app, which viewports matter (desktop always; mobile when responsive)?

Write this list down. If you can't, the PRD is too vague — note it as a coverage smell and surface it as an Open Question on the resulting ticket.

## 2. Drive the current product

**Invoke `use-the-product`** to detect the type, resolve the environment + mutation policy, and discover personas — then drive the surfaces from step 1 through its per-type playbook (browser for DOM, `curl` for an API, canvas+input for a game, `cdk synth`/`diff` for IaC). Capture evidence as you go: for a DOM app, a `browser_snapshot` (accessibility tree — best for reasoning) and a `browser_take_screenshot` (visual) per surface and per state, plus `browser_console_messages` / `browser_network_requests` after interactions; for an API, representative request/response pairs; for a game, screenshots of each state. If the project defines personas, walk the surfaces as the relevant archetype(s).

When the resolved DOM environment is non-production with mutation policy `full` and the configured Kane provider passes `lisa kane probe`, `use-the-product` may delegate the bounded journey to `lisa-kane-browser`. Extract its screenshot, HAR/network, console, and result artifacts into the normal Current Product evidence. Never use the expiring Test Manager link as the only evidence. A walkthrough that resolves `read-only` stays on a directly controlled browser backend during the initial Kane rollout.

Honor the mutation gate: on a `read-only` env, observe without submitting; never walk a `forbidden` env (production defaults to forbidden). Treat console errors, 4xx/5xx, and unexpected calls as findings.

## 3. Record findings

For every walkthrough, record:

- **What exists today**: a short prose description of the current flow, the components/endpoints in use (identify them from the snapshot/routes where you can), and the states observed.
- **What the PRD changes**: explicit delta — added / removed / modified surfaces, new/removed states.
- **Existing-component reuse candidates**: components or endpoints in the current product that could absorb the new behavior (see `lisa-tracker-source-artifacts` §7).
- **Design-vs-current-product divergence**: where the mock/prototype materially diverges from what's shipped. Each divergence is a discussion item, not an automatic rebuild (see `lisa-tracker-source-artifacts` §3).
- **Coverage smells**: states the PRD doesn't address that exist today (e.g. the mock shows the empty state but ignores the populated state 90% of users see).
- **Behavioral surprises**: anything that doesn't match the PRD's assumptions about current behavior — usually the most valuable findings, because they invalidate parts of the PRD.

## 4. Attach evidence and close

Capture evidence so the originating ticket / Notion comment / PRD review can reference it. Close the session when done (`browser_close` for a browser) — walkthroughs are short, focused, and one-shot.

- For **PRD intake**: include a "Current Product" comment on the Notion PRD with the findings prose and inline screenshots alongside each affected surface.
- For **ticket creation**: include the findings under `## Current Product` in the ticket description (Story or Epic). Reference screenshots as remote links or attachments.
- For **change-impact analysis**: produce a short report; the consuming skill decides where it lands.

## Findings format

Use this structure when emitting walkthrough findings, so consuming skills can splice them into tickets / comments unchanged. The `## Current Product` heading matches what `lisa-jira-write-ticket` Phase 4e expects to inherit — keep the heading exact.

```text
## Current Product

**Environment**: <target> as <account/role> (<mutation level>)
**Explored as**: <persona(s) or "generic representative user">
**Viewports exercised**: Desktop 1512×768, Mobile 375×812   (DOM web only)

### Surfaces walked
1. <route/endpoint/screen> — <one-line current behavior>
2. <route/endpoint/screen> — <one-line current behavior>

### What exists today
<2-4 sentence prose summary of the current flow and components/endpoints in use>

### Delta vs. PRD
- ADDED: <new surface/state from PRD>
- MODIFIED: <existing surface, with the change>
- REMOVED: <existing surface PRD removes>
- UNCHANGED-BUT-IMPACTED: <existing surface PRD doesn't mention but will be affected>

### Existing-component reuse candidates
- <component / endpoint / screen> — could absorb <new behavior>

### Design-vs-current-product divergence
- <mock or prototype reference> diverges from <current surface> in: <specific dimension>
- Recommendation: <reuse / new build / discussion>

### Coverage smells & behavioral surprises
- <smell or surprise>

### Evidence
- <list of screenshots/snapshots/request-response pairs, with captions>
```

## Rules

- Walk before you write. If the work touches existing user-facing surfaces and the walkthrough wasn't done, the resulting ticket is missing context — don't ship it.
- Never walk a `forbidden` environment (production is forbidden by default). Use `dev`/`staging` per the `exploration` config, and default to read-only for a planning walkthrough.
- Treat console errors and unexpected network calls as findings — they often reveal undocumented behavior the PRD assumes is fine.
- Findings drive `## Open Questions` on tickets, not silent assumptions. If the current product contradicts the PRD, surface it as a BLOCKER.
- This skill captures observations; it does not edit the tracker or the PRD. Consuming skills decide where findings land.
