Add a check on the release PRs to verify (via AI) that all documentation is accurate and up-to-date with the proposed release #277

New issue

Closed

opened 2026-01-01 09:51:40 -08:00 by jwilger · 0 comments

jwilger commented

2026-01-01 09:51:40 -08:00

(Migrated from github.com)

Is your feature request related to a problem? Please describe.
When someone is using the library, if the documentation is outdated, then they are not able to use it effectively without a lot of friction. They may even give up on the library entirely.

Describe the solution you'd like
When a release PR is created in GH Actions, there should be a check that verifies all of our user-facing (i.e. developers using eventcore and/or implementing backends) documentation is accurate and up-to-date for the state of the library in the proposed release. If there are any changes needed, it should open a new PR to main with the proposed changes and fail the check. This could be implemented as a claude code review, replacing the normal review that happens on regular PRs (which we currently skip on release PRs).

Describe alternatives you've considered

just remembering to do it (people won't)
doing it as part of every PR (sometimes the API is in flux before a release, and that would be wasted effort)

**Is your feature request related to a problem? Please describe.** When someone is using the library, if the documentation is outdated, then they are not able to use it effectively without a lot of friction. They may even give up on the library entirely. **Describe the solution you'd like** When a release PR is created in GH Actions, there should be a check that verifies all of our user-facing (i.e. developers using eventcore and/or implementing backends) documentation is accurate and up-to-date for the state of the library in the proposed release. If there are any changes needed, it should open a new PR to main with the proposed changes *and fail the check*. This could be implemented as a claude code review, replacing the normal review that happens on regular PRs (which we currently skip on release PRs). **Describe alternatives you've considered** - just remembering to do it (people won't) - doing it as part of every PR (sometimes the API is in flux before a release, and that would be wasted effort)