Log Week One, Your Real Baseline
The skill will not guess a number for you
Once the skill is installed, logging a week looks like a conversation, not a form. Open Claude
Code in the project where the skill lives and say something like "let's log week 1." The skill
(.claude/skills/transformation-tracker/SKILL.md) is written to ask for six numbers before it
runs anything, and it is written just as deliberately to never estimate, infer, or carry one of
those numbers over from a prior week. If you mentioned in passing three messages ago that you
worked "about fifty hours," the skill still asks. That repetition is not an oversight. A tracker
that fills in gaps from conversational context is a tracker that will eventually invent a number
you never actually gave it, and by week eight nobody remembers which numbers were real.
Here are the six questions, in order:
Every hour, not just billable hours. This is the denominator every other metric in this course divides against, so it has to be honest.
Of that total, how many hours did an agent do the work, not you? Not "hours saved" (you cannot measure a counterfactual with a stopwatch) but hours where the output existed and you did not produce it by hand.
A headcount, not a revenue figure. This is what turns into the Client Capacity Score once there are prior weeks to compare against.
Week 1 is always 1.0, by definition; there is nothing to compare it to yet. Every later week answers this as a ratio to that first number, never as a dollar figure.
What share of this week's revenue is subscription or retainer work, as opposed to one-off project billing.
What got handed to an agent this week, in your own words, and what is the thing still slowing you down. These two sentences do not feed a formula. They are the part of the log a spreadsheet cannot produce on its own, and they are usually what you reread first when a report disagrees with how a week felt.
Claude Code asks these conversationally, one at a time, the same way a good intake form does. Nothing gets logged until all six are on the table.
A rough honest number beats a precise one you spend twenty minutes reconstructing. "About 55 hours" logged today is worth more than an exact figure logged three weeks late because you were waiting until you had time to calculate it properly.
--revenue-ratio wants "this week compared to Week 1," not "this week's revenue." Week 1 answers
1.0 because it is comparing itself to itself; Week 6 might answer 1.4, meaning 40% more revenue
than the Week 1 baseline. Type an actual dollar amount here and every later week's Revenue
Efficiency Multiple is measuring against a number that was never a ratio to begin with.
Running it for a real Week 1
Here is an actual Week 1, run against the real skill after a fresh clone of profrodai/transformation-tracker-course: 55 total hours, 8 of them automated, 3 active clients, revenue ratio 1.0 (Week 1 defines its own baseline), 10% of revenue recurring, email filtering and meeting notes as the automation, manual client onboarding as the bottleneck. Once Claude Code has those six answers, it runs the underlying script for you:
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"Reading what it prints back
The real output, printed to the terminal:
week 1 logged.
automation_index: 14.55%
time_saved_vs_baseline: 0.0 hours/week
revenue_efficiency_multiple: 1.0x
client_capacity_score: 1.0x
recurring_revenue_pct: 10.0%
Lesson 4 is where each of those five metrics gets a full explanation. For now, notice the shape: one number (automation index) actually did something this week, and three of the other four are sitting at zero or 1.0. That is not the script failing to compute anything. Week 1 has no prior week to compare against, so "time saved versus baseline" is 0.0 because the baseline is this week, and the two multiples are 1.0x because a ratio of a number to itself is always 1.0. Hold that thought; the checkpoint at the end of this lesson comes back to it.
What actually lands in the log file
The script does not just print a summary and discard the rest. It appends one line of JSON to
transformation-log.jsonl in the project root, and that line is the entire source of truth for
every chart, every later-week comparison, and the graduation gate at the end of this course.
Here is the exact line the run above wrote:
{"week_number": 1, "submission_date": "2026-08-17", "total_hours": 55.0, "automated_hours": 8.0, "manual_hours": 47.0, "active_clients": 3, "revenue_ratio": 1.0, "recurring_revenue_pct": 10.0, "automation_index": 14.55, "time_saved_vs_baseline": 0.0, "revenue_efficiency_multiple": 1.0, "client_capacity_score": 1.0, "automated_this_week": "Email filtering, automated meeting notes", "biggest_bottleneck": "Manual client onboarding", "logged_at_utc": "2026-08-17T18:51:44.876759+00:00"}Notice what is not in that line: no client name, no dollar amount, no invoice total. manual_hours
is derived (total_hours minus automated_hours, computed once and stored rather than
recalculated every time something reads the file), and revenue_ratio is the only revenue-shaped
field in the entire record, stored as a ratio to your own Week 1 rather than as a number that
would mean anything to someone else reading the file. Lesson 4 explains why that design choice is
the one that makes this dashboard safe to share.
The three guard conditions, and why each one exists
The script protects three specific ways this log could go wrong, and all three are tested, not theoretical:
A week that is already logged refuses to run again, for the reason above: this is an append-only
record, and a script that would silently overwrite Week 3 because you ran the command twice is a
script nobody should trust with their only copy of the truth. An --automated-hours value that
is negative or greater than --total-hours refuses too, printing "error: automated-hours must be
between 0 and total-hours" and exiting 1, because automated hours are a subset of total hours by
definition; claiming the agent did more work than the whole week contained is not a typo you want
silently accepted. And any submission after Week 1 stops cold if no Week 1 entry exists yet,
printing "No Week 1 entry found. Log Week 1 first; every later week is measured against it."
Every metric past this lesson is a comparison to Week 1, so a Week 5 with no Week 1 to compare
against is not a smaller version of the truth. It is not measuring anything at all.
| Guard | Triggered by | Exact printed message |
|---|---|---|
| No overwrite | --week N already has an entry | "week N is already logged. This script only appends; it will not overwrite a prior week." |
| Bounds check | --automated-hours negative or above --total-hours | "error: automated-hours must be between 0 and total-hours" |
| Baseline required | --week above 1 with no Week 1 entry | "No Week 1 entry found. Log Week 1 first; every later week is measured against it." |
Log your own real Week 1 the same way, with your own six numbers in place of the ones above. The command is the template; only the values change.
Five metrics, one privacy rule: what each of these numbers actually proves, and why revenue never gets stored as a figure anyone could read off the file.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
