App Store Changelog

**Judgment:** A focused, high-utility skill for teams that ship apps via the App Store and manage releases via git tags; particularly valuable when you want consistent, concise "What’s New" sections driven directly from commit history. **Strengths:** - Aligns closely with a common real-world workflow: gather commits since the last tag and turn them into App Store-ready bullets. - Explicitly filters for user-visible changes and avoids internal noise (CI, refactors, dependency bumps). - Encourages best practices (plain language, one-sentence bullets, 5–10 items) and respects storefront length limits when provided. **Key Risks / Limitations:** - Quality depends heavily on commit messages and tagging discipline; poorly written or inconsistent commits may lead to thin or ambiguous notes. - Internal-only work might still leak into notes if commits are mislabeled or mixed (e.g., user-facing + refactor in one commit). - Requires the user to correctly run the `scripts/collect_release_changes.sh` script and supply the results; misconfigured ranges or missing tags could produce incomplete or overly long changelogs. **Recommended Scenarios:** - You have an iOS/macOS app with a reasonably clean git history and tags per release, and you need fast, consistent App Store release notes. - You want to standardize how different teams write "What’s New" text while still grounding every bullet in real code changes. - You’re preparing a release with many commits and need help triaging which changes are truly user-facing vs. internal housekeeping.