Patchnotes

Turns your git history into a changelog people actually read

Noah FischerLaunched 4 days agoCLIWorking · checked 3 hours ago
0:42

About

Patchnotes reads the commits since your last tag, groups them by what changed for the user, and writes release notes in plain language. It knows the difference between a refactor nobody cares about and a fix someone has been waiting for.

It's a single Rust binary. Run it locally, or drop the GitHub Action into your repo and it opens a pull request with the draft every time you tag a release.

#changelog#git#release notes#github action

How it was made

Shared by the maker. Numbers are their own estimate.

Build time
2 weeks
AI spend
$22
Prompts
~96
Written by AI
80%

Agents

  • Codex

    68% of the work

    Rust implementation and the GitHub Action

  • Claude

    32% of the work

    The tone guide and the grouping rules

MCP servers1

  • GitHub

    Reads tags and commits, opens the release pull request

Build recipe

The code is on GitHub. If you’d rather build it yourself than fork it, paste this into your own agent.

Written by Claude

From the project’s code and history · 354 words

Build a cli called Patchnotes: turns your git history into a changelog people actually read.

What it does

Patchnotes reads the commits since your last tag, groups them by what changed for the user, and writes release notes in plain language. It knows the difference between a refactor nobody cares about and a fix someone has been waiting for.

Stack

Use Rust, Anthropic API. The original was built with Codex and Claude in 2 weeks, for about $22 in AI usage.

How it fits together

  • A single binary with subcommands
  • A config file with sensible defaults
  • An optional CI integration that runs the same command

Build it in this order

  1. Scaffold the binary with --help and one subcommand
  2. Implement the core command against real input and print readable output
  3. Add flags, config and a dry run mode
  4. Package it for Homebrew and as a CI action
  5. Write tests for parsing and output

Tools to connect

  • GitHub MCP: reads tags and commits, opens the release pull request

A prompt that worked: Write the tone guide first

You're writing release notes for people who use the product, not for the developers who built it. Before writing anything, produce a one-page tone guide: what we call things, what we never mention (refactors, dependency bumps, CI), how we phrase fixes ("Fixed: …" + what the user saw), and how long each line may be. I'll review the guide, then you'll use it for every release.

Watch out for

  • Output is the interface: make it short, aligned and readable
  • Never change files without a dry run option

Done when

  • --help explains every command in one screen
  • It runs in CI with the same result as locally
  • Tests cover parsing and the main output

Before writing code, ask me up to five questions about who this engineering cli is for and what the first version must do. Then work in small steps: after each one, tell me how to try it and wait for my feedback.

Discussion

3 comments

  • Lena Vogt6 hours ago

    Love how focused this is. One thing: the empty state took me a second to understand. Maybe show an example right away?

  • Kenji Mori1 day ago

    What did the agent struggle with most? Always curious where people had to step in.

    • Noah FischerMaker2 hours ago

      Thanks! Good question, I'll write it up in the build log this week.

More like this