ST

store-changelog

Creates platform-specific release notes derived from your Git commit history.

Install

mkdir -p .claude/skills/store-changelog && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3116" && unzip -o skill.zip -d .claude/skills/store-changelog && rm skill.zip

Installs to .claude/skills/store-changelog

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Generate release notes for app stores (Android Play Store, iOS App Store, macOS App Store, Linux Flatpak). Use when the user asks for changelogs, release notes, or store descriptions based on git history.
204 chars✓ has a “when” trigger
Beginner

Key capabilities

  • →Parse git history since the latest tag
  • →Categorize commits into features, improvements, and bug fixes
  • →Generate platform-specific release notes for Android, iOS, macOS, and Linux
  • →Format output for Play Store and App Store requirements
  • →Create XML-formatted metainfo for Flatpak

How it works

The skill parses commit logs between a specified tag and HEAD, categorizes the changes, and formats them according to the specific requirements of the target platform.

Inputs & outputs

You give it
Git tag or repository history
You get back
Formatted release notes for specific app stores

When to use store-changelog

  • →Generating App Store release notes
  • →Creating Play Store changelogs
  • →Formatting Git logs for public display

About this skill

Store Changelog Generator

Generate release notes for every FeedFlow store from the git history since a tag, get the user's approval, then translate them and write them into the repo files each store reads.

Workflow

1. Pick the tag

  • Use the tag the user gives (for example 1.18.0-all).
  • Otherwise run git describe --tags --abbrev=0 and tell the user which tag you used.
  • Tags are per platform (-all, -android, -ios). If the latest tag only covers one platform, check whether it holds anything the other platforms haven't shipped. For example, run git log <previous -all tag>..<latest tag>. Then say which range each platform's notes cover.

2. Read the changes

git log <tag>..HEAD --pretty=format:"%h %s%n%b" --no-merges

Keep only changes users would notice. Follow resources/release-notes-guidelines.md: leave out dependency bumps, translations, tests, docs, CI and tooling. Decide which platforms each change reaches. Shared code reaches every platform. Swift or iosApp/ reaches iOS and macOS. androidApp/ is Android only. desktopApp/ reaches Windows, Linux, and the macOS desktop build. Search ~/regesto-kb for recorded FeedFlow release-note decisions, for example release-note-format, and follow them.

3. Propose, then STOP

Show the user the full English notes for every platform, in the exact final format of each section below. Include:

  • the tag and commit range used
  • the character count of the Android notes
  • the changes you left out on purpose, and why

Do not translate or edit any file yet. Wait for the user to confirm or change the notes. Treat the text the user approves as final, and don't reword it in the next steps.

4. Translate and write the files (after confirmation only)

Translate the approved notes into every configured locale for each platform. Write each platform's notes to the files listed below. Keep the author's first-person singular voice in every language ("I'd love your feedback", never "we" or "us").

5. Validate and report

  • Android: count each file with Python len() on the UTF-8 text. wc -m counts bytes in the C locale. If a locale is over 500 characters, tighten that translation, keeping every bullet.
  • Microsoft Store and App Store: jq empty <file>, and check that every locale has the same number of bullets as English.
  • Flatpak: xmllint --noout desktopApp/packaging/flatpak/com.prof18.feedflow.metainfo.xml.
  • Run git diff --check.
  • Report which files changed, the locale count for each platform, and any translation you shortened. Say that the translations are machine-made and need a native review.

Do not commit, upload, or publish anything unless the user asks. Pushing notes to a store is a separate step: see update-store-release-notes for App Store Connect, and pcenter and the release workflow for the Microsoft Store.

Platforms: formats and files

All platforms use the same bullet format: one • bullet per line, one sentence each, starting with the benefit. No section headers.

Android (Google Play)

  • Limit: 500 characters per locale, including bullets and newlines. Pick the 4–5 changes with the most impact.
  • Files: androidApp/src/googlePlay/play/release-notes/<locale>/production.txt. en-US is the source. Every other locale folder is a target. Never touch alpha.txt.
  • After writing, also give the Play Console block: en-US first, then the other locales in alphabetical order. Save it to the scratchpad and send it to the user as well:
    <en-US>
    • ...
    </en-US>
    <bg>
    • ...
    </bg>
    

iOS and macOS (App Store)

  • iOS and macOS are separate apps with separate copy. Highlight the changes each platform actually gets: scrolling and iPad on iOS, windows and keyboard on macOS.
  • Same simple bullet list as the other platforms, with no headers. Example:
    • Reader Mode has a brand-new engine that gives cleaner, more reliable articles. If a page doesn't look right, I'd love to hear your feedback.
    • Smoother scrolling in the article list, especially on iPad.
    
  • File: assets/storecopy/app-store-release-notes.json, shaped as { "ios": { "<locale>": [bullets] }, "macos": { "<locale>": [bullets] } }. Each bullet string includes the leading • .
  • The keys are App Store Connect locale codes: en-US, de-DE, es-ES, fr-FR, he, hu, it, ja, pt-BR, ru, sk, uk, vi, zh-Hans. If App Store Connect may have gained or lost a language, confirm the list with a read-only asc query.

Windows (Microsoft Store)

  • File: assets/storecopy/microsoft-store-release-notes.json. It keeps the top-level notes object. Each locale value is an array of bullet strings that include the leading • .
  • Update every existing locale key. Alias keys (de/de-de, es/es-es, gl/gl-es, zh-cn/zh-hans) get identical text. A missing locale fails the publish.
  • Include Windows-only fixes (for example Google Drive sign-in). Mention only the sync providers the Windows app has.

Linux (Flatpak)

  • File: desktopApp/packaging/flatpak/com.prof18.feedflow.metainfo.xml. Add a new <release> as the first child of <releases>, using the version from the com.feedflow.versioning convention plugin and the release date. English only.
      <release version="X.X.X" date="YYYY-MM-DD">
          <description>
              <p>Feature or fix description</p>
          </description>
      </release>
    
  • Leave out Google Drive: Flatpak builds disable it.

Resources

  • resources/release-notes-guidelines.md: rules for language, filtering and QA.

When not to use it

  • →When the project does not use git tags for versioning
  • →When commit messages are not descriptive enough for categorization

Prerequisites

git

Limitations

  • →Depends on the quality and consistency of commit messages
  • →Limited to the formats defined for supported platforms

How it compares

It automates the transformation of raw git logs into platform-compliant release notes, saving manual formatting time.

Compared to similar skills

store-changelog side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
store-changelog (this skill)18moNo flagsBeginner
prepare-changelog69moReviewBeginner
workthrough1010moReviewBeginner
generate-release-notes79moReviewIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

prepare-changelog

nextest-rs

Guidelines for preparing changelog entries for nextest releases following Keep a Changelog format

689

workthrough

bear2u

Automatically document all development work and code modifications in a structured workthrough format. Use this skill after completing any development task, bug fix, feature implementation, or code refactoring to create comprehensive documentation.

1085

generate-release-notes

teambit

Generate comprehensive release notes for Bit from git commits and pull requests. Use when creating release notes, building changelogs, documenting version releases, or preparing a new Bit release.

752

changelog-generator

ComposioHQ

Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.

346

release-note-generation

microsoft

Toolkit for generating PowerToys release notes from GitHub milestone PRs or commit ranges. Use when asked to create release notes, summarize milestone PRs, generate changelog, prepare release documentation, request Copilot reviews for PRs, update README for a new release, manage PR milestones, or collect PRs between commits/tags. Supports PR collection by milestone or commit range, milestone assignment, grouping by label, summarization with external contributor attribution, and README version bumping.

537

doc-check

coder

Checks if code changes require documentation updates

427

Search skills

Search the agent skills registry