I didn't build hrs to track R&D. I built it because I manage agents across half a dozen repos and most days I cannot tell you what I shipped.
But as it turns out, logging every entry against a daily goal, every goal against a multi-day strategy, and every strategy against a ticket is exactly what a defensible R&D claim looks like.
- Create a strategy:
hrs strategy add -t "Ship Eisenhower matrix in TUI" -i 5 -u 3 --ticket PROMO-150 - Create a tactical goal:
hrs goals add "wire up i/u priority toggle" -s 1 -i 5 -u 4 - Log time against it:
hrs log -c dev -t "matrix navigation" -b "h/l day switch,live i/u toggle" -e 2 - Mark it done:
hrs goals done 1 -e 217,218
Then at the end of the year:
hrs export --ticket PROMO-150 --from 2025-07-01 --to 2026-06-30 --format csv
Defensible hours per ticket, all auditable and exportable. Rolled up from entries → goals → strategies, so "how many hours on PROMO-150?" stays one query.
Our R&D consultant Anders Landberg at AHL Advisory put it well: the claim process is getting more sophisticated every year, and the defensible answer is to stay ahead of it. Reconstructing hours at lodgement is a great way to lose half the claim under audit.
Logging against an activity and an experiment as you go means the timesheet is the evidence, not a reconstruction.
New TUI view also: Eisenhower matrix of goals and strategies with live i/u toggles, so you can re-prioritise the day without leaving the terminal.
Single Go binary, MIT license, FOSS. hrs.dev. Feel free to use it, critique, or contribute.
Cross-posted from LinkedIn.