Help/Recipes/Automations

Save every release to onecell from GitHub Actions

For
A release owner or tech lead who wants a searchable history of what shipped without writing it up
When
Once, in the repo; then every release
Takes
A few minutes to set up
You get
A draft in onecell for each release, tagged src:github, that search, agents and the Monday brief can find
Add a GitHub Actions workflow to this repo that saves every published
release to onecell. Follow https://onecell.io/p/automations.md exactly.

1. Create .github/workflows/release-to-onecell.yml, triggered on
   release: published. It reads ONECELL_API_KEY from secrets.

2. It calls create_document at https://onecell.io/api/mcp with:
   - cell: <cell>
   - slug: release-<tag>, lowercased, so a rerun gets slug_taken
     instead of a duplicate
   - title "Release <tag>: <release name>", a one-line summary
   - tags ["release", "src:github"]
   - the release body and a link to the release
   - dry_run: false
   The step fails only if the call fails and the slug is not taken.

3. Don't put the key in the file, and don't print it in logs.

4. Open a pull request with the workflow and tell me how to test it.

What your agent does

  1. Reads the guide

    The Automations guide, as Markdown, so the workflow matches what onecell expects.

  2. Writes the workflow

    One job, one curl call, built with jq so release notes with quotes or newlines can't break it.

  3. Makes reruns safe

    The slug comes from the tag, so a retried job does nothing instead of writing twice.

  4. Opens a pull request

    You review the workflow like any other change.

What you get back

Open the full example →

A release of Tally, a made-up invoicing app, saved by the workflow seconds after it was published. Someone linked it to the decision it carried out, then published it.

Sample release note: Tally v2.15.0, saved by GitHub Actions

Published on GitHub as v2.15.0 on 21 August by the release workflow. Merged since v2.14.0: 9 pull requests.

What changed

  • Reminders are sent from the job queue, each with its own key, so none is ever sent twice (#431).
  • Deploys during the reminder window wait until it ends (#428).
  • Invoice PDFs show the client's VAT number when they have one (#433).

Settings

.env+1 −1
Removed: REMINDERS_QUEUE=off
Added: REMINDERS_QUEUE=on

Linked

Carries out the decision Move reminders to the job queue and closes the last action in Postmortem: invoice reminders sent twice.

Variations

Every merge to main, not every release

Trigger on push to main and write one running changelog document instead: read it with get_document, add the merge at the top, and save with update_document and expected_version.

Deploys and incidents

Call the same step at the end of your deploy job, with a slug from the deploy id. On a failed deploy, write it to an incidents cell instead; it becomes the first draft of the postmortem.

Let an agent write the notes

Run Claude Code in the job with -p and the Repo snapshot recipe's prompt, so the release note groups changes by area and links the decisions it carried out.

Tips

  • One key per workflow, Drafts only. Revoke it and the workflow stops writing.
  • The src:github tag lets anyone list what automation wrote, apart from people's notes.
  • Keep secrets and customer data out of release notes; they will be searchable.