使用说明

核心用法

该 Skill 通过执行 scripts/collect_release_changes.sh 脚本，自动收集自上个 Git 标签以来的所有提交记录和变更文件，然后筛选出对用户可见的改动，按主题（新增、优化、修复）分组去重，最终输出简洁明了的 App Store "What's New" 文案。

显著优点

自动化提效：一键从 Git 历史生成交付物，省去手动整理提交日志的繁琐工作
用户视角转换：内置过滤规则自动剔除内部重构、CI 配置、依赖升级等技术债务类提交
结构化输出：按 "New/Improved/Fixed" 模板组织，符合主流应用商店的内容规范
灵活溯源：支持指定任意 Git 引用范围（标签或 commit），适应多种发布节奏

潜在局限

依赖前置脚本：必须存在 scripts/collect_release_changes.sh 才能执行核心功能，若仓库未配置则无法运行
语义理解有限：基于文件路径和提交 message 做启发式过滤，可能误判用户价值（如 UI 重构被误认为内部改动）
语言本地化不足：输出为英文模板，如需多语言上架需额外处理
无法验证真实性：Skill 本身不验证脚本返回数据的准确性，需人工复核

适合人群

移动应用开发团队的产品运营人员
需要频繁发版、维护多个渠道 release notes 的 DevOps 工程师
缺乏专职运营、需技术团队兼管上架文案的初创公司

常规风险

信息泄露风险：若过滤规则不完善，可能将内部缺陷编号、敏感文件名暴露到公开商店页
过度承诺风险：自动生成的 "优化性能" 类描述可能与实际用户感知不符，引发差评
合规风险：部分平台（如 App Store）对 "What's New" 有字数和禁用词限制，需人工最终校验

安全解读

核心用法

app-store-changelog 是一个专注于将 Git 提交历史转换为用户友好型 App Store 发布说明的 Skill。其工作流程分为四步：首先通过 collect_release_changes.sh 脚本采集自上一标签以来的所有提交和文件变更；随后基于用户可见性进行筛选，剔除构建脚本、CI 配置、依赖升级等内部工作；接着将有效变更按「新增」「优化」「修复」三类主题组织，生成 5-10 条简洁明了、以用户利益为导向的要点；最后验证每条 bullet 均对应真实代码变更，避免杜撰或技术术语堆砌。

显著优点

安全透明：纯本地 Bash 脚本实现，仅调用系统 Git 命令，无网络请求、无第三方依赖、无敏感信息收集，通过六维安全检测（静态分析、动态行为、依赖审计、网络、隐私、威胁情报）全部满分。
零配置上手：自动检测最近 Git 标签作为变更基准，支持自定义起止版本，无需手动维护变更日志。
用户视角：内置过滤规则自动识别「用户可见 vs 内部工作」，输出语言符合 App Store 审核指南。
轻量高效：仅 34 行代码、4 个文件，扫描耗时 <20 秒，适合集成到 CI/CD 流水线。

潜在局限

功能单一：仅支持 Git 仓库，对 SVN/Mercurial 等版本控制无效；若仓库无标签则需全量扫描，大型历史可能产生噪音。
语义依赖：依赖提交信息质量，若团队提交规范混乱（如全用 "fix bug"），需人工介入提炼。
无国际化：当前输出为单一语言，多语言 App Store 需外部翻译流程。

适合人群

移动应用开发团队（iOS/Android）需要自动化「What's New」文案生成
产品经理或运营人员希望降低技术沟通成本，直接获取用户可读的更新摘要
追求供应链安全的组织（零依赖、可审计代码）

常规风险

T3 来源风险：作者为社区个人开发者，无企业背书，建议结合人工代码审查后用于生产。
Git 环境依赖：要求运行环境已安装 Git 且当前目录为有效仓库，否则脚本将报错退出。
标签管理：若团队标签策略混乱（如重复标签、轻量标签与附注标签混用），可能影响变更范围判定。

git release-management app-store automation technical-writing changelog

App Store Changelog 内容

references文件夹

scripts文件夹

手动下载zip · 2.7 kB

release-notes-guidelines.mdtext/markdown

请选择文件