asc-notarization

asc-notarization 技能概览

asc-notarization 是一套实用的 macOS 发布流程技能，覆盖使用 xcodebuild 和 asc 对应用进行归档、导出、签名和公证。它特别适合需要从构建产物稳定走到 Apple notarization 的 App Store 外发布场景，尤其是在证书或信任问题可能阻塞发布时。

适合谁使用

如果你已经有一个 macOS 应用项目，并且需要一套可重复的 Developer ID 分发公证流程，就适合使用 asc-notarization 技能。它最适合发布工程师、独立开发者，以及自动化代理——这些角色需要准备的是一个已签名的 app bundle，而不只是理解 notarization 的概念。

它解决什么问题

它的核心作用，是减少在提交构建产物做 notarization 之前，对预检检查、签名身份验证和信任链失败的猜测。asc-notarization 指南可以帮你尽早发现那些典型的“本地能构建，但就是无法 notarize”的问题，而这正是大多数发布阻力的来源。

为什么它有用

不同于泛泛的提示词，asc-notarization 聚焦的是实际发布顺序：先检查前置条件，再核对签名身份，修复证书信任问题，最后再归档并 notarize。对于需要可直接落地的指导，而不是 macOS 代码签名高层概览的场景，它更合适。

如何使用 asc-notarization 技能

安装并加载该技能

使用 npx skills add rudrankriyam/app-store-connect-cli-skills --skill asc-notarization 安装，然后先打开 SKILL.md。由于这个仓库目前只有一个技能文件，没有配套脚本或参考资料，技能正文就是工作流和约束的唯一依据。

先提供正确的输入

当你的请求包含应用名称、项目路径、签名配置，以及具体失败点或目标时，asc-notarization 的效果最好。例如：“用 Developer ID Application 签名把 /path/to/project 里的 macOS target 做公证，并帮我排查任何 trust-chain 错误。”

按正确顺序阅读工作流

在使用 asc-notarization 时，应先读前置条件，再尝试归档或导出步骤，然后检查预检身份验证、信任设置修复和证书链验证。这些部分很重要，因为它们能告诉你，阻塞点到底是环境配置、证书状态，还是项目配置。

用具体的发布需求来提问

这个技能的高质量提示词应该明确分发目标和期望产出，例如：“为我的 macOS 应用准备外部分发，验证签名身份，生成可用于 notarization 的归档，并解释任何证书不匹配问题。” 这类输入能让技能输出更有操作性的 asc-notarization 指南，而不是一份泛泛的检查清单。

asc-notarization 技能 FAQ

asc-notarization 只适用于 App Store 分发吗？

不是。这个技能面向的是 App Store 之外分发的 macOS 应用，这类场景需要 Developer ID 签名和 Apple notarization。如果你的发布路径是提交到 App Store Connect，那么你大概率需要另一套工作流。

我需要先有 macOS 发布经验吗？

不需要，但你确实需要一个可用的 Xcode 环境和有效的签名身份。asc-notarization 对新手是友好的，因为它从检查项开始，但它仍然默认你能运行终端命令，并理解基本的 Xcode 项目设置。

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

普通提示词可能只是解释 notarization 的一般概念。asc-notarization 更偏向执行层面：它围绕前置条件、签名验证以及损坏的信任设置修复展开，而这些细节通常才决定部署能否成功。

什么情况下不该用它？

如果你的应用不面向 macOS、你无法访问 Developer ID 证书，或者你要找的是纯粹的 App Store 提交指南，就不要用 asc-notarization。它也不适合需要广义 CI/CD 方案，而不是聚焦 notarization 工作流的场景。

如何改进 asc-notarization 技能

一开始就给它构建和签名事实

asc-notarization 的最佳输出来自精确细节：项目类型、target 名称、签名证书名称、认证方式，以及你看到的错误文本。相比之下，“xcodebuild 在 archive 时失败，报 errSecInternalComponent”要比“我的签名坏了”有用得多。

提供真正影响结果的发布约束

告诉技能你是在本地还是在 CI 中操作，应用是否已经签名，以及你是否可以修改钥匙串信任设置。这些约束会直接影响 asc-notarization 指南的侧重点，并决定答案是更偏诊断、修复，还是发布顺序安排。

不只问修复，还要问下一步检查什么

如果第一次尝试失败，就继续追问下一步验证项：证书链、信任覆盖、归档设置，或者导出时使用的签名身份。这样的方式能让 asc-notarization 在 Deployment 场景下更好用，因为它把一次失败的发布变成一条可控的排障流程，而不是反复盲试。