App Store Changelog

3) Draft App Store notes

• Write short, benefit-focused bullets for each user-facing change.
• Use clear verbs and plain language; avoid internal jargon.
• Prefer 5 to 10 bullets unless the user requests a different length.

4) Validate

• Ensure every bullet maps back to a real change in the range.
• Check for duplicates and overly technical wording.
• Ask for clarification if any change is ambiguous or possibly internal-only.

Commit-to-Bullet Examples

The following shows how raw commits are translated into App Store bullets:

Internal-only commits that are dropped (no user impact):

• chore: upgrade fastlane to 2.219
• refactor(network): extract URLSession wrapper into module
• ci: add nightly build job

Example Output

What's New in Version 3.4

• Search your library hands-free with the new voice input option.
• Scrolling through your timeline is now smoother and faster.
• Fixed a login issue that could leave some users unexpectedly signed out.
• Added dark-mode support to the settings screen.
• Improved load times when opening large photo albums.

Output Format

• Title (optional): "What's New" or product name + version.
• Bullet list only; one sentence per bullet.
• Stick to storefront limits if the user provides one.

Resources

• scripts/collect_release_changes.sh: Collect commits and touched files since last tag.
• references/release-notes-guidelines.md: Language, filtering, and QA rules for App Store notes.

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.