ASC CLI Skills · App Store Connect CLI Agent Skills
rorkai/App-Store-Connect-CLI 為 AI 智慧代理提供了一整套 ASC CLI Skills（又稱 AscSkill / AscCliSkill），覆蓋建置打包、簽名分發、TestFlight、中繼資料本地化、訂閱定價和廣告投放。本頁收錄全部 ASC Skills 的中文說明與可直接使用的命令示例。
# 全域安裝 25 個經審查的 asc 技能$asc install-skills四步完成從安裝到首個 API 呼叫。發佈的二進位制檔案自帶執行環境，安裝後即可在終端、IDE 或 CI/CD 流水線中使用。
透過 Homebrew、安裝指令碼或 WinGet 獲取二進位制檔案，發佈版本自帶執行環境，無需額外安裝 Go。
在設定驗證前，先確認命令可以正常執行。
$asc version$asc --help在 App Store Connect 生成 API 金鑰後，使用金鑰登入；CI 或無金鑰串環境可加 --bypass-keychain。
$asc auth login \$ --name "MyApp" \$ --key-id "ABC123" \$ --issuer-id "DEF456" \$ --private-key /path/to/AuthKey.p8 \$ --network確認驗證狀態健康，然後拉取一次應用列表確認一切就緒。
$asc auth status --validate$asc auth doctor$asc apps list --output table# 推薦方式（macOS / Linux）$brew install asc將 25 個官方技能一次性安裝到全域 agent-skills 目錄，跨專案可用，且鎖定到已審核的提交版本。
$git --version$asc install-skills共 25 個技能
asc-cli-usage
這是所有工作流的起點技能：幫助智慧代理或開發者選擇正確的 asc 命令、規範的參數組合、分頁方式與輸出格式（JSON / table / markdown），並覆蓋 Apple Ads 相關的驗證與分頁細節。
# 不確定命令時，先用本地搜尋發現命令路徑$asc search "submit app for review"# 以 JSON 格式列出某應用的全部建置，並自動翻頁$asc builds list --app 123456789 --output json --paginateasc-app-create-ui
App Store Connect 目前沒有公開 API 用於建立新應用，該技能透過受控的瀏覽器自動化完成應用名稱、Bundle ID、SKU 與主要語言的填寫與提交。
# 第一步：先透過公開 API 註冊 Bundle ID，並確認尚無同名應用記錄$asc bundle-ids create --identifier "com.example.myapp" --name "My App" --platform IOS$asc apps list --bundle-id "com.example.myapp" --output json# 第二步：交給智慧代理在瀏覽器裡填寫 New App 表單（名稱 / SKU / 主語言）對智慧代理說建立一個 Bundle ID 為 com.example.myapp、SKU 為 MYAPP123、主語言為英語（美國）的新 App Store Connect 應用# 第三步：建立後透過 API 校驗，並繼續設定主語言、分類等$asc apps list --bundle-id "com.example.myapp" --output json$asc app-setup info set --app "APP_ID" --primary-locale "en-US"asc-xcode-build
覆蓋從本地 Xcode 專案到可上傳產物的全過程：建置、封存（archive）、生成並自定義 ExportOptions.plist、匯出 IPA 或 PKG，並能管理版本號與建置號（asc xcode version）、銜接 asc builds upload / asc publish 完成上傳，以及排查常見的匯出簽名與建置號問題。
# 自動取下一個可用建置號，再封存並匯出（具體參數請用 asc xcode archive --help 檢視）$asc xcode version edit --next-build-number --app "APP_ID" --platform IOS對智慧代理說封存並匯出我的 iOS 應用為 IPA，以便上傳到 App Store Connect# 匯出後上傳，或直接發佈到 TestFlight$asc builds upload --app "APP_ID" --ipa ".asc/artifacts/App.ipa" --wait$asc publish testflight --app "APP_ID" --ipa ".asc/artifacts/App.ipa" --group "GROUP_ID" --waitasc-id-resolver
許多 asc 命令需要精確的資源 ID（應用、建置、App 版本、數字商品版本、測試組、測試員等），該技能負責把名稱解析為確定性的 ID，也支援 API 4.4.1 中 IAP / 訂閱 / 訂閱組版本 ID 的解析，便於自動化指令碼消費。
# 解析應用 ID、最新建置 ID 與 TestFlight 測試組 ID$asc apps list --output table$asc builds info --app "APP_ID" --latest --platform IOS --output json$asc testflight groups list --app "APP_ID" --paginate --output json# API 4.4.1：解析訂閱版本 ID 與訂閱組版本 ID$asc subscriptions versions list --subscription-id "SUB_ID" --paginate --output json$asc subscriptions groups versions list --group-id "GROUP_ID" --paginate --output jsonasc-release-flow
負責把準備好的應用版本或建置產物送到 App Store：在 asc release stage（準備中繼資料並關聯已有建置，但不提交審核）、asc review submit（提交已就緒的版本）、asc publish appstore（上傳 IPA 並可選提交）之間做出正確選擇，並支援組裝包含 Game Center 或數字商品版本的多項提交。只讀準備情況診斷、監控與重試請使用「提交健康診斷」技能。
# 暫存：沿用上一版本的本地化中繼資料並關聯建置，預覽計畫（不會建立審核提交）$asc release stage --app 123456789 --version 1.2.3 --build-id BUILD_ID --copy-metadata-from 1.2.2 --dry-run# 暫存就緒後，先預覽再提交審核$asc review submit --app 123456789 --version 1.2.3 --build-id BUILD_ID --dry-run$asc review submit --app 123456789 --version 1.2.3 --build-id BUILD_ID --confirm# 或：一步完成上傳、關聯建置與提交審核$asc publish appstore --app 123456789 --ipa ./MyApp.ipa --version 1.2.3 --submit --confirmasc-submission-health
當校驗報告中繼資料、合規性、數字商品或 App Privacy 阻塞時，該技能負責判斷應用當前是否可以提交、對每個阻塞項分類、給出修復路徑，並支援監控、取消與安全重試的決策。發佈與提交的具體執行請使用「發佈流程編排」技能。
# 校驗版本並檢視嚴格模式下的阻塞詳情$asc validate --app 123456789 --version 1.2.3 --output json$asc validate --app 123456789 --version 1.2.3 --strict# 校驗內購與訂閱，並做審核準備情況診斷$asc validate iap --app 123456789 --output table$asc validate subscriptions --app 123456789 --output table$asc review doctor --app 123456789 --version 1.2.3 --platform IOS --output table# 監控審核狀態；必要時取消提交$asc review status --app 123456789 --version 1.2.3 --platform IOS --output table$asc submit cancel --version-id VERSION_ID --app 123456789 --confirmasc-signing-setup
覆蓋新應用或新 Bundle ID 的接入、證書與描述檔的建立或輪換，以及透過加密 Git 倉庫（類似輕量版 fastlane match）同步私鑰身份、協調（reconcile）Ad Hoc 描述檔、在隔離簽名環境中執行命令等高階場景。
# 為 Bundle ID 啟用 iCloud 能力，建立分發證書（同時生成金鑰與 CSR）$asc bundle-ids capabilities add --bundle "BUNDLE_ID" --capability ICLOUD$asc certificates create --certificate-type IOS_DISTRIBUTION --generate-csr --key-out "./signing/dist.key" --csr-out "./signing/dist.csr"# 建立 App Store 描述檔並下載$asc profiles create --name "AppStore Profile" --profile-type IOS_APP_STORE --bundle "BUNDLE_ID" --certificate "CERT_ID"$asc profiles download --id "PROFILE_ID" --output "./profiles/AppStore.mobileprovision"asc-ad-hoc-distribution
使用實驗性的 asc distribute 工作流，面向註冊裝置準備併發布私有的 iOS 安裝包；會先給出只讀計畫，再執行追加式的簽名與儲存變更，並支援斷點續傳與即時校驗私有的 S3 相容分發流程。
# 先規劃（只讀），確認計畫後再執行；中斷後可斷點續傳並校驗對智慧代理說基於這個 Xcode 封存規劃一次私有的 release-testing 安裝，先展示具體影響，我確認計畫雜湊後再執行# 對應的子命令（參數請用 --help 檢視）$asc distribute plan --help$asc distribute apply --help$asc distribute resume --run "RUN_ID" --state-dir ".asc/distribution/runs" --output json$asc distribute verify --run "RUN_ID" --state-dir ".asc/distribution/runs" --timeout 30s --output jsonasc-notarization
覆蓋 App Store 之外分發 macOS 應用所需的完整鏈路：封存 → Developer ID 匯出 → 壓縮 → 提交公證（asc notarization）→ 裝訂（可選，使用 xcrun stapler），並幫助排查 Developer ID 簽名或信任鏈問題。
# 封存並以 Developer ID 方式匯出（交給智慧代理執行 xcodebuild）對智慧代理說封存我的 macOS 應用，以 Developer ID 方式匯出並壓縮為 zip# 提交公證並等待結果；失敗時檢視開發者日誌$asc notarization submit --file "./YourApp.zip" --wait$asc notarization log --id "SUBMISSION_ID"# 公證透過後裝訂票據（Apple 自帶工具，非 asc 命令）$xcrun stapler staple "./YourApp.app"asc-testflight-orchestration
適合同時維護多個 TestFlight 測試組與測試員名單的團隊，提供一致的 Beta 發佈步驟，覆蓋建立分組、新增測試員、關聯最新建置與撰寫測試說明。
# 匯出當前 TestFlight 設定，建立測試組並新增測試員$asc testflight config export --app "APP_ID" --output "./testflight.yaml"$asc testflight groups create --app "APP_ID" --name "Beta Testers"$asc testflight testers add --app "APP_ID" --email "tester@example.com" --group "Beta Testers"# 把建置分發給測試組，並寫入「測試重點」$asc builds add-groups --build-id "BUILD_ID" --group "GROUP_ID"$asc builds test-notes create --build-id "BUILD_ID" --locale "en-US" --whats-new "請重點測試登入流程"asc-build-lifecycle
在等待 Apple 處理建置、需要自動解析「最新可用建置」，或希望按保留策略批次清理過期 TestFlight 建置時使用，支援自動化清理與保留策略預覽。
# 找到最新建置，並獲取下一個可用建置號$asc builds info --app 123456789 --latest --version 1.2.3 --platform IOS$asc builds next-build-number --app 123456789 --version 1.2.3 --platform IOS# 預覽過期 90 天以上建置的清理計畫，確認後再執行$asc builds expire-all --app 123456789 --older-than 90d --dry-run$asc builds expire-all --app 123456789 --older-than 90d --confirmasc-crash-triage
按崩潰簽名、裝置與建置對最近的 TestFlight 崩潰報告進行分組彙總，同時檢查 Beta 測試員回饋與截圖，並提供啟動耗時、卡頓、磁碟寫入等效能診斷資料。
# 檢視最近 10 條 TestFlight 崩潰與帶截圖的 Beta 回饋$asc testflight crashes list --app "APP_ID" --sort -createdDate --limit 10 --output table$asc testflight feedback list --app "APP_ID" --sort -createdDate --limit 10 --include-screenshots# 檢視某個建置的卡頓（HANGS）診斷$asc performance diagnostics list --build-id "BUILD_ID" --diagnostic-type "HANGS"# 讓智慧代理按簽名和受影響建置分組彙總對智慧代理說展示 MyApp 最新的 TestFlight 崩潰與回饋，按簽名和受影響建置分組asc-screenshot-resize
結合 asc screenshots sizes 返回的最新尺寸目錄與 macOS 的 sips 工具，檢查截圖尺寸是否符合 Apple 當前要求，去除 Alpha 通道、按裝置型別調整尺寸，並在上傳前完成本地校驗。
# 檢視 Apple 當前接受的截圖尺寸，並校驗本地截圖$asc screenshots sizes --output table$asc screenshots validate --path "./screenshots/iphone" --device-type "IPHONE_65" --output table# 用 macOS 自帶 sips 調整尺寸（寬 1284 × 高 2778），再重新校驗$sips -z 2778 1284 input.png --out output.pngasc-shots-pipeline
面向智慧代理的截圖流水線：使用 xcodebuild / simctl 啟動模擬器，透過 AXe 驅動介面互動完成截圖採集，再用實驗性的 asc screenshots frame 加殼取景，最後透過 asc screenshots upload 上傳；支援查詢可用取景裝置，並推薦固定版本的 Koubou 以保證取景結果可復現。
# 建置應用，採集首頁與設定頁截圖，取景後準備上傳對智慧代理說建置我的 iOS 應用，在模擬器中採集首頁與設定頁截圖，加殼取景後準備好上傳# 對應的 asc 子命令（取景前需安裝 Koubou：kou setup-frames）$asc screenshots list-frame-devices --output json$asc screenshots frame --help$asc screenshots upload --helpasc-metadata-sync
負責 App Store 中繼資料與本地化內容的雙向同步，包括從舊版中繼資料格式遷移、上傳前的字數限制校驗，以及更新隱私政策連結等應用級中繼資料。
# 拉取線上中繼資料 → 本地校驗字數限制 → 以 dry-run 預覽回寫$asc metadata pull --app 123456789 --version 1.2.3 --platform IOS --dir ./metadata$asc metadata validate --dir ./metadata --output table$asc metadata push --app 123456789 --version 1.2.3 --platform IOS --dir ./metadata --dry-run# 應用級欄位（如隱私政策連結）使用 app-setup$asc app-setup info set --app 123456789 --primary-locale en-US --privacy-policy-url "https://example.com/privacy"asc-localize-metadata
從源語言（通常是 en-US）出發，將應用描述、關鍵詞、更新說明、副標題等翻譯為多個本地化語言；關鍵詞采用「符合當地搜尋習慣」而非字面翻譯，並嚴格執行各欄位的字元數限制，提供上傳前的人工複核環節。
# 下載源語言本地化 → 交給 LLM 翻譯 → 上傳前人工複核$asc localizations download --version "VERSION_ID" --path "./localizations"對智慧代理說把我的 en-US App Store 中繼資料翻譯成德語、法語和日語，上傳前先給我看改動$asc localizations upload --version "VERSION_ID" --path "./localizations"asc-aso-audit
對副標題、關鍵詞、描述、更新說明等欄位做格式與「浪費空間」問題審計，結合 Astro 跟蹤的排名與競品關鍵詞做差距分析，並給出能直接對應到 asc metadata keywords 命令的後續動作。
# 先拉取規範化中繼資料，再做離線審計$asc metadata pull --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata"對智慧代理說審計 ./metadata 中的 ASO 問題，再展示 Astro 中針對我最新版本的高價值關鍵詞差距# 審計後的關鍵詞調整可直接對應到：$asc metadata keywords diff --app "APP_ID" --version "1.2.3" --platform IOS --dir "./metadata"asc-whats-new-writer
基於 ./metadata 下的規範化中繼資料，從 git 提交記錄、要點列表或自由文本生成打磨過的 What's New 文案，並可將其本地化到已有的所有語言，提供基於 asc metadata push 或直接編輯中繼資料的上傳前複核流程。
# 把發佈要點整理成文案並本地化到現有語言對智慧代理說把這些發佈要點整理成 en-US 的更新說明文案，並本地化到我現有的所有中繼資料語言# 複核後先 dry-run，再回寫$asc metadata push --app "APP_ID" --version "1.2.3" --dir "./metadata" --dry-run$asc metadata push --app "APP_ID" --version "1.2.3" --dir "./metadata"asc-ppp-pricing
用於實現按地區購買力調整價格的策略，幫助為不同國家 / 地區設定不同的售價，常用於訂閱與內購的區域化定價方案。
# 先檢視某地區當前價格，再設定單個地區的價格$asc subscriptions pricing summary --subscription-id "SUB_ID" --territory "IND"$asc subscriptions pricing prices set --subscription-id "SUB_ID" --price "2.99" --territory "IND"# 批次調整：用 CSV 匯入（子命令參數請用 --help 檢視）$asc subscriptions pricing prices import --help# 按購買力平價為多個地區調整並校驗對智慧代理說按購買力平價方式為印度、巴西和墨西哥調整我的訂閱價格，並校驗最終結果asc-subscription-localization
一次性為訂閱與內購的展示名稱填充所有語言，補齊缺失的訂閱 / 訂閱組 / 內購本地化內容，覆蓋 API 4.4.1 中版本化的 v2 資源，免去在 App Store Connect 後臺逐語言點選的麻煩。
# 從 JSON 檔案一次性匯入多語言名稱（先 dry-run 再確認）$asc subscriptions versions localizations import --version-id "VERSION_ID" --file "./localizations.json" --dry-run$asc subscriptions versions localizations import --version-id "VERSION_ID" --file "./localizations.json" --confirm# 校驗各語言是否已建立$asc subscriptions versions localizations list --version-id "VERSION_ID" --paginate --output tableasc-revenuecat-catalog-sync
對賬 App Store Connect 的訂閱與內購同 RevenueCat 中的產品（Products）、權益（Entitlements）、Offering 與 Package，支援在建立對應前自動建立缺失的 ASC 訂閱 / 內購，採用「先審計、後確認執行」的工作流。
# 讀取 ASC 當前目錄（RevenueCat 一側透過 RevenueCat MCP 讀取）$asc subscriptions groups list --app "APP_ID" --paginate --output json$asc iap list --app "APP_ID" --paginate --output json# 審計差異，確認後再建立對應對智慧代理說審計我的 App Store Connect 訂閱與內購同 RevenueCat 的差異，我確認後再建立缺失的對應asc-workflow
幫助團隊從基於「lane」的自動化遷移到倉庫本地的工作流定義，支援多步驟編排、面向 CI / 智慧代理的機器可讀 JSON 輸出、生命週期鉤子（before_all / after_all / error）、條件判斷（if）與可複用的私有子工作流，並在執行前透過 asc workflow validate 做環檢測與引用校驗。
# 校驗工作流定義，再以 dry-run 方式預演一次測試發佈$asc workflow validate --output json$asc workflow run --dry-run testflight_beta VERSION:1.2.3# 列出可用工作流；失敗後用執行 ID 斷點續跑$asc workflow list$asc workflow run release --resume "RUN_ID"asc-apple-ads
覆蓋 Apple Ads 獨立 OAuth 驗證與廣告帳號發現、基於 Platform API v1 的廣告系列與定向管理、報表與素材操作、有防護的變更操作（guarded mutations）、原始 API 呼叫，以及從廢棄的 v5 自動化遷移到 Platform API v1 的路徑。
# 登入 Apple Ads、發現帳號並查詢廣告系列$asc ads auth login --name Marketing --client-id SEARCHADS_CLIENT_ID --team-id SEARCHADS_TEAM_ID --key-id KEY_ID --private-key ./ads-key.pem --ad-account 987654$asc ads campaigns find --ad-account 987654 --file query.json --output jsonasc-analytics-reports
幫助查詢已存在的分析報告請求，按處理日期或粒度篩選報告實例，並下載每一個報告分段，同時依據 Apple 提供的檔案大小與 MD5 中繼資料逐一校驗完整性。
# 先確認命令契約，再交給智慧代理執行「查詢請求 → 選擇實例 → 下載分段 → 校驗」$asc analytics view --help# 查詢已有報告請求，並列出某個請求下的報告實例$asc analytics requests --app "APP_ID" --paginate --output json$asc analytics view --request-id "REQUEST_ID" --paginate --output json# 按處理日期與粒度篩選，並下載單個分段（需 asc 3.5.0+）$asc analytics view --request-id "REQUEST_ID" --processing-date "2026-01-15" --granularity DAILY --paginate --include-segments --output json$asc analytics download --request-id "REQUEST_ID" --instance-id "INSTANCE_ID" --segment-id "SEGMENT_ID" --output "./segment.txt.gz"# 讓智慧代理做完整採集與大小 / MD5 校驗對智慧代理說採集我最新的周度分析報告，私有下載每個分段檔案，並在分析前逐一校驗完整性asc-wall-submit
使用內建的 CLI 提交流程，把應用加入 App-Store-Connect-CLI 的 Wall of Apps 展示牆，或更新已有條目；需在 App-Store-Connect-CLI 倉庫根目錄下執行，命令會使用已登入的 gh 工作階段 fork 倉庫併發起 PR，自動從應用 ID 解析公開的名稱、連結與圖示。
# 預覽 fork / 分支 / PR 計畫，再正式提交$asc apps wall submit --app 1234567890 --dry-run$asc apps wall submit --app 1234567890 --confirm# 非 App Store 條目（如 TestFlight 公測連結）$asc apps wall submit --link "https://testflight.apple.com/join/ABCDEFG" --name "My Beta App" --confirm