Thanks CLI

A CLI for thanking open-source maintainers

What it is

Thanks CLI (give-thanks) stars a GitHub repo and posts a thank-you message in GitHub Discussions. One command from your terminal. That's the whole thing.

One command. Star the repo. Post the thank-you. Move on.

How I got here

I was watching 4 hours to build a web app with Google Gemini — a Web Dev Challenge episode where four developers each build an app around the theme of gratitude. One of them, Zeu, built something called #ThankADev. It pulls the software bill of materials from a repo, generates a thank-you note for each dependency with Gemini, and lets you tweet it out.

I thought that was great. But it was a web app built in a hackathon. I kept thinking — what if this was a real tool? Something you could run from the terminal in 10 seconds? Something an AI agent could pick up and use as part of a workstream?

Open source has infrastructure for bugs, contributions, questions, sponsorship — everything except telling someone their work matters to you. A short message — "I use this for X and it saves me hours" — is the kind of thing that keeps someone maintaining a package on a Saturday.

How it works

Two modes: single thank and scan.

Single thank — run give-thanks hashbrown --used-for "generative UI dashboards for a Shopify merchant copilot" and it resolves the package to its GitHub repo, stars it, and posts a Discussion. The maintainer sees something like this:

Thanks for building hashbrown!

Hey! I'm using hashbrown in my work for fast hash maps in my data pipeline and wanted to say thanks for building and maintaining this. It makes a real difference.

If Discussions aren't enabled, it automatically falls through a chain — Issue, email, star-only — until something works. No prompts, no manual steps.

Scan mode — run give-thanks --scan and it reads your dependency files, filters out packages you've already thanked, and gives you an interactive checklist. Pick the ones that matter. It handles the rest.

Package resolution — looks up npm and PyPI registries, or accepts direct owner/repo
Smart auth — detects the GitHub CLI token first, falls back to GITHUB_TOKEN env var
Local history — tracks thanked packages in ~/.give-thanks/history.json so you don't thank someone twice
Dry run — --dry-run to see what would happen without posting anything
Non-interactive mode — --non-interactive or auto-detected when stdin isn't a TTY (CI, agents)
Fallback chain — Discussion → Issue → Email → Star-only, fully automatic
Email channel — sends via Resend when Discussions and Issues are both unavailable
Profile surfacing — shows the maintainer's email, blog, and Twitter after thanking

Design decisions

No infrastructure. Single npm package. History is a local JSON file. Auth piggybacks on tools you already have. Install it, run it, done.

In interactive mode, the scan checklist is intentionally manual — you pick the packages that matter. In non-interactive mode (CI, agents), it thanks everything unthanked. Either way: one channel per repo, no spam.

Being a CLI also makes it agent-friendly. If you're working with Claude and your workflow has you pulling in a bunch of small packages — scaffolding, evaluating libraries, wiring up integrations — the agent can run give-thanks as part of that workstream. Gratitude becomes a step in the pipeline, not something you remember to do later and then don't.

Where it's at

Shipped. Published to npm as give-thanks. Install it globally or run it with npx give-thanks.