asc-release-flow

asc-release-flow 技能概览

asc-release-flow 是一款面向“先判断能不能提审，再决定要修什么”的 App Store 发布就绪技能，适合使用 asc 的团队来判断应用现在是否可以提交，以及如果不能提交，应该先修哪些问题。它最适合你需要一条可执行的 App Store Connect 版本配置、校验、提审、首次上架、订阅、IAP、Game Center 和 App Privacy 发布路径，而不是泛泛地问“怎么把应用发出去”。

谁应该使用它

如果你已经在使用 App Store Connect，并且想要一份以提审就绪度为起点、以命令为导向的发布检查清单，就应该用 asc-release-flow 技能。它适合发布工程师、移动端开发者以及负责自动化构建的人，因为他们需要的是下一步该做什么，而不是一篇宽泛的政策综述。

它能帮你做什么

这个技能的核心问题是：“这个应用现在能提交了吗？”它会帮你区分哪些问题可以通过公共 API 由 asc 处理，哪些问题仍然需要网页会话步骤或人工介入。这种区分就是 asc-release-flow 指南的主要价值，尤其是在发布阻塞同时分布在元数据、审核状态和平台特定配置时。

什么时候最适合用

当你的工作流里已经包含 App Store Connect 凭证、应用标识以及版本/构建上下文时，选择 asc-release-flow for Deployment 最合适。它最擅长发布准备、预发布和提交流程，因为你希望减少猜测，并更清楚地梳理阻塞项。

如何使用 asc-release-flow 技能

安装 asc-release-flow 技能

使用以下命令安装：

npx skills add rudrankriyam/app-store-connect-cli-skills --skill asc-release-flow

要获得最佳的 asc-release-flow install 体验，请先确保你的环境里已经通过 asc auth login 或 ASC_* 变量提供了 App Store Connect 认证。这个技能默认你能先完成认证，再开始评估就绪度。

先提供正确的输入

asc-release-flow usage 这类用法在你提供应用的 APP_ID、版本号、BUILD_ID，以及流程需要时的 VERSION_ID 时效果最好。如果你使用的是基于元数据的分阶段发布，请把规范化元数据放到 ./metadata 里。像“帮我提交应用”这种笼统提示，远不如“检查 app 123456789 的 2.3.1 版本和 84 构建是否已准备好提审，并列出阻塞项”来得可执行。

按正确顺序阅读仓库

先看 SKILL.md，因为它定义了以就绪度为先的流程和回答顺序。然后再查看会影响执行上下文的仓库文件，尤其是 README.md、AGENTS.md、metadata.json，以及你副本中如果存在的 rules/、resources/、references/ 或 scripts/ 等目录。这个仓库刻意保持得很小，所以真正的收益在于先理解命令路径和阻塞分类，再开始操作。

按发布决策流程执行

使用这个技能时，建议按顺序拿到三样东西：就绪判断、阻塞清单、下一条命令。高质量的提问应该是直接检查是否可以提交，而不是泛泛咨询。例如：“使用 asc-release-flow 判断这个应用现在是否可以提审，把可通过 API 修复的阻塞与需要 web-session 或人工处理的阻塞分开，并给我下一条该运行的命令。” 这种提法更符合技能预期输出，也能减少来回追问。

asc-release-flow 技能常见问题

asc-release-flow 只用于 App Store 提审吗？

不是。它同样适用于分阶段发布、审核提交流程、首次上架、订阅、IAP、Game Center 和 App Privacy 检查。这个技能的范围比“提交版本”更广，但核心仍然围绕发布就绪度和发布执行。

它和普通提示词有什么不同？

普通提示词可能只是描述发布流程，而 asc-release-flow 的设计目标是强制给出有用的决策顺序：先看就绪度，再看阻塞项，接着看修复路径，最后给命令。对于需要可操作的 asc-release-flow guide，而不是探索性解释的场景，这种顺序更有用。

它适合新手吗？

只有当你能收集应用标识，并且理解元数据、构建挂载和审核状态问题之间的区别时，它才算对新手友好。如果你还不知道自己的 APP_ID，或者无法登录 App Store Connect，就应该先把这些基础问题解决掉；否则这个技能也给不出可靠的提交路径。

什么时候不该用它？

如果你要的是营销文案、应用发布策略，或者一个脱离 asc 的通用 App Store 检查清单，就不要用 asc-release-flow。如果你的组织不接受 web-session 或人工兜底步骤，或者你的发布边缘状态必须完全依赖这些步骤，那它也不太适合你。

如何改进 asc-release-flow 技能

给技能完整的发布上下文

想让 asc-release-flow 得到更好的结果，最关键的是提供准确的发布事实：应用 ID、版本、构建号、目标平台，以及你已经在 App Store Connect 里改过什么。如果你还能说明元数据、截图、审核备注、IAP、订阅或 App Privacy 是否已经准备好，它就能更快地区分真实阻塞和已经完成的配置。

要求它做阻塞分类，而不只是给建议

一个常见失败方式，是只问一个模糊的“发布计划”。更好的请求是：“告诉我这个版本现在是否已准备好，按 API 可修复、web-session 可修复和人工处理分类列出阻塞，并给出下一条确切命令。” 这种格式更贴合技能内部逻辑，也会产出更可执行的结果。

用第一轮结果推进下一轮

如果第一次运行就发现阻塞项，把这些阻塞连同准确的 App Store Connect 状态和你已经拿到的命令输出一起回传。对于 asc-release-flow for Deployment 来说，最有价值的迭代通常是：先做就绪检查，再做定向修复，然后再推进提交。错误细节给得越完整，技能需要猜测的地方就越少。

注意边界情况

这个技能最有价值的地方，正是 App Store Connect 流程在公共 API 支持和 web-session 或人工步骤之间分流的边界。如果你的应用涉及首次上架、首次审核的订阅挂载，或者 App Privacy 的发布状态，请尽早说明。这些情况往往比版本号本身更能改变路径，而 asc-release-flow 在这些场景里能提供最实用的信息增益。