spotting-friction

Installation
SKILL.md

Spotting friction

Friction is discovered, not fetched. Scan the raw agent trace with get_trace — tool errors (isError), the agent stalling or looping (repeated toolNames, rising gapAfterMs), interruption turns — the same mechanics the reading-an-agent-trace skill uses (toolCounts, totalErrors, totalInterruptions, the isError merge-by-tool_use_id). A pre-graded friction list isn't evidence you've verified against this run; a trace turn is.

Tools

  • get_trace({ slug }) — the primary source: find the turn where the agent actually hit a problem (see the reading-an-agent-trace skill for the scanning mechanics).
  • get_report({ slug }) — for legacy.keyFinding and metrics (friction rarely means anything without the metrics it explains). get_report().legacy.frictionPoints and get_report().recommendations also exist but are pre-graded, pre-written report-time fields — treat them as hints only (see below).

The report's canned legacy.frictionPoints shape (use only as a hint)

get_report({ slug }).legacy.frictionPoints is a report-time snapshot (null when the report recorded none) generated once and never re-checked against what actually happened in this run. Each item: { id?, severity, title, desc, impact? } — severity is critical/major/minor, id a shortcode like F-01. Treat these as a rough pointer to where problems might be, not as verified findings; your actual citation should be the trace evidence (tool name, error text, turn) you find at that location, not the F-XX id.

Ignore the report's canned friction points and recommendations — derive both from the raw trace

get_report().legacy.frictionPoints is pre-graded and unverified against this specific run. get_report().recommendations ({ id?, effort, title, desc, estimatedImpact? }) is a legacy, pre-written field. Don't quote either as authoritative, and don't lead your narrative with F-XX or R-XX ids. Instead, derive both the friction and the fix yourself:

  1. Scan get_trace (per the reading-an-agent-trace skill's mechanics — toolCounts, totalErrors, error-flagged tool_use blocks, interruption turns, stalling gapAfterMs) to find the actual moments where the agent had a bad experience.
  2. Reason about the concrete product change from that raw evidence — what would have made that specific tool call, error, or dead end not happen.
  3. Quote the trace turn (tool name, error text, URL, timestamp) as your evidence, not a pre-written friction point or recommendation.

You may optionally use get_report().legacy.frictionPoints/.recommendations as a rough map of where problems might be, but every claim in your final output must be grounded in something you can point to in the trace.

Installs
3
First Seen
6 days ago
Security Audits