Update to Subtext

{
  "name": "subtext-review",
  "description": "Review a completed Subtext session and produce a structured summary. Use when you have a session URL and want to understand what happened — verify a flow, walk through a dev / staging / preview session, or summarize a captured session. Optionally emits reproduction steps on request.",
  "included_files": [],
  "skill_md_contents": "---\nname: subtext-review\ndescription: Review a completed Subtext session and produce a structured summary. Use when you have a session URL and want to understand what happened — verify a flow, walk through a dev / staging / preview session, or summarize a captured session. Optionally emits reproduction steps on request.\n---\n\n# Review\n\n> **PREREQUISITE:** Read `subtext-shared` and `subtext-session` for tool conventions.\n\n**Type:** Workflow — goal-oriented with decision logic.\n\nReview a completed session and produce a structured summary of what happened. Optionally emit reproduction steps when the user asks. Review is read-only analysis.\n\n## When to use\n\n**Use when:**\n- The user provides a session URL and wants to know what happened.\n- The user asks for a walkthrough, summary, or diagnosis of a session.\n- Session source is any of: local dev, staging, preview, production.\n\n**Skip when:**\n- The user wants the repro *executed*, not just described — that needs a live browser (the separate Subtext Verify plugin).\n\n## The loop\n\n### Step 1: Open the session\n\nCall `review-open` with whichever identifier you have — see `subtext-session` for the six accepted forms. Capture the `client_id` from the response, and read the **map** it returns — signal counts by kind/tag and page flow. Don't call `review-zoom` yet.\n\n### Step 2: Form hypotheses from the map\n\nThe map is the orientation layer. Before zooming, ask: does anything in `kinds`/`tags` stand out (an `error:` count, an unusually dense phase)? Form one or two hypotheses about what happened — that's what you zoom to confirm.\n\n### Step 3: Zoom to confirm — as recipes, coarse to fine\n\nUse `review-zoom` with a `resolution` map. Treat resolutions as recipes, not parameters to memorize:\n\n- Errors anywhere → `resolution={ error: \"standard\" }`\n- What happened overall → `resolution={ navigation: \"standard\", interaction: \"standard\" }`\n- Devtool-level detail on a suspect window → `resolution={ network: \"machine\", console: \"machine\" }`, narrowed with `t0_ms`/`t1_ms`\n\nStart coarse (`standard`, the default) and only reach for `machine`/`detail` on the specific kind or tag your hypothesis needs — each step down costs more tokens for more fidelity. Judge coverage against the map from `review-open` (its `kinds`/`tags` counts); `review-zoom` returns the signal slice.\n\nWhen you need to see the screen itself — confirm a layout, grab a component tree — use `review-snapshot` at the timestamp in question. It's a separate data set from signals; don't expect it to carry network/console detail.\n\nDon't sweep the entire session frame-by-frame — that's expensive and usually unnecessary. Lead with the map and the errors it surfaces.\n\n### Step 4: Assess\n\nForm a judgment on:\n\n- **What the session was trying to accomplish** — inferable from behavior.\n- **Did it succeed** — any errors? Did the final state match the apparent intent?\n- **Notable moments** — anything surprising, confusing, or worth flagging to the user.\n\n### Step 5: Produce the structured summary\n\nOutput in this shape — stable sections make the result easy to consume, especially for a downstream agent:\n\n```markdown\n## Session Summary\n\n**Session:** <URL>\n**Type:** <dev | staging | preview | production>\n**Duration:** <if available>\n\n### What happened\n<One-paragraph narrative of what the user/agent tried to do.>\n\n### Errors\n<Timestamped list with context, or: \"None observed.\">\n\n### Key moments\n- `<timestamp>` — <inflection point>\n\n### Assessment\n<One paragraph. Did the session achieve its apparent goal? Anything the next reader should know?>\n```\n\n### Step 6: Reproduction steps — only if asked\n\nIf the user explicitly asks to reproduce, append a structured step list. **Do not execute** — this plugin is read-only. Executing a repro requires driving a live browser, which lives in the separate Subtext Verify plugin.\n\n```markdown\n### Reproduction steps\n\n1. Navigate to <URL>\n2. <action> — e.g., \"Click the 'Sign in' button\"\n3. <observation to confirm> — e.g., \"Verify modal appears within 2s\"\n```\n\nWrite the steps as deterministic actions: concrete selectors, URLs, and assertions. Avoid subjective instructions (\"look around\").\n\n## Decision logic\n\n### Errors present\n\nAlways lead with errors. A downstream reader — human or agent — will look for this section first.\n\n### Repro steps requested\n\n- \"reproduce\", \"repro\", \"walk me through step by step\", \"how do I hit this\" → produce the step list in Step 6.\n- \"review\", \"summarize\", \"what happened\" → stop at Step 5. Don't volunteer repro steps; they add length without being asked for.\n"
}