For the past few months, my team and I have been working on a project involving AI agents — which is exciting by nature, full of experiments, fast iterations, and plenty of moving parts. Every Friday, three of us — me (backend), our frontend lead, and our designer — had a ritual: each one would write a short summary in our team channel about what happened during the week. It was a way to make sure product and non-technical folks could follow along with the backend, frontend, and design work.
The challenge wasn’t so much about discipline. The real friction was translating what was actually done into something meaningful and digestible for the rest of the team. What made sense as commits and technical details didn’t always land well for product.
Since we were already deep into AI and automation, the question naturally came up: why not automate this weekly process too?
That thought was the seed of Briefly.
From Ritual to CLI
The idea was straightforward: grab the git commits for the week, summarize them with AI, and share the result where the team communicates.
A couple of shell scripts later, the first version of Briefly was alive.
# Setup for your repo
briefly setup
# Generate a changelog from recent commits
briefly generate --since 7d
# Publish to Discord
briefly publish briefly-summary.md --env staging --app-url https://example.com
How It Works
Briefly has three simple commands:
-
Setup: Creates a local
.brieflyconfig with your OpenAI key, Discord webhook, and defaults. -
Generate: Collects git commits, summarizes them with OpenAI, and writes a
briefly-summary.md. - Publish: Posts the summary directly to Discord via webhook.
The config is just a small .ini file:
OPENAI_API_KEY=...
DISCORD_WEBHOOK=...
DEFAULT_MODEL=gpt-4o-mini
PROJECT_KIND=api
DEFAULT_ENV=staging
DEFAULT_APP_URL=https://example.com
Why Two Commands?
You might wonder: why split generate and publish instead of a single command?
The reason is intentional. AI outputs are, by nature, non-deterministic. I wanted whoever was responsible that week to review the generated changelog before pushing it out. This way they could:
- Ensure the summary was factually accurate.
- Add or remove emphasis on changes that mattered most.
- Adjust wording so it resonated better with product or leadership.
It’s a balance between automation and human judgment: the AI does the heavy lifting, but people keep the final say.
Why It Matters
Most teams struggle with changelogs. They’re either too detailed (commit dumps no one reads) or too sparse ("fixed stuff"). Briefly finds the middle ground: concise, readable summaries generated automatically.
Instead of forgetting to update your team, or spending 30 minutes writing a message at the end of the week, you can run:
briefly generate && briefly publish
And that’s it. Your team gets a digestible changelog, right where they already communicate.
What’s Next
Briefly is still early, but here’s what’s on the roadmap:
- Aliases (
briefly g,briefly p,briefly .) - Multilingual summaries
- Relative dates (
--since 7d|1w|2m) - Dry-run mode for CI
- Custom prompts for different project styles
And yes, CI integration is coming soon — imagine every Friday your bot dropping the changelog in your channel without anyone lifting a finger.
Give It a Spin ✨
Briefly is published on npm as @jmscarpa/briefly.
npm install -g @jmscarpa/briefly
If your team also shares weekly updates, give it a try. Automating the boring parts leaves more time for the creative ones.
Sometimes the best tools are born not from big visions, but from small rituals that refuse to stay manual.
Top comments (1)
Curious to hear how other teams handle changelogs.
Do you keep them manual, automate with scripts, or skip them entirely?
Would AI fit into your workflow here?