Release notes should describe the behavior users receive, not every internal commit. Separate new capabilities, fixes and known limits, then verify that the package and source match the release.
- 1Changes since tag
- 2User-facing behavior
- 3Version consistency
- 4Release notes
Work through the example
Compare the installed package version with the changelog before publishing. Batch compatible fixes rather than releasing every cosmetic edit.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
[Unreleased]
- Source-only private feedback preview/approval tool and receiver for a private GitHub inbox. Explicit in-chat approval, fixed categories, private-destination checks and no public fallback. Hosting is not configured; no npm publication.
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Changes since tag | Confirm the input and environment | Preserve the failure and return to this step |
| User-facing behavior | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Version consistency | Run the focused check | Preserve the failure and return to this step |
| Release notes | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
This writing task does not authorize a new npm release.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- Review AI-generated Swift before you trust it
A focused review, a small patch and a real test beat a confident completion message.
What to do next
Next: CI for an iOS repo with agent-written code: what to run on every PR