Files
dckc 65199cafa7 Add what-was-i-doing skill
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
2026-10-08 07:21:44 -05:00

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. --author cuts 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 by git gc (default 90 days, 30 for unreachable), so older days may be patchy. The mtime of .git/FETCH_HEAD gives the last fetch even when the reflog doesn't.
  • The locate DB is rebuilt nightly. Repos created today are missing; sudo updatedb if 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_history has timestamps only if HISTTIMEFORMAT was set; .tmp/*.script typescripts (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.