Every developer has a ~/dev/tools/scripts folder. Mine has run for years without an index. I asked Claude Code to read every file in it and write one.

The brief was simple: read the whole directory, then produce an INDEX.md with three columns — tool, how to run it, what it does.

It scanned roughly 40 files: Python CLIs built on uv, shell wrappers, one-off Snowflake key-rotation scripts, a tmux session launcher, a Hacker News summarizer. Some had docstrings. Several had none, and their purpose was recoverable only by reading the argparse block or the hardcoded constants at the top.

The index itself is now grouped by what the tools are for — Claude Code workflow helpers, DISC infrastructure reporting, Snowflake key management — with a separate section for stubs and known-broken scripts, so the next person (probably me, in six months) sees the warnings before running anything.

What’s in the drawer

For anyone curious what four years of “I’ll just script this” produces…

ScriptWhat it does
claude-sessions.pyLists resumable Claude Code sessions with a ready-to-paste resume command
which-sessionFinds past Claude Code / Copilot sessions run from a given directory
install-claude-skillInstalls a Claude skill from a GitHub folder URL into the local skills directory
aitx.pyTUI browser/installer for an internal AI tool exchange
jira_history.pyRanks JIRA tickets visited in browser history, enriched via the JIRA CLI
dev-session.shSpins up a tmux session with preset windows for a project
dev-worktree.sh / dev-rm-worktree.shCreates and tears down git worktrees, with an fzf repo picker
delete-gone-branches.shDeletes local branches whose remote has disappeared
git-pull-all.shFetches and pulls every repo under a parent directory, in parallel
hn-summary.shSummarizes a Hacker News thread’s comments via an LLM
disc-postgres-azure-flexpg.pyReports CPU/memory/storage/connection metrics for a set of prod Postgres instances
disc-postgres-pgo-connections.pyReports connection utilization across a set of prod Postgres clusters
bits_parse_tenants.shOne-line jq/column filter that formats tenant build data as a table
stacks.pyPrints a static reference table of internal environment/region codes
etl_jobs.py / etl-jobsReads ETL job config files from a data-platform repo and prints selected fields
prmFuzzy-search browser for an internal data model catalog (symlinked from another repo)
domain_sebs.py / sebsWalks a config repo and tallies event-bus definitions per domain
disc_admin_checks.pyBroken — near-duplicate of domain_sebs.py, raises NameError on run
make_snowflake_key_pair.shGenerates RSA key pairs per environment and prints the matching SQL
create_rsa_keys.pyPython equivalent of the above, plus a YAML summary of generated keys
set_snowflake_user_public_key.pySets a user’s public key across a list of accounts — placeholder values, unfinished
upload_keys.pyUploads a generated private key to a secrets manager, with a confirmation prompt per secret
test_snowflake_connection_with_rsa_key.pySmoke test: connects with a key file and runs a version check
data-mesh-sf.pyStub — renders a “Hello, World” template and does nothing else
publish-gist.shEmpty file — a placeholder that was never written

Session stats

Real numbers from this session’s transcript, not estimates:

  • 21 assistant turns carried usage data
  • 22,428 output tokens generated
  • 155,639 tokens written to cache
  • 1,159,344 tokens read from cache
  • 42 tokens of fresh, uncached input
  • 42 minutes, start to finish

Cache-read tokens are billed at a fraction of the rate of fresh input, so summing all four categories into “1.3m tokens” overstates the cost by a wide margin — most of that figure is cheap re-reads of context already paid for earlier in the session, not new work.