Reconstruct past activity from an artifact's mtime: day-in-repos.sh lists one day's commits and reflog entries (pulls, checkouts, clones: local events git log never shows) across every repo locate knows. Generated-by: Claude Opus 5.5
3.5 KiB
name, description
| name | description |
|---|---|
| what-was-i-doing | What was I doing on <date>? Reconstruct past activity on this machine — use when the operator asks what they were doing on a day, where a stray file / install / symlink came from, or "why is this here?"; when a timestamp (ls, stat, cache dir) is the only clue. Correlates file mtimes with git commits and reflogs across every repo `locate` finds. |
What was I doing? Timestamps as a diary
The machine already keeps a diary; it's just scattered. A mystery artifact
(a stray ~/.bun, an odd symlink, a cache dir) carries an mtime. Line that
time up against git activity across all repos, and the project usually
falls out within a few minutes.
1. Pin the clue's timestamp to the minute
ls -la --time-style=+'%F %H:%M' ~/.bun ~/.bun/* ~/.local/bin/bunx
Look at the artifact and its neighbors: the directory, its children, and
anything that points at it (symlink targets, readlink). The newest mtime
inside a cache says when it was last used. Caches also say what was
used: ls ~/.bun/install/cache, ~/.npm/_cacache, ~/.cache/pip.
A cache full of @vitejs, @reduxjs, @tailwindcss means a frontend
build.
2. Sweep every repo for that day
day-in-repos.sh lists commits and reflog entries for
one day across every repo in the locate database. Reflog is the important
half: pulls, checkouts, rebases, and amends are local-only, never show in
git log, and are often exactly what you did that day.
.agents/skills/what-was-i-doing/day-in-repos.sh 2026-05-25 | grep -v heartbeat
.agents/skills/what-was-i-doing/day-in-repos.sh 2026-05-25 --author=dckc
- Extra args go to
git log.--authorcuts upstream and bot commits, but reflog rows are never filtered. They're always yours. - A commit shared by several clones/worktrees prints once, listing them all.
- Reflog begins at
clone: from <url>and is pruned bygit gc(default 90 days, 30 for unreachable), so older days may be patchy. The mtime of.git/FETCH_HEADgives the last fetch even when the reflog doesn't. - The
locateDB is rebuilt nightly. Repos created today are missing;sudo updatedbif that matters. - Filter noise with
grep -v. Bot heartbeats and dependabot bumps flood some repos.
3. Correlate, then confirm in the candidate repo
Look for repo activity within minutes of the artifact's mtime. Then confirm
inside that repo: does it reference the tool (git grep -i bun, CI
workflows, lockfiles), and do its build outputs (node_modules, dist)
carry matching mtimes?
Report it as a timeline table: time, event, source. Say which links are evidence and which are inference ("probably linked by hand").
Other diaries, when git is quiet
journalctl --user --since ... --until ...: user units, systemd-run.- Shell history:
~/.bash_historyhas timestamps only ifHISTTIMEFORMATwas set;.tmp/*.scripttypescripts (see the watchme skill). - File mtimes broadly:
find ~ -xdev -newermt 2026-05-25 ! -newermt 2026-05-26 -not -path '*/node_modules/*' -not -path '*/.cache/*'(fselect does the same in SQL, if installed).
Worked example
~/.local/bin/bunx → ~/.bun/bin/bun (1.3.14), both 2026-05-25 12:27.
The sweep showed projects/pinchtab reflog: pull 12:19, forced-update
12:35, checkout v0.13.0 12:36. pinchtab/dashboard/ has a bun.lock,
CI runs bun install, and dashboard/node_modules was created at 12:28.
Conclusion: bun was installed to build pinchtab's dashboard for v0.13.0.