Skip to main content
After every workflow run, Fabro generates a retro — a structured retrospective that captures what happened, what went well, and what didn’t. Retros combine deterministic metrics extracted from the run’s checkpoint with a qualitative narrative produced by an LLM agent that analyzes the full event stream. The goal is continuous improvement. Retros give you a searchable history of how your workflows perform over time, surface friction patterns that would otherwise go unnoticed, and identify follow-up work before it falls through the cracks.
Fabro web UI Retros list showing runs with Smooth, Bumpy, Effortless, and Struggled ratings

​
What’s in a retro

A retro has two layers: quantitative stats derived cheaply from checkpoint data, and an agent-generated narrative that interprets the run holistically.

​
Quantitative layer

The quantitative layer is extracted directly from the checkpoint and event stream — no LLM calls required:
FieldDescription
Per-stage breakdownDuration, retry count, cost, files touched, status, and failure reason for each stage
Aggregate statsTotal duration, total cost, total retries, all files touched, stages completed vs. failed

​
Narrative layer

An LLM agent reads the run’s progress.jsonl event stream and produces a structured analysis:
FieldDescription
SmoothnessOverall rating on a 5-point scale (see below)
IntentWhat the run was trying to accomplish
OutcomeWhat actually happened
LearningsWhat was discovered about the repo, code, workflow, or tools
Friction pointsWhere things got stuck and why
Open itemsFollow-up work, tech debt, test gaps, or investigations identified
The agent has tool access to grep and read the event stream, so it can inspect actual tool call patterns, error messages, and approach pivots — not just pass/fail signals.

​
Smoothness ratings

Every retro includes a smoothness rating that grades the overall quality of the run’s execution:
RatingMeaning
EffortlessGoal achieved on the first try. No retries, no wrong approaches. Agent moved efficiently from start to finish.
SmoothGoal achieved with minor hiccups — 1–2 retries or a brief wrong approach quickly corrected. No human intervention needed.
BumpyGoal achieved but with notable friction: multiple retries, at least one significant wrong approach, or substantial time on dead ends.
StruggledGoal achieved only with difficulty: many retries, major approach changes, human intervention, or partial failures requiring recovery.
FailedRun did not achieve its stated goal. Some stages may have completed, but the overall intent was not fulfilled.
The rating considers the full context visible in agent events — tool call patterns, error recovery sequences, approach pivots — not just stage pass/fail counts.

​
Learnings, friction points, and open items

​
Learnings

Learnings capture what was discovered during the run, categorized by type:
CategoryExamples
repoRepository structure, build system quirks, CI configuration
codeBug root causes, module boundaries, API contracts
workflowNode ordering issues, missing stages, prompt improvements
toolTool limitations, MCP server behavior, command output parsing

​
Friction points

Friction points identify where the run got stuck and what caused the slowdown:
KindDescription
retryA stage needed multiple attempts
timeoutA stage or tool call hit a time limit
wrong_approachThe agent pursued a dead end before pivoting
tool_failureA tool or command failed unexpectedly
ambiguityUnclear requirements or conflicting signals caused confusion
Each friction point can optionally reference the stage_id where it occurred.

​
Open items

Open items capture follow-up work identified during the run:
KindDescription
tech_debtCode quality issues worth addressing later
follow_upWork that’s related but out of scope for this run
investigationUnknowns that need further research
test_gapMissing test coverage discovered during the run

​
How retros are generated

Retro generation happens in two phases after a run completes:
  1. Derive — Fabro extracts stage durations from progress.jsonl and builds a retro from the checkpoint data. This is deterministic, fast, and produces the quantitative layer. The retro is saved immediately as retro.json in the run’s directory.
  2. Narrate — An LLM agent session analyzes the run data. The agent has read access to progress.jsonl, checkpoint.json, and manifest.json. It uses grep and read tools to find interesting signals — failures, retries, errors, approach changes — then calls a submit_retro tool with its structured analysis. The narrative fields are merged into the existing retro and saved.
Both phases run automatically at the end of every CLI run. The API server derives the quantitative layer but does not currently run the narrative agent.
Fabro web UI run retro showing Smooth rating, duration, cost, learnings, and follow-up items

​
Accessing retros

​
CLI

Retros are saved to {run_dir}/retro.json after every run. The path is printed at the end of the run output: 
Retro: smooth — Successfully implemented the feature
  Retro saved to ~/fabro-logs/01JKXYZ.../retro.json
To skip retro generation for a single run, pass --no-retro: 
fabro run workflow.fabro --no-retro
To disable retros project-wide, set retro = false in your fabro.toml:
fabro.toml
version = 1

[fabro]
retro = false

​
API

Retros are also available via the REST API. See the Retros API reference for endpoints to retrieve a single run’s retro or list retros across all runs.

​
Storage

Retros are stored as retro.json in the run’s directory alongside checkpoint.json and progress.jsonl. They are plain JSON files — easy to parse, query, or pipe into other tools.