| name | refresh-reports |
| description | Locates a freshly downloaded Instagram data export zip, unzips it into this repo's export/ directory (clearing out whatever was there before), and runs the non-followers, pending-requests, close-friends, and followers/following-diff reports. Use when asked to process, import, or refresh the Instagram export, or to regenerate the reports from a new download. |
When asked to process a new Instagram export and regenerate the reports, follow
these steps in order.
1. Find the zip
If the skill was invoked with an explicit path to a zip (e.g. via ARGUMENTS),
that path is the new export — use it directly and skip the search below.
The path a user gives you always names the new export, never something to be
cleaned away.
Otherwise, run the search script — it deterministically checks, in fixed
order, this repo's export/ folder, then ~/Desktop, then ~/Downloads,
short-circuiting on the first location whose newest instagram-*.zip was
modified today, and otherwise falling back to the overall newest match:
.claude/skills/refresh-reports/scripts/find_export.sh
It prints the chosen zip's path on success. If it exits non-zero (no output,
no match anywhere), ask the user where to look — they'll typically name a
folder like "check the Desktop" — map that to the actual path and check there
directly. Don't guess a location the user didn't name and that isn't one of
the three the script already covers.
2. Clear out the old export
Before bringing in the new one, stale data from a previous run must not linger
alongside it. export/ is gitignored, so all of this is local cleanup only,
not a git operation.
Check whether the found zip already lives inside export/ first — resolve
its path and compare against the repo's export/ directory:
3. Move and unzip
If the zip isn't already in export/, move it there; then unzip it (unzipping
is safe either way — it just overwrites the same-named folder):
mv <found_zip> export/
unzip -q "export/$(basename <found_zip>)" -d export/
Confirm export/connections/followers_and_following/ exists afterward — that's
what every report command reads from.
4. Run the reports
Run all four read-only commands with their defaults — do not ask the user
for a cutoff date, and don't pass --exclude-after unless they explicitly
asked for one in this request:
cargo run --bin non_followers
cargo run --bin pending_requests
cargo run --bin close_friends
cargo run --bin followers_diff
Let each command run to completion rather than piping its output through
head/tail/etc. — each one writes its report file only after finishing its
stdout output, and cutting the pipe early can kill the process with SIGPIPE
before it saves the file.
If the user did ask for a cutoff date in this request, pass
--exclude-after <YYYY-MM-DD> to non_followers and/or pending_requests as
they specified — close_friends and followers_diff have no such flag.
followers_diff compares this export's followers/following against a
snapshot saved locally under data/ on the previous run of this command
(not against this same export) and then overwrites that snapshot with the
current lists. The first time it ever runs, there's no prior snapshot to
diff against — it just saves the baseline and writes no report files. That's
expected, not an error.
5. Report back
Once the commands have saved their files, respond with nothing but the lines
below that apply (paths relative to the repo root, matching each command's
--output default unless the user overrode it). Always include the first
three. Include the last two only if results/followers_diff.txt and
results/following_diff.txt actually exist — followers_diff skips writing
them on its first-ever run (see step 4):
Non-followers: results/non_followers.txt
Pending requests: results/pending_requests.txt
Close friends: results/close_friends.txt
Followers diff: results/followers_diff.txt
Following diff: results/following_diff.txt
No counts, no preamble, no extra commentary — just the lines.
