Skill

Review session recordings with evidence-based findings

clarity-session-review turns Microsoft Clarity replays into triangulated findings instead of timeline-read anecdotes.

Works with clarityclaude

91
Spark score
out of 100
Updated 2 months ago
Source checked Sep 17, 2026
Version 1.0.0
Models
claude

Add to Favorites

Why it matters

Transform Microsoft Clarity session replay analysis from anecdotal storytelling into a rigorous, evidence-backed investigation process that triangulates replay data with database records and source code to produce verifiable findings instead of confident-but-wrong conclusions.

Outcomes

What it gets done

01

Attribute anonymous Clarity sessions to real users by joining session-entry URLs with your product database

02

Triangulate replay observations against database state and frontend source code to verify every load-bearing claim

03

Run periodic session-intelligence reports across all recordings using a resumable multi-agent workflow with triage, watch, and adversarial refutation phases

04

Conduct targeted investigations with dead-click analysis, thin-session forensics, and UI-clarity reviews that ship with evidence coordinates for two-minute verification

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/bayramannakov-clarity-session-review | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

Clarity Session Review

clarity-session-review is a discipline for reviewing Microsoft Clarity session recordings via question-scoped triage, attribution, replay-watching, and database and source triangulation, producing evidence-linked findings instead of timeline-read anecdotes, built after replay-watching reversed four confident timeline conclusions in one investigation. Use it for a targeted investigation into a specific user's behavior or a recurring session-intelligence report over all sessions in a window - not as a substitute for Clarity's own analytics tooling.

What it does

clarity-session-review is a discipline for reviewing Microsoft Clarity session recordings that produces findings, not anecdotes, structured as question-scoped triage, attribution, replay-watch, database and source triangulation, and a verifiable evidence appendix. It runs as a Claude Code/Codex skill, a SKILL.md the agent loads on demand, but reads as a plain playbook for a human too. It exists because replay-watching once overturned four timeline-based conclusions in a single investigation: a user filed as "bailed at the redirect" had actually spent two minutes inside the hosted OAuth flow; a "five-day starer" was a hidden background tab; a "never-returned" user had returned; and a dramatic "48-minute struggle session" was an internal teammate's own browser - all four were read straight off the Clarity event timeline, and only reversed once checked against replays, the product database, and the frontend source. The skill encodes seven principles, each attributed to a specific mistake that paid for it: question before player, since no discriminating question means no watching; attribute before interpreting, since Clarity has no identify() so session-entry URLs usually carry identity and must be joined to the database before interpretation; a replay alone is a story, replay plus database plus source code is a finding, so every load-bearing claim gets triangulated; TIMELINE does not equal REPLAY, since API timelines are truncated and masked so their counts are floors and a timeline read must never be presented as watched; every claim ships with its evidence coordinates - link, timestamps, and what to check - so verification is a two-minute job; count people, not sessions, since Clarity fragments one visit into many sessions (one user showed up as 59) and 50-60% of a pull is thin bounces, so a run of 462 sessions turned out to be about 26 real people, and that's the number to lead with; and audit what the UI shows, not only what users click, since the method is behavioral and blind to a misleading label or a dead-end status, requiring a source-lint of the label code to catch those, marked provisional.

When to use - and when NOT to

Use it in two modes: targeted investigation for a specific question such as "why did user X churn," "verify the fix," or "what did this user do before the call," run directly through the pipeline, or periodic census, the recurring session-intelligence report over every session in a window, orchestrated as a resumable multi-agent workflow - scout, triage fan-out, serial watch, synthesize plus adversarial refute. The skill auto-loads when asked to "watch recordings," "check Clarity," "review all sessions," "why did users drop off," "verify the fix," or "run the dead-click review." It is explicitly not a Clarity API wrapper or scraper - it's the judgment layer on top of Clarity's own tools (MCP, API, dashboard) - and it is not a substitute for analytics; it's the replay discipline that explains what aggregate numbers can't, and names what the instrument is blind to.

Inputs and outputs

Five files make up the skill: SKILL.md itself, covering the seven principles, the two modes, the pipeline, the report contract, a replay-semantics gotcha list, cadences, and blind spots; references/method.md for per-session mechanics and standing modules, including a Clarity-instruments toolkit noting recordings are just one of roughly ten instrument families, thin-session forensics, dead-click analysis with a verify-first gate since a dead-click count is not a defect count, and a UI-clarity review; references/periodic-review.md for the Mode B recurring report workflow; ADAPTING.md, an eight-item checklist for wiring the method to a specific product, such as the URL-to-identity join, the product's own database, its exclusion list, and its source paths; and examples/, a templatized, data-driven report generator. Output is a findings report where every claim carries evidence coordinates - a link, timestamps, and what to check - rather than a narrative summary.

Integrations

Sits on top of Microsoft Clarity's own tooling (MCP, API, dashboard) as a judgment layer rather than replacing or wrapping it; installed by cloning the repo and symlinking it into an agent's skills directory, for example ln -s "$PWD" ~/.claude/skills/clarity-session-review for Claude Code, so updates propagate automatically.

Who it's for

Anyone using Microsoft Clarity session recordings to investigate a specific user behavior or run a recurring session-intelligence report, who wants a checklist that defaults to triangulated findings instead of a confident, wrong story read straight off an event timeline. It is MIT licensed, distilled from real practice, with battle-tested principles and anonymized examples.

Source README

clarity-session-review

A reusable agent skill for reviewing Microsoft Clarity
session recordings the way that produces findings, not anecdotes - and doesn't
let a half-trusted event timeline become a confident, wrong story.

It's a discipline, not a dashboard: question-scoped triage → attribution → replay-watch
→ database/source triangulation → a verifiable evidence appendix. It runs as a
Claude Code / Codex skill (a SKILL.md the agent
loads on demand), but the method reads fine as a plain playbook for a human, too.

Why it exists

It was born the day replay-watching overturned four timeline-based conclusions in a
single investigation:

  • a user filed as "bailed at the redirect" had actually spent two minutes inside the
    hosted OAuth flow
    ;
  • a "five-day starer" was a hidden background tab;
  • a "never-returned" user had returned;
  • a dramatic "48-minute struggle session" was an internal teammate's own browser.

Every one was read straight off the Clarity event timeline. Watching the replays - and
checking them against the product database and the frontend source - reversed all four.
This skill is the checklist that makes that the default, not the lucky exception.

The eight principles (each one paid for by a specific mistake)

  1. Question before player. No discriminating question → no watching.
  2. Attribute before interpreting. Wire Clarity's Identify API if you can - it's
    the first-class join. Until then, session-entry URLs usually carry the identity -
    join it to your database before you interpret anything.
  3. A replay alone is a story; replay + database + source code is a finding.
    Triangulate every load-bearing claim.
  4. TIMELINE ≠ REPLAY. API timelines are truncated and masked - treat their counts as
    floors; never present a timeline read as watched.
  5. Every claim ships with its evidence coordinates - link + timestamps + what to
    check. Verification should be a two-minute job.
  6. Count people, not sessions. Clarity fragments one visit into many "sessions" (one
    user showed up as 59); on our runs 50-60% of a pull was thin bounces. One run's 462
    sessions was ~26 real people - lead with that number.
  7. Audit what the UI shows, not only what users click. The method is behavioral and
    blind to a misleading label or a status with no next action; a source-lint of the
    label code catches those. (Provisional.)
  8. Walk the step before you explain it. Before theorizing about any step, execute it
    yourself on the real product, end to end. Replays tell you WHERE people stop; only
    walking tells you WHAT you were asking of them. A partial walk is worse than none -
    it manufactures confidence: one halted at a credential field and published a careful
    account of the ask, missing that the real ask was a password and a live 2FA code. If
    you can't finish a step (credentials, payment, a third-party account), hand it to a
    human for full-path screenshots - never infer a flow's tail.

What's inside

File What it is
SKILL.md The skill: the eight principles, the two modes, the pipeline, the report contract, the replay-semantics gotcha list, the cadences, and the blind spots.
references/method.md Per-session mechanics + the standing modules: the Clarity-instruments toolkit (recordings are 1 of ~10 families), thin-session forensics, dead-click analysis (with a verify-first gate - a dead-click count is not a defect count), the UI-clarity review, the discovery modules (first-session comprehension · input-struggle/abandoned-intent · person-arc/return-visit · success-session shape), and a date-stamped Clarity-facts appendix.
references/periodic-review.md Mode B - the recurring "session-intelligence report" over ALL sessions in a window, as a resumable multi-agent workflow (scout → triage fan-out → serial watch → synthesize + adversarial refute).
ADAPTING.md The eight-item checklist to wire the method to your product (URL→identity join, your database, your exclusion list, your source paths…).
examples/ A templatized, data-driven report generator.

Two modes

  • Targeted investigation - a specific question ("why did user X churn", "verify the
    fix", "what did this user do before the call"). Run the pipeline directly.
  • Periodic census - the recurring report over every session in a window. Same
    principles, orchestrated as a resumable multi-agent workflow.

Install (as an agent skill)

Clone, then symlink (so updates propagate) or copy into your agent's skills directory:

git clone https://github.com/BayramAnnakov/clarity-session-review
cd clarity-session-review

# Claude Code (global skills)
ln -s "$PWD" ~/.claude/skills/clarity-session-review

Then adapt it to your product with the ADAPTING.md checklist. The
skill auto-loads when you ask your agent to "watch recordings", "check Clarity", "review
all sessions", "why did users drop off", "verify the fix", or "run the dead-click review".

Not using an agent? Read SKILL.md and the references/ top-to-bottom - it's a
complete manual method.

What this is not

  • Not a Clarity API wrapper or a scraper - it's the judgment layer on top of Clarity's
    own tools (MCP, API, dashboard).
  • Not a substitute for your analytics - it's the replay discipline that explains what
    the aggregate numbers can't, and names what the instrument is blind to.

Credit & license

Distilled from real practice by Bayram Annakov.
This is a public snapshot of a living internal skill - the principles are battle-tested;
the examples are anonymized. Contributions and adaptations welcome.

MIT - see LICENSE.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.