Start with a confirmed release
Release notes fail when they are written from a list of merged pull requests and treated as a record of what customers received. A merge is evidence of a code change, not proof that it reached production. Start with a confirmed release manifest, then add linked issues, approved product names, and the intended audience.
Ask Nema to separate confirmed releases from changes that are merely merged, staged, or planned. That keeps an attractive draft from turning uncertain status into a public claim.
Give Nema the right inputs
Provide the release version and date, the confirmed manifest, linked change records, and any writing guide the product team uses. Include known limitations and rollout notes when they affect what a customer can use.
If the release covers several plans or regions, supply that scope explicitly. Nema can call out missing plan availability rather than guessing from an issue title.
Review the draft in Slack
Nema can group related changes, translate internal issue language into customer-readable copy, and link each note to its source. The draft appears in the release channel where engineering, product, and support can challenge it.
A useful review asks three questions: did it ship, who can use it, and does the note promise more than the change delivers? The release owner resolves those questions before publication.
A practical example
Suppose the manifest confirms a new export filter and a permissions fix. A dashboard redesign is merged but absent from the deployment record. Nema drafts notes for the two confirmed changes and puts the redesign in a "needs confirmation" section. It also flags that the permissions fix affects administrators only.
The release owner checks the manifest, revises the customer language, and approves the draft. Nema prepares content for review. It does not claim to publish or verify deployment without an authorized, tested path.
Make it repeatable
Teach the release channel the preferred note format, terminology, and evidence requirements. A recurring prompt can prepare the next draft when a release record is supplied. Keep release confirmation as an explicit input rather than relying on memory.
Common questions
Can Nema write notes from pull requests?
Pull requests can provide supporting detail, but they do not prove deployment. Pair them with a confirmed release manifest and let the release owner verify scope.
Can Nema publish the release notes?
Nema can draft the content. Any publishing action should use a verified connection and require the release owner's review.
How should phased rollouts be described?
Provide the actual rollout scope and dates. Nema can state the confirmed availability and flag unknown regions, plans, or cohorts.