> ## Documentation Index > Fetch the complete documentation index at: https://subtext.fullstory.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # UX Digest: The Top Five Things to Fix, From Real Sessions > One scheduled routine reviews a sample of real sessions, keeps a short ranked list of the patterns it finds, and posts the list to your team's channel only when it changes. Your agent sets it up from this page. Every product has a short list of things most worth fixing this week. Usually nobody writes it down, and the people who could are busy. This recipe has an agent keep that list. On a schedule it reviews a sample of real sessions, folds what it finds into a ranked set of themes, and posts the top five to your channel whenever the list changes. When a theme gets a ticket, the agent that builds the fix can open the same sessions. When the fix ships and the pattern stops showing up, the theme retires on its own. The list is the product. It changes as your product changes, and a new critical pattern goes straight to the top. ## What you need * The **Subtext capture snippet** installed and recording real sessions. Start with [Install the capture snippet](/docs/install/overview) if you haven't. * The official **Subtext plugin** for Claude Code, Cursor, or Codex, which configures the MCP connection and runs inside each harness's scheduling features. Any other agent can connect to the hosted server at `https://api.fullstory.com/mcp/subtext` with an API key. See [Manual install](/docs/install/manual#install-the-subtext-plugin-for-your-agent). * **A place for the list.** Any table your agent can read and write through a tool: a Notion or Airtable database, a Linear project, or a markdown file in your repo. One table is enough. * **A channel** your team already reads and your agent can post to. Slack, most often. * **An agent that can run a prompt on a schedule.** Claude Code, Cursor, and Codex can all create a scheduled routine from inside a chat. ## Set it up Paste this page's link to your agent and tell it what to watch and where to post: ```text theme={null} Read and set up the UX digest for the /checkout and /cart routes. Keep the themes in a Notion database called "UX themes" and post the digest to #product-signals every weekday morning. ``` The agent creates the table, writes the routine below with your routes, table, and channel filled in, and schedules it. Ask it to run the routine once by hand before the first scheduled run so you can see the first digest and the cost. ## The routine This is the prompt the schedule runs. It is written for an agent that has the Subtext tools plus a tool for your table and your channel. Replace the placeholders in braces. ```text UX digest routine theme={null} You maintain the UX theme list for {ROUTES} in {TABLE} and post changes to {CHANNEL}. Run the four phases in order. If a phase fails, stop and post one line saying so. ## 1. Sample Run review-search twice over the time since the last run, each with limit 100: a. sessions that navigated to any of {ROUTES} and had a request with status >= 400 b. sessions that navigated to any of {ROUTES} Merge, dedupe by session id, and keep up to 80, taking the failed-request sessions first. Store each session's URL and start time exactly as returned. If nothing matched, post one line saying so and stop. ## 2. Triage, then open Call review-summary on each sampled session (one credit each). Score each 0-10 on how likely a full review is to find something worth recording. Raise the score for a 5xx, or a 4xx on the request behind the user's own action; a console exception during an action; a page paint far behind load or over 4 seconds when the user reacted by clicking again, reloading, or leaving; a failed action with no retry; repeated searches or filter changes that keep returning nothing; a detour to help docs or support mid-task. Score low for a session under ten seconds with no error, a long idle tail of background polling, repeated 401/403 on a gated feature, and ordinary successful use. If your harness has subagents, summarize in batches of 15 in parallel and return only scores and one-line reasons. Open the top 10 with review-open, plus one clean low-scoring session as a baseline. For each: read the map first, review-zoom on the errors, review-snapshot only when a blank or misleading screen is the point, then always review-close(client_id, use_case="ux_review", was_helpful=...). Most sessions yield nothing. Record a finding only when a reader could act on it: - one specific claim as the title, e.g. "Promo code field accepts input but the total never updates" - the exact figures and endpoint names - one or more codes from: silent-failure, dead-end-state, unhandled-exception, slow-first-paint, slow-task-response, abandon-before-load, wrong-input-target, mode-confusion, unstable-url-state, tool-switch-abandon, usage-concentration, success-path - severity: Critical, High, Medium, Low - the session URL with the evidence moment appended as a third colon segment in absolute epoch milliseconds (session start + offset), so the player opens there Replace customer names, domains, emails, and anything the user typed with , , . ## 3. Update the themes Read every row in {TABLE}. For each finding, match it to an existing theme with at least two codes in common and the same underlying pattern (same route, same failing request, same broken control). Prefer updating over creating; a second theme for the same pattern splits the count and hides it. Otherwise create a theme. On a theme: keep the title under 80 characters; write a one-sentence summary under 160 characters in plain words with no endpoint names; append one evidence line "{date} · {finding title} · {session URL}"; skip a session already in the evidence; set severity to the highest across its evidence; add 1 to this ISO week's count. Never edit an evidence line that is already there. Status rules: - New on create. People move a theme to Ticketed, Fixed, or Closed; you never do. - A Fixed theme that gets new evidence goes back to New with the note "regressed {date}". A Fixed theme with no new evidence for 14 days becomes Verified. Verified and Closed themes still collect evidence but never post. ## 4. Post the top five, only if something changed A theme changed if it is new, its evidence count grew, or its status changed since Last Posted. If no publishable theme changed, post nothing. Otherwise rank the publishable themes (not Verified, not Closed, at least one session link) by severity, then by this week's count, and post the top five as markdown under 5000 characters: ## 🔭 {AREA} · top five · {date} **1. [{title}]({table row link})** · {severity} · {status} · {evidence count} sessions · new {summary} Evidence: [session 1]({url}) · [session 2]({url}) · [session 3]({url}) ... _{n} more themes in {TABLE}._ Mark each theme "new", "↑ {delta}", or leave the marker off if unchanged. Then, and only then, write Last Posted date, count, and status on every theme you posted. ``` ## The table One row per theme. Your agent creates it with these columns. | Column | What goes in it | | ------------- | ------------------------------------------------------------------------------------------- | | Title | One problem statement, under 80 characters. | | Summary | One plain sentence, under 160 characters. The only prose the digest shows. | | Codes | One or more from the list in the routine. Fixed set; the matching key. | | Severity | Critical, High, Medium, Low. Highest across the evidence. | | Status | New, Ticketed, Fixed, Verified, Closed. | | Ticket | The Linear or Jira key, once one exists. | | Evidence | One line per session: date, finding, session link with the evidence moment. Append-only. | | Weekly counts | `2026-W37: 3` per line. Trend reads off this. | | Last posted | Date, evidence count, and status at the last post. The change check compares against these. | ## Closing the loop The list is only useful if things leave it. The path a theme takes: 1. **New.** The routine found it and posted it. Someone reads the summary, opens a session link, and decides. 2. **Ticketed.** A person files a Linear or Jira ticket and puts the key on the theme. The ticket carries the theme's session links, so the agent that picks it up can open the exact sessions and see the failure before writing code. The [Linear triage recipe](/docs/recipes/linear) shows that side. 3. **Fixed.** The person marks the theme Fixed when the change ships. The routine keeps watching. 4. **Verified.** Fourteen days with no new evidence and the routine retires the theme. If the pattern comes back, the theme returns to New marked as a regression and the digest shows it again. 5. **Closed.** Not a bug, by design, or not worth it. A person sets it. The theme keeps counting quietly and never posts. A theme can jump the queue at any point. A new Critical pattern ranks first in the next digest whatever else is on the list. ## Budget Each run spends two credits on search, one per summary, and ten per opened session. At the defaults that is about 190 credits, plus model tokens for the summaries and ten deep reviews. A run on a low-traffic area in the reference build spent 141 credits and roughly \$14.50 in tokens to record 9 findings. Raise the number of opened sessions only after a week of digests shows the extra reviews produce themes people act on. Fifty to eighty summaries is enough to see the patterns behind a targeted search; more mostly re-reads the same ones. ## Check it Ask your agent to demonstrate these before trusting the schedule: * Every `review-open` is followed by a `review-close`, including when the review fails. * Running the routine twice over the same window adds no duplicate evidence lines. * A session link in the digest opens the replay player at the moment the finding names. * A Closed theme gains evidence but never appears in a digest. * A run where no theme changed posts nothing. * A Fixed theme with no new evidence for 14 days becomes Verified without anyone touching it. ## Scaling up The single routine covers one area and one channel. Split it when: * several product areas have different owners and different channels * triage needs to fan out across subagents to stay inside a context window * you want each finding kept as its own immutable row, not a line on a theme * you want a cost ledger per run and a gate that holds the digest when an earlier step failed [UX digest at scale](/docs/recipes/ux-digest-scaled) describes that version: three scheduled agents, an observations table, a run ledger, and per-area digests. ## Related * [Session Review overview](/docs/session-review/overview): what an agent does once a session is open. * [Tools reference](/docs/session-review/tools-reference): `review-search` predicates, `review-open`, `review-zoom`, `review-close` and their credits. * [Linear triage](/docs/recipes/linear): the ticket side of the loop, where a session link on an issue triggers a review.