Skip to content

AI changelogs for GitHub teams

Your changelog, written the moment you merge.

Recap watches your repository, reads the diff behind every merged pull request, and writes a summary a human actually wants to read. No config file. No release script. Nobody assigned to “do the changelog.”

Get started for free

Free credits on signup · Unlimited repositories · No credit card required

acme/platform

main

Thursday, 14 August

  1. Payslip access now checks the requesting employee's own record

    Any authenticated user could previously request a payslip by ID. The controller now authorizes against the signed-in employee before the file is streamed.

    SW swap PR #486 3 files +42 −11

  2. Subscription reminders send in the member's own timezone

    The reminder job was scheduled in UTC. It now resolves each member's stored timezone and queues at 9am local.

    NM nina-m PR #482 7 files +118 −34

  3. Routing and middleware consolidated into feature modules

    push a3f19c2 100 files +420 −541

0

Merged PRs backfilled the second you connect a repo

0

Config files, CI steps or release scripts to maintain

0

Event types watched — PR merges and pushes to main

Seconds

From merge landing to a published, readable entry

01 — The problem

Every team starts a changelog. Almost none of them finish one.

Write it at release time

Release day is the worst possible moment to reconstruct six weeks of merges from memory.

Ask everyone to update the file

It becomes the one review comment nobody wants to leave, and the entry quietly never lands.

Generate it from commit messages

“fix stuff”, “wip”, and “address review” are not a changelog. They are an apology.

Skip it and answer in Slack

Now the changelog exists — scattered across four threads that nobody can search next quarter.

The work already happened. The record of it just needs someone — or something — to be paying attention when it does.

02 — Watch it happen

Merge. Then look away.

Three things happen without anyone opening a tab. Scroll to run the sequence — or watch the whole thing end to end.

A pull request merges

GitHub fires a webhook the instant the merge lands on your default branch. Recap verifies the signature, acknowledges in milliseconds, and queues the work. Direct pushes to main are picked up too — and a push that is just a PR's merge commit is never logged twice.

Merged

2 seconds ago

POST /webhooks/github/…
x-hub-signature-256 verified
event pull_request.closed merged: true

Recap reads the actual diff

Not just the title. The queued job pulls the pull request's description, its file list and the patch itself, then hands that context to the model. Oversized diffs are truncated gracefully rather than dropped.

Reading 3 files

app/Http/Controllers/PayslipController.php

+ $this->authorize('view', $payslip);

− $payslip = Payslip::find($id);

+ $payslip = $user->payslips()->findOrFail($id);

tests/Feature/PayslipAccessTest.php

The entry publishes itself

A title and a short summary land on your timeline, grouped by day, credited to the author, stamped with the PR number and diff stats. No draft queue, no approval step, nothing waiting on you.

Payslip access now checks the requesting employee's own record

Any authenticated user could previously request a payslip by ID. The controller now authorizes against the signed-in employee before the file is streamed, with a regression test covering the cross-account case.▍

PR #486 3 files +42 −11 published

03 — What you get

Built for the way merges actually happen.

Written from the diff

The summary comes from the code that changed, not from whatever the commit message happened to say. Context includes the PR description, the file list and the patch.

History from minute one

Connecting a five-year-old repository does not give you an empty page. The last 20 merged pull requests are summarized immediately, in a single batched call.

Merges and direct pushes

Both are watched. A push that is really a pull request's merge commit is deduplicated, so the same change never appears twice on the timeline.

Diff stats on every entry

Files touched, lines added, lines removed — the shape of a change at a glance, next to the author and the pull request number.

Nothing fails silently

If GitHub rate-limits or a summary times out, the entry stays on the timeline marked failed, with the reason and a retry button. You always know what is missing.

Locked down by default

GitHub OAuth with an encrypted token, per-application HMAC webhook verification, and passkeys plus two-factor authentication on your Recap account.

“What shipped this week?” should take four seconds to answer, not an afternoon of scrolling through merged pull requests.

04 — Setup

Three steps, once.

Then you never touch it again.

  1. 1

    Create your account

    Sign up free, then connect GitHub. A single OAuth grant covers both signing in and reading your repositories — there is no second authorization step later.

  2. 2

    Pick a repository

    Choose from your repo list. Recap registers the webhook for you and immediately backfills your recent merged pull requests.

  3. 3

    Keep merging

    That is the whole setup. Every merge from here on writes itself onto the timeline, grouped by day.

05 — Who it's for

The people who keep asking what shipped.

Engineering leads

Run standup without doing archaeology

Open one timeline instead of scrolling the merged tab and reverse-engineering four days of work from branch names.

Founders & product

Know what shipped without asking

Summaries are written for a reader who was not in the pull request. Check on progress without pulling an engineer out of flow.

Support & customer success

Answer “when did that change?”

A searchable, dated record of behaviour changes, with the pull request number attached when someone needs to go deeper.

06 — Pricing

Pay for summaries, not for seats you don't use.

Every plan includes unlimited repositories. Credits are spent on AI summarization and reset each month — a live merge costs one summary, and a repo's initial backfill is batched into a single call.

Free

0

AI credits per month

  • 1 seat
  • Unlimited repositories
  • Automatic backfill on connect
  • Passkeys & two-factor auth
Get started for free
Most popular

Freelancer

0

AI credits per month

  • 1 seat
  • Unlimited repositories
  • Automatic backfill on connect
  • Passkeys & two-factor auth
Get started for free

Agency

0

AI credits per month

  • 5 seats
  • Unlimited repositories
  • Automatic backfill on connect
  • Passkeys & two-factor auth
Get started for free

07 — Questions

Reasonable objections.

Most of them are about trust, and they should be.

How is this different from generating a changelog from commit messages?

Commit messages describe what a developer typed at 11pm. Recap reads the actual pull request — title, description, changed files and the diff itself — and writes a summary from what the code does. "fix stuff" becomes a sentence a stakeholder can read.

Do I have to change my workflow?

No. You connect a repository once and keep merging exactly as you do today. Recap registers a webhook on your repo, listens for merged pull requests and pushes to your default branch, and writes an entry each time. There is no config file to commit, no CI step to add, and no release script to run.

Will my changelog be empty when I connect an existing repo?

No. The moment a repository is connected, Recap backfills the last 20 merged pull requests, so your timeline has real history before the first new merge lands.

What happens if a summary fails to generate?

Nothing disappears. A failed entry stays visible on the timeline with the reason it failed — a GitHub API hiccup, a timeout, an exhausted credit balance — and a retry action next to it. Retrying re-runs the summary for that single entry.

How do credits work?

Each plan includes a monthly allowance of AI credits. Credits are consumed by summarization: a live merge costs one summary, and the initial backfill of a repo is summarized in a single batched call rather than one per pull request. Every plan includes unlimited repositories, and credits reset each month.

What access does Recap need to my code?

You sign in with GitHub and grant repository access through OAuth. The token is stored encrypted and used to read pull request metadata and diffs, and to register the webhook on the repository you pick. Incoming webhook payloads are verified with an HMAC signature unique to each application, and requests that fail verification are rejected outright.

Who is the changelog written for?

Your team and the people who ask your team what shipped — engineering leads, founders, support and customer success. Summaries are allowed to carry technical detail, because the reader is internal.

How do I secure my Recap account itself?

Passkeys, two-factor authentication with recovery codes, and password confirmation on sensitive actions are all built in, alongside GitHub sign-in.

Stop writing changelogs. Start having one.

Connect a repository in under a minute. Your last 20 merged pull requests will be waiting for you when you land on the dashboard.

Get started for free Log in