comparisons

comparisons is a skill for Claude Code from reatlat/fullstory-claude-plugin. It costs 40 tokens per session (1,057 once invoked), scanned A, original, MIT.

A guide to comparing two groups in Fullstory, a tool for studying how people use a website or app. It explains when to group individual events by their properties and when to compare groups of users.

In plain words
What is it for?
Use it to compare events such as rage clicks on mobile and desktop, or to refine an existing comparison with an extra filter.
Why use it?
It prevents comparisons from giving misleading results by mixing up facts about an event, such as a device, with facts about the person who made it.

Skill for Claude Code

Written for Claude Code: user-invocable in frontmatter.

Part of the fullstory-claude-plugin plugin — 46 skills, 3 agents, 1 MCP server shipped together

Good fit Use it to compare events such as rage clicks on mobile and desktop, or to refine an existing comparison with an extra filter.

Compare 6 skills from other repositories ↓
Install with agentmods
npx agentmods add skills/reatlat/fullstory-claude-plugin/comparisons
Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent
npx skills add reatlat/fullstory-claude-plugin --skill comparisons
Clone the repo
git clone --depth 1 https://github.com/reatlat/fullstory-claude-plugin

Made for: Claude Code.

Or install fullstory-claude-plugin, the plugin that ships this one along with the rest of its 46 skills, 3 agents, 1 MCP server.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for comparisons

README.md
[![agentmods](https://agentmods.dev/badge/skills/reatlat/fullstory-claude-plugin/comparisons/github.svg)](https://agentmods.dev/skills/reatlat/fullstory-claude-plugin/comparisons)
Your own site
<a href="https://agentmods.dev/skills/reatlat/fullstory-claude-plugin/comparisons"><img src="https://agentmods.dev/badge/skills/reatlat/fullstory-claude-plugin/comparisons/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

agentmods 80×15 button for comparisons

Your own site · 80×15
<a href="https://agentmods.dev/skills/reatlat/fullstory-claude-plugin/comparisons"><img src="https://agentmods.dev/badge/skills/reatlat/fullstory-claude-plugin/comparisons.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 40 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,057 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe. Third-party audits
  • NVIDIA SkillSpector pass 7 Sept 2026
How audits are shown
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00040 $0.01057
Opus 5 $0.00020 $0.00528
Sonnet 5 $0.00008 $0.00211
Haiku 4.5 $0.00004 $0.00106

Measured 10d ago against content hash d8c6df990961, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-09, from the pricing page.

Security

Grade A, and why

comparisons scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/comparisons/SKILL.md · 50 lines

How it starts

The opening of the file, as written. The whole thing — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Comparisons

When the user asks to compare A vs B, the right mechanism depends on what the comparison axis is. Use the decision table below to classify it — the user doesn't need to know this distinction exists.

Event/session properties → dimensionality

If the comparison axis describes the context of an individual event at the moment it fired — not the user who triggered it — use dimensionality. Common examples: device type, browser, OS, page URL, element. But the rule is the principle, not the list: if the property travels with the event, not the user, it belongs here. Express it as a single top_n metric with the comparison axis as the grouping dimension.

Example: "rage clicks on mobile vs desktop" → fullstory:build_metric(query="rage clicks by device type", output_type="top_n"). The result table shows mobile and desktop as separate rows.

To refine an established comparison metric (e.g., "add a Chrome-only filter"), pass its metric_id to fullstory:update_metric with a refinement instruction rather than rebuilding.

Do not use segments for event properties. Building a "mobile users" segment and a "desktop users" segment would assign all of a user's rage clicks to whichever device they ever used — even clicks that happened on the other device.

User-level properties → separate segments

Properties that describe a user rather than an event should use segments. The key mechanism: Fullstory resolves user properties to the user's last known value for that key. This canonical value is what segment queries match against — so you're asking "what bucket is this user in now?", not "what was their value at the moment of each event?".

Built-in user properties that work this way: signed_up (signed-up status), first_seen / last_seen (dates), total_sessions (engagement depth), and any custom user properties (user_var_string, user_var_int, etc.) set via setUserProperties — e.g. plan type or account ID. Build one metric and one segment per cohort, then compute each cohort in sequence: attach the segment via fullstory:update_metric(metric_id, segment_id), call fullstory:compute_metric(metric_id), store the result, then repeat with the next segment. Present the results side by side. Do not pass segment_id directly to fullstory:compute_metric.

Read the full file on GitHub · 50 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 10d ago First seen · 50 lines · 40 tokens per session scan A d8c6df990961

Subscribe to this mod's changes

comparisons is a skill published in the GitHub repository reatlat/fullstory-claude-plugin (62 stars, last pushed 27d ago), licensed MIT. It adds 40 tokens to every session and 1,057 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.