The companion repo for The 12-Week Transformation Tracker, Run on Claude Code, a free 12-lesson course at profrod.ai. Built for that course specifically, to be read and run alongside it, not as a standalone product.
A minimal, dependency-free starter for tracking a 12-week automation transformation, built as a Claude Code skill instead of a notebook you'd otherwise need Polars, DuckDB, and Plotly just to open. Five things get measured every week: Automation Index, Time Liberation Score, Revenue Efficiency Multiple, Client Capacity Score, and recurring-revenue percentage. Revenue is never stored as an absolute number, only as a ratio to your own Week 1 baseline.
Clone this repo, or copy .claude/skills/transformation-tracker/ into a project you already
have. Open Claude Code in that project and say "log week 1" — it will ask for the six numbers it
needs (see .claude/skills/transformation-tracker/SKILL.md) and run the logging script for you.
Prefer the command line directly:
python3 .claude/skills/transformation-tracker/scripts/log_week.py \
--week 1 --total-hours 55 --automated-hours 8 --active-clients 3 \
--revenue-ratio 1.0 --recurring-pct 10.0 \
--automated-this-week "Email filtering, automated meeting notes" \
--bottleneck "Manual client onboarding"
python3 .claude/skills/transformation-tracker/scripts/report.pyNo install step. Both scripts are Python standard library only.
.claude/skills/transformation-tracker/SKILL.md— the skill Claude Code loads automatically, and the full contract for what it asks before it logs anything..claude/skills/transformation-tracker/scripts/log_week.py— appends one week's metrics totransformation-log.jsonl, refuses to overwrite a prior week, refuses an invalid hours value, refuses to log week N > 1 with no Week 1 baseline yet..claude/skills/transformation-tracker/scripts/report.py— reads the log back as a table plus a graduation-readiness report.example-transformation-log.jsonl— four real weeks of output from the scripts above, kept as a worked example, not fabricated data. Delete it before logging your own Week 1; it is not the log the skill reads from and writes to (that'stransformation-log.jsonl, created fresh the first time you log a week, and gitignored on purpose since it can hold your own hours and client-count data).
| Metric | Formula | Answers |
|---|---|---|
| Automation Index | automated_hours / total_hours * 100 |
How much of this week's work did an agent do? |
| Time Liberation Score | baseline_hours - total_hours |
Hours back this week, vs. a fixed Week 1 |
| Revenue Efficiency Multiple | (revenue_ratio / total_hours) / (baseline_revenue_ratio / baseline_hours) |
Revenue per hour, as a multiple of Week 1 |
| Client Capacity Score | (active_clients / total_hours) / (baseline_clients / baseline_hours) |
Clients served per hour, as a multiple of Week 1 |
| Recurring-revenue percentage | entered directly, 0-100 | Share of revenue that's recurring, not one-off |
The course (lesson 4) covers what each one is actually for, not just the formula.
Revenue is only ever entered as a ratio to your own Week 1 baseline (revenue_ratio, a float —
never a dollar figure, never a field the schema even has room for). transformation-log.jsonl is
safe to post publicly or pull up on a client call because there's structurally nowhere in it for
a real number to leak, not because you were careful about what you typed.
The metrics and formulas here trace back to an earlier tracker (a Polars/DuckDB/Jupyter notebook,
not published alongside this course) that had a real internal inconsistency: its dashboard text
and target lines were all drawn at 80% automation, but its actual graduation-readiness check
tested for 70%. This repo picks one number as the real graduation bar (70%) and names 80%
separately as a stretch target, documented directly in report.py's source rather than left as a
silent mismatch between what a dashboard shows and what a gate actually checks.
MIT.