Orchestrator for analyzing a single Claude Code session transcript. Takes the tmp folder produced by get-claude-code-transcript-from-local, requires the Segment tree from decompose-agent-transcript-into-transcript-segments (invoking it if the tmp folder doesn't already have one), drives the per-Segment analyzers across four buckets (outcomes, prompts, skills, mcp) and writes their conclusions as findings.<kind>.json — and stops there. It produces only that transcript's four findings files; there is no per-transcript report. The report is a batch-end step: once every transcript of interest has been analyzed, synthesize-agent-transcript-analysis-report runs once over the whole batch's findings. Use this skill when the user wants a single session analyzed, a "how could this have gone better" review, or to surface Skill/MCP opportunities from real usage.
Cross-cutting analyzer. Given the per-transcript findings.*.json sets of several already-analyzed transcripts (the phase-3 outputs of analyze-agent-transcript — findings.outcomes/prompts/skills/mcp.json), surface patterns that no single transcript reveals: Segments that could have been shorter with hindsight, user prompts that repeat the same nudges or context, recurring missing Skills / MCP tools across sessions, time-spend patterns where the agent consistently takes 5x what a human would. Still phase-3 labeling, but runs once over the whole batch — last in phase 3, after every transcript has been analyzed — as an optional pre-report augmentation, not interleaved per transcript and not fanned out by the orchestrator. Runs on the raw per-transcript findings; there is no per-transcript report, and reading raw findings is what catches the long tail that only matters in aggregate. Writes findings.cross-transcript.json into the batch_dir for synthesize-agent-transcript-analysis-report to pick up. Use this skill w
Per-Segment analyzer. Produces an improvement hypothesis for every Failure Outcome and every retro-Failure (a Correction trigger at the next Segment's head implies the prior Segment failed even if it didn't recognize it). Both user-source and agent-source Corrections qualify as retro-Failure signals; user-source is the stronger signal. Each hypothesis names the most plausible root cause — usually a missing Skill, a Skill whose description didn't trigger, a missing MCP capability, or a user-side prompting issue — and the concrete change that would have prevented the failure. Fed by analyze-agent-transcript; outputs flow into the Prompting / Skills / MCP recommendation buckets of the final report.
Per-user-source-New-Trigger analyzer (the case formerly known as the Initial Prompt). Flags user-typed Triggers that look like they under-scoped the work — short, narrow, followed quickly by another user-source New Trigger on a related Goal. Pattern suggests the user split work the agent could have one-shotted with a more ambitious prompt. Output feeds the human-prompting recommendation bucket, and may also surface deterministic-trigger opportunities (the ideal end-state for user-source New Triggers).
Analyze a single user-source Trigger attached to a Transcript Segment. Classify it (question vs delegation), confirm the Segment's Goal, and assess whether the Segment closed the loop on that Goal. The Trigger kind (New vs Correction) and source (user) are already set by the segmenter; this skill consumes them. If the Goal isn't self-evident, delegate to pull-together-agent-transcript-goal-context. Output feeds the "human prompting" recommendation bucket of analyze-agent-transcript.
Phase-4 synthesis — runs once over a whole batch of analyzed transcripts. Given the per-transcript tmp_dirs that make up the batch, reads every transcript's phase-3 findings (findings.outcomes/prompts/skills/mcp.json) plus findings.cross-transcript.json when present, and synthesizes them into ONE final report of actionable next steps across three buckets: human prompting, Skills (create/modify/delete), and MCP servers (create/modify/delete). Writes findings.report.json (the reviewable recommendation slate) and report.md (the human-readable report grouped by priority, including a key-stats block aggregated across the batch), and a multi-page HTML site that drills from the report down into every intermediate decision the pipeline made — report.html landing + recommendations/rec-NNN.html per rec + sessions/<tag>.html per transcript + segments/<tag>--<SID>.html per Segment (its decomposition plus every phase-3 finding tagged to it) + optional external-context and cross-transcript pages — into a batch_dir. Use onc
For a given transcript, gather the external context a reviewer would want before judging the session: the ticket the work traces back to (e.g. from Jira), the pull request it landed in (e.g. from GitHub), and background on the user's role, team, and project. Reads transcript.json from get-claude-code-transcript-from-local, infers what to look up from the session's cwd / git remote / branch / prompts, pulls it from whatever systems are reachable, and consolidates everything into one external-context.json that travels with the transcript through every later phase. Use after get-claude-code-transcript-from-local and before decompose-agent-transcript-into-transcript-segments. Best-effort: missing sources are recorded, never fatal. The set of sources is expected to grow over time.
Given the tmp folder produced by get-claude-code-transcript-from-local (containing transcript.json — an OpenTranscripts Transcript document), decompose the transcript into a recursive tree of Transcript Segments (see the transcript-segment reference). Each Segment carries a Trigger (kind: New | Correction × source: user | agent | subagent), a Goal (Plan | Action), an Outcome (Success | Failure), child sub-segments, and a meta block (event range, wall-clock, tokens, model). Emits segments.json (structured) and flamegraph.html (annotated). All phase-3 analyzers read segments.json — they never walk transcript.json events directly. Use this skill immediately after acquisition and before any analyze-* skill.