{"owner":"rorkai","repo":"App-Store-Connect-CLI","hasSkills":true,"totalSkillsCount":18,"totalTokensCount":11658,"categories":["anthropic-skill","root-instruction","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/audit-asc-pr/SKILL.md",".agents/skills/audit-asc-pr/agents/openai.yaml",".agents/skills/develop-asc-change/SKILL.md",".agents/skills/develop-asc-change/agents/openai.yaml",".agents/skills/develop-asc-change/references/test-matrix.md",".agents/skills/release-asc-cli/SKILL.md",".agents/skills/release-asc-cli/agents/openai.yaml",".agents/skills/release-asc-cli/references/release-announcement.md",".agents/skills/review-wall-of-apps-prs/SKILL.md",".agents/skills/review-wall-of-apps-prs/agents/openai.yaml",".agents/skills/sync-asc-skills/SKILL.md",".agents/skills/sync-asc-skills/agents/openai.yaml",".agents/skills/triage-asc-issue/SKILL.md",".agents/skills/triage-asc-issue/agents/openai.yaml",".agents/skills/watch-asc-pr/SKILL.md",".agents/skills/watch-asc-pr/agents/openai.yaml","AGENTS.md","CLAUDE.md"],"skills":{".agents/skills/audit-asc-pr/SKILL.md":"---\nname: audit-asc-pr\ndescription: Audit App-Store-Connect-CLI pull requests end to end and fix concrete defects when authorized. Use for PR review, value and blast-radius assessment, issue verification, or requested fixes before merge.\n---\n\n# Audit an ASC CLI pull request\n\nAudit the entire PR under the authority and review rules in `AGENTS.md`.\n\n## Establish the contract\n\n1. Read `AGENTS.md` and resolve the repository, PR number, base branch, head branch, and exact head SHA.\n2. Read the PR body, every commit, linked issues, current checks, reviews, and comments.\n3. Fetch thread-aware review state with GitHub GraphQL. Do not treat a flat comment list as proof that all review threads are resolved.\n4. State the behavior the PR claims to change and the evidence needed to prove it.\n\n## Isolate and inspect\n\n1. Use a dedicated worktree and local branch for the PR. Preserve the user's main checkout and unrelated worktrees.\n2. Inspect the full merge-base diff and all PR commits, not only the latest commit.\n3. Compare the implementation with the linked issue and current product behavior. Check architecture fit, compatibility, error paths, permissions, destructive operations, output contracts, and missing cleanup.\n4. Verify claims from bots or reviewers against code, schemas, and tests before editing.\n5. Flag added tests that do not meet the test rules in `AGENTS.md`, naming the rule each one breaks.\n6. Identify the blast radius: commands, shared helpers, API resources, output formats, auth modes, and release surfaces affected.\n\n## Verify behavior\n\n1. Run the relevant current `--help` paths before judging command shape.\n2. Build a binary when CLI behavior, flags, output, or exit codes changed. Exercise realistic invocations against the built binary.\n3. For API-facing changes, verify the exact endpoint and method in `docs/openapi/latest.json`, including create-versus-update attributes and endpoint-specific query parameters.\n4. Run focused tests first, then checks required by repository policy or proportional to the diff. Pending or unrelated advisory CI does not block the audit once required checks pass; report relevant advisory failures.\n5. Prefer read-only live App Store Connect verification. If live mutations and their cleanup are authorized, use the disposable app `6759231657` and record anything that could not be removed. Never mutate another app without explicit approval.\n6. Preserve uncertainty when live state cannot reproduce an edge case; use deterministic fixtures or tests instead of claiming success.\n\n## Fix forward\n\nFor authorized fixes:\n\n1. Reproduce each defect before changing code.\n2. Add or adjust a failing regression test, confirm the failure, implement the smallest coherent fix, and rerun the focused test.\n3. Add fixes as logical commits traceable to findings or review threads.\n4. Push to the PR head when permitted. If the contributor branch cannot accept maintainer pushes, report the exact limitation and prepare a separate fix PR only when authorized.\n5. When review communication is authorized, reply to and resolve only threads fully addressed by the pushed change.\n6. Re-fetch the head SHA, checks, reviews, and GraphQL threads after every push.\n\nDo not post a generic top-level audit summary unless the user asks. Put actionable findings in review threads when review communication is authorized.\n\n## Apply the merge gate\n\nDo not call the PR ready until all of the following are true:\n\n- The latest head was audited against current `main` under the branch-update rules in `AGENTS.md`.\n- The final committed head passed the full-branch local review loop required by `AGENTS.md` against the current authoritative base, with no subsequent diff change.\n- Relevant focused and GitHub-required checks pass. Non-required checks may still be pending.\n- No actionable unresolved review thread remains.\n- Required reviews are satisfied.\n- GitHub reports the PR mergeable without conflicts. Interpret `BLOCKED` or `UNSTABLE` through the required-check, required-review, and thread gates above; do not require a `CLEAN` merge state when only advisory jobs remain.\n- Live or deterministic verification supports the claimed behavior.\n\nFor requested follow-up monitoring, use `$watch-asc-pr`. Approve and merge only under the authority, history, and exact-head rules in `AGENTS.md`.\n\n## Hand off\n\nReport findings, evidence, remaining gates, and the merge recommendation. Include any fixes, pushes, live mutations, and cleanup.\n",".agents/skills/audit-asc-pr/agents/openai.yaml":"interface:\n  display_name: \"Audit ASC Pull Request\"\n  short_description: \"Review ASC CLI PRs and identify concrete defects\"\n  default_prompt: \"Use $audit-asc-pr to audit this ASC CLI pull request end to end.\"\n",".agents/skills/develop-asc-change/SKILL.md":"---\nname: develop-asc-change\ndescription: Design, implement, and verify behavior changes in App-Store-Connect-CLI. Use when adding or changing a command, flag, API endpoint, output format, exit code, shared CLI behavior, or when fixing or refactoring behavior that requires code and tests.\n---\n\n# Develop an ASC CLI change\n\nFollow `AGENTS.md` for authority, CLI contracts, implementation invariants, validation, and review gates.\n\n## Write the design note\n\nFor a small fix, record the reproduced failure, intended behavior, and focused check. For new public behavior or compatibility decisions, also record:\n\n1. Placement in the existing command taxonomy and registry.\n2. Current `--help` behavior and expected invocation shape.\n3. Exact OpenAPI endpoint, method, request schema, query parameters, and response shape when API-facing.\n4. Flags, output formats, stdout/stderr behavior, and exit codes.\n5. Compatibility, lifecycle, migration, and deprecation impact.\n6. RED-GREEN tests, black-box checks, live verification, edge cases, and failure modes.\n7. Credible alternatives when a material design trade-off exists.\n\n## Establish RED\n\n- For a bug, reproduce it first and add the smallest regression test that fails for the expected reason.\n- For a feature, start with CLI-level coverage of the changed observable contract; add unit or HTTP tests for distinct behavior that those tests do not cover.\n- For a behavior-changing refactor, use existing characterization coverage where sufficient and add coverage for missing behavior before moving code.\n- Run the focused test and record the expected failure before implementation.\n\nRead [references/test-matrix.md](references/test-matrix.md) for applicable CLI, output, artifact, and auth cases. Reuse sufficient existing coverage; do not duplicate shared parser or renderer tests for every command. Every new test must meet the test rules in `AGENTS.md`.\n\n## Validate API support\n\n1. Search `docs/openapi/paths.txt`, then inspect the exact operation in `docs/openapi/latest.json`.\n2. Apply the endpoint-specific schema checks in `AGENTS.md`.\n3. If the API cannot support the behavior, implement explicit client-side behavior or document the limitation; do not ship a misleading flag.\n\n## Implement narrowly\n\nApply `AGENTS.md`'s implementation invariants. Return usage errors with exit code `2`.\n\n## Reach GREEN and verify\n\n1. Rerun the focused failing test after each small fix.\n2. Run adjacent package and command tests.\n3. Build a binary at a worktree-specific path and verify realistic invocations, output streams, and exit codes. Do not share a fixed `/tmp/asc` path with concurrent tasks.\n4. Run a minimal live smoke test when behavior depends on App Store Connect quirks. Prefer read-only calls; live mutations and cleanup require authority under `AGENTS.md`.\n5. Apply `AGENTS.md`'s validation gate, including command-doc generation when help changes. Public CLI behavior, shared code, release surfaces, and meaningful defect or security fixes require the full gate.\n\nBefore handoff, compare the exact branch head with current `main` read-only. Follow the branch-update rules in `AGENTS.md`; a newer base alone does not justify changing the branch.\n\n## Hand off\n\nUse `AGENTS.md`'s handoff contract; include invocation and compatibility details for public-contract changes.\n",".agents/skills/develop-asc-change/agents/openai.yaml":"interface:\n  display_name: \"Develop ASC Change\"\n  short_description: \"Design, implement, and verify ASC CLI changes\"\n  default_prompt: \"Use $develop-asc-change to implement this ASC CLI behavior change completely.\"\n",".agents/skills/develop-asc-change/references/test-matrix.md":"# ASC CLI behavior test matrix\n\nApply the cases relevant to the changed behavior, under the test rules in `AGENTS.md`. Use existing coverage when it proves the contract. Add tests only for distinct observable behavior or demonstrated regressions; do not repeat shared parser and renderer coverage for each command.\n\n## Flags and parsing\n\n- Cover the valid path and one invalid value (stderr and exit code `2`) of a new or changed flag, unless an existing test already does. Add them as rows in an existing table when one exists.\n- When parsing or dispatch changes, cover affected flag ordering and values that look like subcommand names.\n- Assert required-flag errors on stderr; do not test only for `flag.ErrHelp`.\n- Never accept and silently ignore an unsupported flag or value.\n\n## Output and exit behavior\n\n- Parse JSON or XML and assert fields instead of relying only on substring matching.\n- Assert representative table or Markdown structure and headers.\n- Verify stdout, stderr, and exit code with a built binary for changed CLI behavior.\n- Test successful artifact/report writes and write failures.\n- Prevent duplicate usage or duplicate error output.\n\n## HTTP and API behavior\n\n- Use `httptest` to assert method, path, query, headers, and request body.\n- Cover a realistic non-empty response per response family. Test validation and API errors only where the endpoint handles them differently from the shared client.\n- Keep representative response-decoding assertions when consolidating table-driven tests.\n- Test pagination and empty responses where applicable.\n\n## Auth and process isolation\n\n- Run repository tests with `ASC_BYPASS_KEYCHAIN=1`.\n- Use `t.Setenv` and a temporary `ASC_CONFIG_PATH` for auth-sensitive tests.\n- Set or clear `ASC_PROFILE`, `ASC_KEY_ID`, `ASC_ISSUER_ID`, `ASC_PRIVATE_KEY_PATH`, `ASC_PRIVATE_KEY`, `ASC_PRIVATE_KEY_B64`, and `ASC_STRICT_AUTH` locally when relevant.\n- Restore exact process state when a test cannot use `t.Setenv`.\n- Allow `t.Skip` only for a specific documented and reproducible condition; never use a broad error-string skip.\n\n## Live verification\n\n- Prefer read-only calls first.\n- For authorized mutations and cleanup, use a disposable resource, record its ID, and delete or cancel it afterward.\n- Assert the externally visible result, not only a successful HTTP status.\n- Report any state that could not be cleaned up.\n",".agents/skills/release-asc-cli/SKILL.md":"---\nname: release-asc-cli\ndescription: Publish and verify a new release of the App-Store-Connect-CLI repository. Use only when the user explicitly asks to release, tag, or publish a specific ASC CLI version, including the full GitHub release, artifact, Homebrew, WinGet, cleanup, and release-announcement workflow.\n---\n\n# Release the ASC CLI\n\n## Prove the release target\n\n1. Resolve the requested plain semantic version without a `v` prefix.\n2. Fetch `origin` and inspect the requested tag locally and remotely, any release, and its workflow runs before acting. For a new release, require the tag to be absent and inspect the release-worthy delta since the previous tag. When resuming, verify that the existing tag points to the previously approved release commit and resume only unfinished work; stop on a target mismatch.\n3. Query open PRs and confirm the intended changes are already merged.\n4. For a new release, create a clean detached worktree from the exact current `origin/main` commit. When resuming, use the tag's previously approved, verified release commit. Do not release from a dirty user checkout or an unmerged branch.\n5. Inspect `.github/workflows/release.yml` and current repository guidance instead of assuming an older release procedure still applies.\n\n## Run the release gate\n\nFor a new release, run and record the following checks. On resume, reuse completed checks only while their inputs remain valid under `AGENTS.md`; verify consumer-visible state freshly.\n\n```bash\nmake format\nmake check-docs\nmake check-wall-of-apps\nmake lint\nASC_BYPASS_KEYCHAIN=1 make test\nmake build\n./asc version\n```\n\nIf formatting changes files, inspect the diff and stop the release gate. Prepare necessary corrections on a branch only when authorized; they must pass repository review and validation and merge through the normal PR process before restarting from the updated `origin/main`. Never tag a correction committed only in the detached release worktree. Stop on unexplained failures; do not tag around a broken gate.\n\n## Publish\n\n1. For a new release, refresh `origin/main` and reconfirm the worktree HEAD equals the intended current `origin/main` commit. If `origin/main` advanced, inspect the delta and restart target selection and the release gate in a clean detached worktree at the newly selected commit before tagging. Checks run in the old worktree do not validate the new commit.\n2. Create an annotated tag using the exact requested version and push that tag explicitly. On resume, reuse the verified existing tag: skip the push if the remote tag already matches; if only the local tag exists, push it only within the established release authority. Never replace a mismatched remote tag.\n3. Locate the tag-triggered GitHub Actions run and watch it through completion.\n4. Do not retry by silently moving or recreating a published tag. Diagnose failures and preserve the immutable release history.\n\n## Verify consumer-visible state\n\nVerify:\n\n- The GitHub release is published, not draft or prerelease unless requested.\n- Expected macOS, Linux, Windows, and checksum assets exist.\n- A downloaded macOS binary reports the requested version and passes `codesign --verify`.\n- Downloaded artifact hashes match the published checksum file.\n- The Homebrew formula points to the new version and hashes.\n- The expected WinGet submission or PR exists and references the new version.\n- Any notarization step required by the current workflow succeeded.\n\nIf the `winget` job failed, inspect its rate-limit preflight, retry history, and current submission state first. For a transient failure, prefer one rerun of the failed job before manual repair; dispatch the full workflow only after confirming it will safely reuse the existing release. Wait for the logged reset time only when the primary quota bucket is zero; back off a few minutes for secondary throttles, 5xx responses, or transport failures. After a failed retry or a non-transient error, report the exact blocker instead of looping. See `docs/WINGET.md`.\n\n## Update the website changelog\n\nAfter every published release, prepare the changelog update for the root `CHANGELOG.md` in [rorkai/asc-website](https://github.com/rorkai/asc-website). It is the single source for [asccli.sh/changelog](https://asccli.sh/changelog); keep all release history in that file, without separate archives or a second CLI-repository changelog. Apply it to the website checkout when website edits are authorized by the request or session. Otherwise draft the entry text in the release handoff and report the website update as pending; do not modify the website checkout.\n\n1. Build the release inventory from the previous published tag through the released tag, using GitHub release notes, merged PRs, and tagged source. Include only changes shipped in that release. Verify command names, flags, and migration replacements against the released binary's help or tagged source, not a newer checkout.\n2. With website-edit authority, locate the website checkout by its remote and follow its `AGENTS.md`. Work from current website `origin/main` in an isolated worktree when needed. Inspect an existing entry or pending changelog PR before resuming so the same release is not added twice.\n3. Add the version under its UTC publication month, newest first, using the GitHub release publication date. Preserve older entries and update the month navigation when a new month begins.\n4. Write the entry using the rules and examples below. Keep one release link and one previous-tag comparison link at the end, with migration-guide links where relevant.\n5. Run the website's `pnpm run lint` and `pnpm build`, plus `git diff --check`. Verify the new entry renders, month links work, prior releases remain, and no inline PR references were introduced. Require session authority explicitly covering each website write: PR creation, merge, and deployment. A CLI release request alone does not grant those permissions. If a later website write is not authorized, retain the authorized edits and report that pending step separately from the binary release.\n\n### Changelog writing rules\n\n- Use short, flat bullets under `New features`, `Improvements and fixes`, and `Breaking changes` as applicable; omit empty sections. Split unrelated changes into separate bullets and use domain subheadings for large releases.\n- Describe the concrete behavior and its user impact, usually in one or two sentences. Keep important features, fixes, limitations, confirmation requirements, output or exit-code changes, and actionable migration replacements.\n- Omit PR numbers, inline PR links, commit hashes, introductory paragraphs, and generic claims such as “improved reliability.” PRs are evidence for writing the notes, not visible labels in the notes.\n- Cover significant shipped changes individually. Group routine dependency, CI, and test updates where appropriate; the release and comparison links retain the complete source history.\n- Omit Wall of Apps membership churn, including app additions, removals, renames, icon changes, and routine metadata refreshes. Include only significant user-facing changes to the Wall of Apps feature or contribution workflow.\n- Use backticks for commands, flags, environment variables, and JSON. Do not invent detail to expand a short entry or remove compatibility details merely to shorten a bullet.\n\nExample entry from the published 5.1.0 release (illustrative excerpt, not its complete notes):\n\n```markdown\n### 5.1.0 (2026-09-08)\n\n#### New features\n\n- `asc web api-keys list` accepts `--session-from-env` for CI reads.\n- `--session-from-env` reads `ASC_WEB_SESSION` in memory without changing the session cache or keychain.\n\n#### Improvements and fixes\n\n- Review-draft creation stops before writing when a successful preflight response omits `data`.\n\n[Release](https://github.com/rorkai/App-Store-Connect-CLI/releases/tag/5.1.0) · [Compare changes](https://github.com/rorkai/App-Store-Connect-CLI/compare/5.0.0...5.1.0)\n```\n\nMigration wording should name the replacement, for example: “App-scoped `--build-number` queries require `--platform` instead of assuming `IOS`.” Keep this behavior in its 5.0.0 entry; do not present historical examples as new changes in the next release.\n\n## Draft the announcement\n\nRead [references/release-announcement.md](references/release-announcement.md) after the release is visibly published and the website changelog entry exists. Render the release film from the `asc-motion` template, then prepare the announcement thread. Create an external Typefully draft only when the request or established context authorizes that write; otherwise return the copy locally. Never schedule or publish the post unless the user explicitly asks.\n\n## Clean up and hand off\n\nRemove only a clean temporary release worktree created by this run as part of its authorized cleanup; preserve unexpected changes. Report the released commit and tag, release URL, artifact verification, Homebrew and WinGet state, remaining blockers, website changelog state (edited, PR opened, merged, or live), and announcement status separately. An optional external draft does not prevent reporting a verified binary release.\n\n## Automation boundary\n\nDo not schedule unattended releases. After an explicitly initiated tag push, a thread heartbeat may watch the release run and finish authorized downstream verification. Save the version, immutable commit and tag, run IDs, completed checks, authority, next step, and retry history; create or reuse one heartbeat and end the turn. On wake, reconcile current state once, stay quiet and back off when unchanged, and disable the heartbeat on completion or a blocker requiring user action. Never use a heartbeat to recreate or move the tag.\n",".agents/skills/release-asc-cli/agents/openai.yaml":"interface:\n  display_name: \"Release ASC CLI\"\n  short_description: \"Publish and verify an ASC CLI repository release\"\n  default_prompt: \"Use $release-asc-cli to publish and verify the requested ASC CLI release.\"\n",".agents/skills/release-asc-cli/references/release-announcement.md":"# Release announcement\n\nEvery release gets a short film and a thread. The thread reuses the same posts on X, Threads, Bluesky, and Mastodon; LinkedIn stays off.\n\n## Render the release film\n\nThe films live in the private `rudrankriyam/asc-motion` repository (locally `~/Developer/CLIs/asc-motion`, Remotion with bun). If that checkout is unavailable, skip the film, say so in the handoff, and post the thread without it.\n\n1. From the repository root run `./new-release-film.sh NNNN-asc-X-Y X.Y.Z`, where `NNNN` is the next free folder number.\n2. Edit only `NNNN-asc-X-Y/src/content.ts`. Take three or four headline features from the website changelog entry for the version, each with one exact command from the matching guide. Never invent a flag; check every command against `asc <command> --help`. Put the remaining notable changes in the `FIXES` list, one line each under 60 characters.\n3. Inside the folder run `bun install && bun run render`. The music bed is synthesised on every render; nothing licensed is involved.\n4. Render one still per beat with `bunx remotion still AscRelease --frame N out/<beat>.png` and look at each one. Captions must stay clear of the `>_` mark and commands must finish typing before the beat ends; shorten the caption or command if not.\n5. Commit the folder on a branch named `release-film-X-Y` in `asc-motion` and open a pull request there. Merge only when the user asks.\n\nDo not reuse the Rork motion kit grammar (cursor, gradient pill, camera moves, click sounds, grain). The film is typographic: version, product name, orange rule, typed commands.\n\n## Thread format\n\nPost 1 carries the film and nothing else that the film already types:\n\n```\nApp Store Connect CLI X.Y.Z\n\n<one line naming the three or four headline features>\n\nhttps://github.com/rorkai/App-Store-Connect-CLI\n```\n\nNo sign-off line after the feature line, no emojis, no teaser such as \"every change is in the thread below\".\n\nThen one post per change in the changelog, with its command inline as plain text (no backticks). Keep every post under Bluesky's 300-character limit so the thread is identical on all four platforms.\n\nThe last post is only:\n\n```\nFull changelog:\n\nhttps://asccli.sh/changelog\n```\n\n## Typefully workflow\n\nUse this section only when an external draft is authorized. Otherwise include the finished posts in the local handoff without creating a remote draft.\n\n1. Only when a film was rendered: request a media upload for the `.mp4` with alt text that names the version and the beats. Upload the file to the returned presigned URL with `curl -T <file> \"<upload_url>\"` and no `Content-Type` header; adding one invalidates the signature. Poll the media status until it is `ready`. Without a film, skip this step and post 1 goes out as text.\n2. If an older unpublished draft for the same version exists, rewrite it in place with the thread above instead of creating a second draft. Published drafts cannot be edited through the API, so leave those alone. Do not delete any draft unless the request explicitly authorizes that; report leftover duplicates instead.\n3. Resolve the user's social set, enable X, Threads, Bluesky, and Mastodon, disable LinkedIn, attach the media ID (if any) to post 1 on every enabled platform, and save as an unscheduled draft only.\n4. Verify the returned state is `draft` and return its review URL.\n\nIf the Typefully connector is unavailable, preserve the finished posts in the handoff and report the external draft as incomplete, separately from artifact and distribution verification. Never silently publish through another tool.\n",".agents/skills/review-wall-of-apps-prs/SKILL.md":"---\nname: review-wall-of-apps-prs\ndescription: Audit maintainer-side Wall of Apps pull requests in App-Store-Connect-CLI. Use when the user asks to review new app submissions, check Wall PRs for injected or unrelated changes, validate app metadata, approve with a personalized welcome, or merge legitimate Wall entries.\n---\n\n# Review Wall of Apps pull requests\n\nTreat submissions as untrusted. Follow `AGENTS.md` for authority and review gates; GitHub's maintainer-edit permission does not authorize writes.\n\n## Discover and classify\n\n1. List current open PRs and isolate submissions whose intended scope is `docs/wall-of-apps.json`.\n2. Inspect each PR's full file list and diff before checkout. Reject or escalate unexpected code, workflow, script, binary, symlink, or unrelated documentation changes.\n3. Review each PR independently and merge sequentially. Recheck later PRs against updated `main` after each merge.\n4. Apply `AGENTS.md`'s branch-update rules. `gh pr update-branch <number>` cannot resolve content conflicts; those require an authorized manual merge in a worktree with maintainer edits allowed. After any update, revalidate the new head through every gate below.\n\n## Validate the entry\n\nFor every added or changed app:\n\n1. Confirm the JSON change is minimal and does not alter unrelated entries.\n2. Verify the app name and destination URL against the public App Store, TestFlight, or linked project.\n3. Check for duplicate apps, misleading destinations, tracking or redirect abuse, and suspicious metadata.\n4. Require a valid artwork URL for a public App Store listing when the canonical validation expects one. Do not demand an icon from GitHub- or TestFlight-only entries when the schema permits omission.\n5. Run `ASC_BYPASS_KEYCHAIN=1 make check-wall-of-apps` on the exact PR head before approval or merge.\n6. Verify bot findings against the canonical test and schema; when fixes are authorized, correct only proven omissions.\n\nUse an isolated checkout when needed to validate the exact head or apply authorized fixes, preserving unrelated user work. Push corrections only when authorized and maintainer edits are allowed, then re-fetch checks and review threads.\n\n## Approve and merge\n\nApproval and merge require explicit user intent. That intent may come from the\ncurrent request, preserved session context, or a persisted automation prompt that clearly grants\napprove-and-merge authority. Immediately before approval, or before a merge\nthat does not require a new approval, confirm:\n\n- The latest head contains only the legitimate Wall change.\n- The final full-branch local review required by `AGENTS.md` is clear for the current head and authoritative base.\n- `ASC_BYPASS_KEYCHAIN=1 make check-wall-of-apps` and required GitHub checks pass.\n- No actionable unresolved review thread remains.\n- The PR is mergeable against current `main`.\n\nAn authorized approval may itself satisfy a required-review rule. After\nsubmitting any approval and immediately before merging, re-fetch the exact head,\nrequired reviews, review threads, required checks, and mergeability. Require all\nrequired reviews to be satisfied at that point.\n\nDo not wait for advisory or otherwise non-required CI jobs after these gates pass. A pending non-required job does not make the exact-head evidence stale.\n\nWrite the approval body as a short personalized welcome: name the app, state the validation evidence in one clause (App Store, TestFlight, or linked-project verification as applicable, plus the wall checks), and welcome it to the wall with one app-relevant closing line or emoji. Keep it to one or two sentences and make it specific to what the app does; do not paste a generic template verbatim across a batch. When the user explicitly requests a no-comment approval, submit one app-relevant emoji as the entire approval body instead. Do not add separate summary comments beyond the approval; reply to review threads only when an actionable thread needs an explanation. Merge one PR at a time with a regular merge commit that preserves the PR commits, pinning the audited head, for example `gh pr merge <number> --merge --match-head-commit <sha>`. Do not squash unless the user explicitly requests squash for that PR.\n\nAfter each merge, confirm the resulting commit and entry reached `origin/main`. When the user asks whether the app appears on the live Wall, verify the rendered `asccli.sh` page separately; source presence is not deployment proof, and advisory CI is not a reason to delay the live check.\n\n## Automation contract\n\nA standalone automation needs explicit persisted approve-and-merge authority. Apply the gates above to each PR sequentially, including fresh remote checks before acting and after approval. Reuse local validation only while its inputs remain valid under `AGENTS.md`.\n\nIf authority is absent or any gate is uncertain, failing, suspicious, unrelated,\nor stale, remain read-only and report `safe`, `needs-fix`, `suspicious`, or\n`blocked` with evidence. Persisted task authority may cover later passes, but a changed head requires fresh validation; an earlier approval is not proof that the new head passes the gates.\n\n## Hand off\n\nList each app, what it does, files changed, metadata evidence, validation result, review action, merge result, and any suspicious or unresolved state.\n",".agents/skills/review-wall-of-apps-prs/agents/openai.yaml":"interface:\n  display_name: \"Review Wall of Apps PRs\"\n  short_description: \"Validate and safely review Wall of Apps PRs\"\n  default_prompt: \"Use $review-wall-of-apps-prs to audit the open Wall of Apps pull requests.\"\n",".agents/skills/sync-asc-skills/SKILL.md":"---\nname: sync-asc-skills\ndescription: Check rorkai/app-store-connect-cli-skills against the current ASC CLI surface and correct proven drift when authorized. Use for skill-drift questions, post-release syncs, or checks of command, flag, output, auth, and workflow examples.\n---\n\n# Synchronize ASC workflow skills\n\nDrift questions produce a read-only report; update requests authorize proven corrections. Follow `AGENTS.md` for commit, push, and PR-creation authority.\n\n## Establish both sources\n\n1. Resolve the current App-Store-Connect-CLI source commit and latest released version relevant to the request.\n2. Resolve a clean checkout of `rorkai/app-store-connect-cli-skills` and read its repository guidance.\n3. Inventory every skill and identify which commands, flags, environment variables, outputs, or workflows it claims to use.\n4. Run the current CLI's `--help` at each relevant command path. Use `asc search`, `asc schema`, or `asc capabilities` only when their own current help confirms they are appropriate.\n\nFollow `AGENTS.md` for parallel reads and serialized writes. Validate mutation-capable examples with help and schemas first; execution and cleanup require authority, and dry runs must be side-effect-free.\n\n## Prove drift\n\nCheck for:\n\n- Renamed, moved, deprecated, or removed commands.\n- Added, removed, or changed flags and accepted values.\n- Incorrect long-form examples, pagination, output, confirmation, or pretty-print behavior.\n- Auth, environment-variable, timeout, and default-output changes.\n- Workflow ordering changes that affect builds, TestFlight, metadata, review, signing, or release operations.\n- Examples that parse but no longer perform the claimed workflow.\n\nDo not update skills merely because a newer CLI version exists. Record exact help or runtime evidence for every edit.\n\n## Update minimally\n\n1. Change only affected skills and examples; avoid release-number churn and speculative prose.\n2. Keep each `SKILL.md` concise and move lengthy reference material behind progressive disclosure.\n3. Preserve the skills repository's naming, metadata, validation, and style conventions.\n4. Validate every changed command example against current built or released `asc` help and the relevant schema. Exercise runtime behavior when safe and authorized; report any path not executed.\n5. Run the skills repository's validators and the current skill-creator validator when available.\n6. When PR creation is authorized, open a separate draft PR in the skills repository with the CLI commit or release used as evidence and a summary of validation and unexecuted paths.\n\nNever modify the CLI merely to make stale skill documentation pass.\n\n## Automation contract\n\nA weekly or post-release automation may run a read-only drift audit and report proven mismatches. It may open a draft PR only when the automation has explicit write authorization and every change is deterministic; otherwise leave a precise change plan.\n\n## Hand off\n\nReport the CLI version and commit, skills commit, drift found, files changed, commands verified, validators run, PR URL, and any workflow that could not be tested safely.\n",".agents/skills/sync-asc-skills/agents/openai.yaml":"interface:\n  display_name: \"Sync ASC Skills\"\n  short_description: \"Audit ASC workflow skills for CLI surface drift\"\n  default_prompt: \"Use $sync-asc-skills to compare ASC workflow skills with the current CLI and report proven drift.\"\n",".agents/skills/triage-asc-issue/SKILL.md":"---\nname: triage-asc-issue\ndescription: Triage App-Store-Connect-CLI GitHub issues against current code, CLI behavior, and App Store Connect API support. Use when the user asks to audit, reproduce, classify, label, scope, prioritize, or decide whether an ASC CLI issue should be fixed or implemented.\n---\n\n# Triage an ASC CLI issue\n\nProduce a current, evidence-backed verdict and proposed repository labels. Apply label changes only when authorized under `AGENTS.md`; a read-only triage ends with recommendations.\n\n## Read current evidence\n\n1. Fetch the live issue body, comments, labels, linked PRs, and referenced documentation.\n2. Resolve the affected command through current `--help`, source, tests, and recent history. Do not infer support from an old command name.\n3. Reproduce reported behavior with the current built or installed CLI when safe.\n4. For API claims, verify the exact method and endpoint in `docs/openapi/latest.json`; use the `sosumi.ai` documentation mirror for explanatory context.\n5. Check whether the report is already fixed on current `origin/main`, duplicated, unsupported by the public API, or blocked by Apple/platform behavior.\n\nFollow `AGENTS.md` for parallel reads and serialized writes. Live reproductions require authority for mutations and cleanup, even on disposable resources; confirm dry runs are side-effect-free.\n\n## Classify the outcome\n\nChoose one primary verdict:\n\n- Confirmed bug with a reproducible expected-versus-actual mismatch.\n- Valid enhancement with a supported and coherent API or client-side design.\n- Question requiring clarification or support guidance.\n- Already fixed, duplicate, not reproducible, unsupported, or platform-limited.\n\nSeparate urgency from implementation size. Explain user impact, blast radius, workaround, compatibility risk, and the smallest proof needed for completion.\n\n## Recommend or apply labels\n\nRecommend one type, priority, and difficulty from `AGENTS.md`'s buckets using the meanings in `CONTRIBUTING.md`. Apply them only when authorized.\n\nFor authorized label updates, remove conflicting labels and add the selected replacements, then verify the resulting buckets. If evidence is incomplete, mark the recommendation provisional and identify the missing evidence; uncertainty alone does not establish low urgency or easy implementation.\n\n## Define implementation readiness\n\nWhen the issue is actionable, provide:\n\n1. Proposed command and UX shape.\n2. API endpoint or explicit client-side behavior.\n3. Files and shared surfaces likely affected.\n4. RED-GREEN test plan and black-box exit/output cases.\n5. Safe live verification and cleanup plan.\n6. Compatibility or deprecation requirements.\n\nIf implementation is requested, continue with `$develop-asc-change` in an isolated branch or worktree. Report the requested implementation and validation as complete when finished, with PR and merge gates separately. Do not close the issue or claim it resolved until merged and verified; closure still requires authority.\n\n## Automation contract\n\nA recurring issue-triage automation may classify new or incompletely labeled issues and report actionable findings. Apply labels or post comments only within its persisted write authority. It must not implement code or close issues without explicit authorization, and labels must follow evidence.\n",".agents/skills/triage-asc-issue/agents/openai.yaml":"interface:\n  display_name: \"Triage ASC Issue\"\n  short_description: \"Reproduce, classify, and scope an ASC CLI issue\"\n  default_prompt: \"Use $triage-asc-issue to triage this ASC CLI issue against the code and API.\"\n",".agents/skills/watch-asc-pr/SKILL.md":"---\nname: watch-asc-pr\ndescription: Recheck an in-progress App-Store-Connect-CLI pull request for new review feedback, CI results, head changes, and merge readiness. Use when the user says to check for new PR comments, continue polling, fix and loop, babysit a PR, or keep working until the PR is clean.\n---\n\n# Watch an ASC CLI pull request\n\nPreserve the PR context and authority under `AGENTS.md`: status reads once; watch repeats until a terminal state; fix-and-watch also applies authorized fixes. Watching alone grants no edit, commit, push, or reply authority. A one-time check ends after reporting its snapshot; do not start a full readiness audit or heartbeat unless requested or already authorized.\n\n## Recheck current state\n\n1. Resolve the exact PR and compare its current head SHA with the last audited or pushed SHA.\n2. Fetch checks, reviews, top-level comments, and GraphQL review threads in parallel where possible. Separate required checks from advisory jobs.\n3. Separate new actionable feedback from resolved, outdated, informational, duplicate, or bot-noise comments.\n4. If the head changed outside this workflow, inspect the new diff before relying on prior conclusions.\n5. If `main` advanced, refresh the merge-base diff and mergeability; follow the branch-update rules in `AGENTS.md`.\n\n## Address actionable feedback\n\nApply fixes and external writes only when authorized. Otherwise report the verified finding and proposed fix; if it prevents progress, return `blocked` with the exact missing authority.\n\n1. Verify new claims against code, API schemas, and existing behavior.\n2. Reproduce a valid defect and add or update a focused test before changing behavior.\n3. Implement the smallest coherent fix, run the affected checks and required local review, then commit and push when authorized. Complete the final full-branch review loop in `AGENTS.md` before returning `clean`.\n4. When review communication is authorized, reply to and resolve only the threads fully addressed by that push.\n5. Re-fetch the PR after pushing and confirm the live head, checks, and thread state.\n6. Continue from the fresh head while required checks or reviews remain pending; apply new authorized fixes in additive commits.\n\n## Return one state\n\n- `observed`: a one-time check completed; report the requested facts and mark readiness unverified unless separately established. An actionable finding does not make a completed read-only check blocked.\n- `changed`: pushed a fix; include commit and validation.\n- `pending`: required checks, required reviews, or actionable reviews are still running; identify exactly what remains. This is an intermediate state during a user-requested loop, not the final handoff.\n- `clean`: the final full-branch local review in `AGENTS.md` is clear for the current head and base, required checks pass, required reviews are satisfied, the latest head is mergeable, and no actionable unresolved thread remains. Report advisory jobs without treating them as blockers.\n- `blocked`: user input, permissions, an external outage, or an unsafe product decision prevents progress.\n\nFor an authorized merge, reapply `$audit-asc-pr`'s complete gate immediately before merging and follow the history rules in `AGENTS.md`.\n\n## Automation contract\n\nWhen only an expected external state change remains in an authorized watch, save a checkpoint with the objective, PR, head and base SHAs, authority, validation results and inputs, unresolved feedback, last checked time, next step, stop condition, and retry history. Create or reuse one thread heartbeat, verify it, and end the turn. If scheduling is unavailable, report the pending state and checkpoint without implying that monitoring continues.\n\nOn each wake, inspect decisive state once. Reuse still-valid evidence, stay quiet when unchanged, and back off the next check. Resume work on completion, failure, or a stall. After an uncertain write, reconcile remote state before a bounded retry. Disable the heartbeat when the PR is clean, blocked, merged, closed, superseded, or awaiting a material user decision. Advisory jobs may remain pending after the clean gate passes. Do not create an unattended auto-merge loop.\n",".agents/skills/watch-asc-pr/agents/openai.yaml":"interface:\n  display_name: \"Watch ASC Pull Request\"\n  short_description: \"Recheck ASC PR feedback, checks, and readiness\"\n  default_prompt: \"Use $watch-asc-pr to check this ASC CLI pull request for new actionable feedback.\"\n","AGENTS.md":"# AGENTS.md\n\nUnofficial, fast, lightweight, agent-assisted, reviewer-owned CLI for the App Store Connect API. Built in Go with [ffcli](https://github.com/peterbourgon/ff).\n\n## Skills\n\nSkills for using `asc` in app workflows live at https://github.com/rorkai/app-store-connect-cli-skills.\n\nRepository-maintainer workflows live under `.agents/skills/`:\n\n- `$develop-asc-change`: design, implement, and verify commands, flags, endpoints, bug fixes, and behavior-changing refactors.\n- `$audit-asc-pr`: audit a complete PR and, when authorized, fix proven defects.\n- `$watch-asc-pr`: recheck PR comments, checks, head changes, and merge readiness.\n- `$triage-asc-issue`: reproduce, classify, label, and scope an issue.\n- `$review-wall-of-apps-prs`: validate, approve, and merge Wall of Apps submissions safely.\n- `$release-asc-cli`: publish and verify an end-to-end CLI repository release, including the release film and the announcement thread.\n- `$sync-asc-skills`: check the external ASC workflow skills for CLI-surface drift.\n\nUse these skills for their matching workflows instead of expanding this always-loaded file with task-specific procedures.\n\n## Authority and follow-through\n\n- Audits, reviews, research, triage, status checks, and composing draft text are read-only. Creating or updating a remote draft is an external write. Edits, commits, pushes, PR creation, comments, labels, approval, merge, publication, external sends, and deletion require authority from the request or session context. One request may authorize several actions; do not ask again for granted authority. Creating a PR for agreed changes includes the necessary edits, checks, commit, branch push, and PR creation, but not merge.\n- User instructions override skill guidelines within system and developer constraints; skill selection grants no authority. Make routine choices from repository conventions. Ask only about material scope, compatibility, or authority gaps, after preparing authorized work for review; continue independent work while awaiting answers.\n- If a skill causes a pause or scope change, link its `SKILL.md`, quote the instruction, and explain the unresolved decision. Preserve the objective, targets, authority, and verified progress across follow-ups and skill handoffs unless the user changes scope. Switching skills continues the current task; a failing gate blocks dependent actions, not independent authorized work. Inspect state before retrying an interrupted or uncertain write.\n\n## Core CLI contract\n\n- Use long-form flags in docs, tests, and examples (`--app`, `--output`).\n- Output defaults are TTY-aware: `table` in terminals and minified `json` for pipes or CI. Explicit `--output` wins.\n- Do not add interactive prompts. Require `--confirm` for destructive operations.\n- Use `--paginate` when callers request every page.\n- Write data to stdout and errors or diagnostics to stderr.\n- Never accept and silently ignore an unsupported flag or value.\n- JSON output shape is part of the command contract: reads of ASC collections/resources print Apple's envelope unmodified; mutation receipts and computed results use exported camelCase structs in internal/asc/output_*.go with a registered renderer; added fields are additive and removals follow the stability ladder.\n- Website changelog entries must omit Wall of Apps membership churn, including app additions, removals, renames, icon changes, and routine metadata refreshes. Document only significant user-facing changes to the Wall of Apps feature or contribution workflow.\n\n## Discover current behavior\n\nNever rely on memorized command shapes. Before implementing, testing, or documenting a command, inspect its current help:\n\n```bash\nasc --help\nasc builds --help\nasc builds list --help\n```\n\nFor App Store Connect API documentation, prefer the `sosumi.ai` mirror over `developer.apple.com`.\n\nUse the offline OpenAPI snapshot for endpoint and schema truth:\n\n- `docs/openapi/latest.json`: complete snapshot.\n- `docs/openapi/paths.txt`: quick endpoint index.\n- `docs/openapi/README.md`: update procedure.\n\nValidate attributes against the exact create or update request schema. Validate filters and includes against the specific endpoint; related top-level and relationship endpoints often differ.\n\n## Development workflow\n\n- Work on a branch and use an isolated worktree when the main checkout is dirty or other work is in progress.\n- Do not push directly to `main`, bypass hooks, use `--no-verify`, or skip checks to force a result.\n- Use TDD for behavior changes: reproduce or establish RED, implement the smallest coherent change, then reach GREEN.\n- **IMPORTANT:** Before ending every implementation session, run `/review`. In a non-interactive environment, use the stable local Codex CLI command `codex exec --ignore-user-config review --disable apps --disable plugins --disable remote_plugin -c 'model_provider=\"openai\"' -c 'model=\"gpt-5.6-sol\"' -c 'review_model=\"gpt-5.6-sol\"' --uncommitted` as a pre-commit review of working-tree changes.\n- Run reviews from the local worktree with the exact provider, model, config-isolation, and connector-disable flags shown. Immediately before each review, confirm `codex login status` shows ChatGPT authentication and both `CODEX_API_KEY` and `OPENAI_API_KEY` are unset or empty. Stop on API-key authentication or overrides unless explicitly authorized; these can incur separate usage charges.\n- Before calling a PR ready, refresh its authoritative base with `git fetch origin +refs/heads/<base-branch>:refs/remotes/origin/<base-branch>` and run `codex exec --ignore-user-config review --disable apps --disable plugins --disable remote_plugin -c 'model_provider=\"openai\"' -c 'model=\"gpt-5.6-sol\"' -c 'review_model=\"gpt-5.6-sol\"' --base origin/<base-branch>` on the final committed head so the complete branch or PR diff is reviewed against the current base. If the applicable review mechanism is unavailable, report the review gate as blocked and do not call the PR ready. Fix and verify every valid finding, and explicitly verify and disposition any false positive or non-actionable finding. After any change, rerun the applicable review command and repeat until it reports no actionable findings.\n- PR readiness requires a clear final full-branch `/review` and the GitHub gates below. Any subsequent diff change invalidates the review. An investigation may finish with findings or blocked gates without implying PR readiness.\n- Keep one logical change per commit.\n- Preserve additive PR history. Do not squash, rebase, force-push, or otherwise rewrite commits unless the user explicitly requests that strategy.\n- Re-run the focused failing test after each fix before broad validation.\n- Delegate substantive independent reads or focused validation with distinct ownership; verify conclusions centrally. Handle small or dependent work locally. Serialize edits, commits, pushes, review communication, approvals, merges, releases, and cleanup; agents must not concurrently edit shared branches or files.\n- Treat repository-wide commands that compile, lint, or test broad package sets—including `make build`, `make lint`, `make test`, `go test ./...`, race tests over `./...`, and `golangci-lint run ./...`—as host-intensive gates. Give each gate a CPU budget and keep the sum of running gate budgets within the host's logical CPU count, for example three gates with a budget of 3 on a 10-CPU host. When several agents share a host, run gates concurrently only through a slot mechanism the coordinating agent provides, such as a counting lock that reserves a slot atomically and releases it on exit, and wait for a free slot instead of competing for the same CPUs; without one, run one gate at a time. Run a change's final gates together in one slot instead of queuing for each. Never terminate another task's process without explicit authorization.\n- Within a worktree, wait for each focused test to finish before starting a broad gate. Record the checked commit, relevant working-tree state, command, and environment. Reuse passing checks while their inputs remain unchanged, including during status-only follow-ups. Rerun affected checks when source, test inputs, commands, environment, toolchain, or requested verification changes; unrelated temporary files do not invalidate results. Complete every required gate for the final change, and preserve the separate full-branch review requirement after any diff change.\n- Tool flags are limits within a gate's budget, not values to add together. Avoid multiplying Go package and in-binary concurrency: for a budget of `B`, use `GOMAXPROCS=1 go test -p=B -parallel=1 ./...` for package fan-out or `GOMAXPROCS=B go test -p=1 -parallel=B ./...` for one package at a time. Use `golangci-lint run --concurrency=B ./...` for a linter gate.\n\nUser-facing commands and flags are stable until deprecated or removed. Do not delete stable behavior directly. Deprecations require warning text, transition tests, migration guidance, and a release-note entry.\n\n## Implementation invariants\n\n- Put command implementations in `internal/cli/<domain>` and register new top-level commands in `internal/cli/registry/registry.go`.\n- Set `UsageFunc: shared.DefaultUsageFunc` on command groups and subcommands.\n- Use `shared.ContextWithTimeout` or `shared.ContextWithUploadTimeout` for outbound HTTP.\n- Read and write repository-controlled or API-supplied paths through `internal/rootfs`, anchored to the operator-selected root for that command, instead of plain `os` file operations.\n- Validate required flags before side effects and assert stderr messages in tests.\n- Use `internal/cli/cmdtest` for CLI-level coverage and `httptest` for HTTP payload coverage.\n- Remove shared wrappers or helpers made obsolete by a refactor.\n\n## Tests\n\nWrite a test only when it fails if behavior a user or caller depends on breaks, and no existing test already fails for that break. Name that regression before writing the test.\n\nWrite:\n\n- A regression test that fails before every bug fix and passes after it.\n- CLI contract tests: flag validation with its stderr text, exit codes, JSON output fields, and request wiring (method, path, query, body) through `httptest`.\n- Error, partial-failure, and cancellation paths.\n- Security invariants: rootfs anchoring, secret redaction, keychain and `HOME` isolation, credential handling.\n- Concurrency ordering and bounds, run under `-race`.\n\nDo not write tests that:\n\n- Restate the implementation: constants, defaults copied from code, fields the test just set, or a stub returning its input.\n- Exercise the standard library or a dependency, such as a JSON round-trip of a plain struct.\n- Only check for no panic, non-nil, `err == nil`, or `strings.Contains` on one word.\n- Copy another test per endpoint, command, or flag with only names or IDs changed. Add a row to the existing table instead of a sibling test.\n- Drive the same code path with the same or weaker assertions as an existing test.\n- Cover an unexported helper that its callers' tests already cover.\n- Lock incidental text: whitespace, help prose, or the order of unordered output.\n- Target code no production path runs, or always skip.\n\nAlso:\n\n- Do not use `time.Sleep` or real timeouts. Inject intervals, clocks, and retry delays.\n- Keep test code proportionate to the change. A small fix gets one small test.\n- Justify every new test in the PR body by naming the regression it catches.\n- Before removing a test, show which remaining test still fails for the same break.\n\n## Build and validation\n\nEvery manual test command must use `ASC_BYPASS_KEYCHAIN=1` to prevent host keychain prompts and profile bleed-through. The `make test` target enforces the same environment internally.\n\nBefore opening or merging a substantive behavior PR, run `make build`, `make format`, `make check-docs`, `make lint`, and `ASC_BYPASS_KEYCHAIN=1 make test`. If command help changed, run `make generate-command-docs` and commit `docs/COMMANDS.md` before those checks. For a narrowly scoped documentation or skill change, run `make check-docs`, which includes the repository and skill validators, instead of the full Go suite unless the changed surface or repository policy requires more. For a Wall-only PR, run `make check-wall-of-apps` on the exact head.\n\nRequire GitHub-required checks before merge. Report relevant advisory failures, but do not wait for non-required jobs.\n\nDo not weaken CI: formatting, documentation, lint, and tests must run on PR and `main` workflows.\n\n## GitHub and issue guardrails\n\n- Inspect thread-aware GitHub review state before declaring a PR clean; flat comments do not prove every thread is resolved.\n- A PR is ready only when the latest head was reviewed, required checks pass, required reviews are satisfied, actionable threads are resolved, and GitHub reports it mergeable.\n- If `main` advances, recheck the exact PR head, merge-base diff, duplicate or overlap risk, review threads, required checks, and mergeability against current `main` without changing the branch. Do not update, rebase, or merge `main` into a clean PR merely to refresh its base. Update a branch only when GitHub already reports an actual merge conflict, or when an explicitly authorized merge attempt made with every readiness gate passing is refused under strict up-to-date branch protection. Never bypass branch protection with an admin merge.\n- For loop or babysit requests, follow `$watch-asc-pr` until ready or materially blocked, preserving the authorized actions. Use its checkpoint and heartbeat procedure when only waiting remains.\n- When merge is explicitly authorized, preserve the PR commits with a regular merge commit, for example `gh pr merge <number> --merge --match-head-commit <sha>`. Do not squash unless the user explicitly requests squash for that PR.\n- For read-only triage, recommend exactly one type (`bug`, `enhancement`, `question`), one priority (`p0`-`p3`), and one difficulty (`easy`, `medium`, `hard`). When issue creation or label changes are authorized, apply exactly one label from each bucket and remove conflicting labels.\n\n## Authentication and live testing\n\nApp Store Connect API keys come from https://appstoreconnect.apple.com/access/integrations/api and must never be committed.\n\nTests touching auth must isolate relevant environment and config state. For live verification, prefer read-only calls. Live mutations require authorization, including on disposable app `6759231657`; a disposable target does not itself grant permission. Include temporary-resource cleanup in the authorized verification plan and record anything left behind. Never mutate a non-disposable app without explicit approval.\n\n## Handoff contract\n\nReport the outcome, decisive evidence, material unknowns, and next action concisely. Include design or command details only when useful. Distinguish source review, tests, remote checks, merge, release artifacts, and provider state. Report pre-existing failures and unverified acceptance criteria.\n\n## References\n\n- Go standards: `docs/GO_STANDARDS.md`\n- Testing patterns: `docs/TESTING.md`\n- Git workflow and CLI structure: `docs/CONTRIBUTING.md`\n- API quirks: `docs/API_NOTES.md`\n- Development setup, PRs, labels, and Wall submissions: `CONTRIBUTING.md`\n","CLAUDE.md":"@Agents.md\n"},"files":{".agents/skills/audit-asc-pr/SKILL.md":"---\nname: audit-asc-pr\ndescription: Audit App-Store-Connect-CLI pull requests end to end and fix concrete defects when authorized. Use for PR review, value and blast-radius assessment, issue verification, or requested fixes before merge.\n---\n\n# Audit an ASC CLI pull request\n\nAudit the entire PR under the authority and review rules in `AGENTS.md`.\n\n## Establish the contract\n\n1. Read `AGENTS.md` and resolve the repository, PR number, base branch, head branch, and exact head SHA.\n2. Read the PR body, every commit, linked issues, current checks, reviews, and comments.\n3. Fetch thread-aware review state with GitHub GraphQL. Do not treat a flat comment list as proof that all review threads are resolved.\n4. State the behavior the PR claims to change and the evidence needed to prove it.\n\n## Isolate and inspect\n\n1. Use a dedicated worktree and local branch for the PR. Preserve the user's main checkout and unrelated worktrees.\n2. Inspect the full merge-base diff and all PR commits, not only the latest commit.\n3. Compare the implementation with the linked issue and current product behavior. Check architecture fit, compatibility, error paths, permissions, destructive operations, output contracts, and missing cleanup.\n4. Verify claims from bots or reviewers against code, schemas, and tests before editing.\n5. Flag added tests that do not meet the test rules in `AGENTS.md`, naming the rule each one breaks.\n6. Identify the blast radius: commands, shared helpers, API resources, output formats, auth modes, and release surfaces affected.\n\n## Verify behavior\n\n1. Run the relevant current `--help` paths before judging command shape.\n2. Build a binary when CLI behavior, flags, output, or exit codes changed. Exercise realistic invocations against the built binary.\n3. For API-facing changes, verify the exact endpoint and method in `docs/openapi/latest.json`, including create-versus-update attributes and endpoint-specific query parameters.\n4. Run focused tests first, then checks required by repository policy or proportional to the diff. Pending or unrelated advisory CI does not block the audit once required checks pass; report relevant advisory failures.\n5. Prefer read-only live App Store Connect verification. If live mutations and their cleanup are authorized, use the disposable app `6759231657` and record anything that could not be removed. Never mutate another app without explicit approval.\n6. Preserve uncertainty when live state cannot reproduce an edge case; use deterministic fixtures or tests instead of claiming success.\n\n## Fix forward\n\nFor authorized fixes:\n\n1. Reproduce each defect before changing code.\n2. Add or adjust a failing regression test, confirm the failure, implement the smallest coherent fix, and rerun the focused test.\n3. Add fixes as logical commits traceable to findings or review threads.\n4. Push to the PR head when permitted. If the contributor branch cannot accept maintainer pushes, report the exact limitation and prepare a separate fix PR only when authorized.\n5. When review communication is authorized, reply to and resolve only threads fully addressed by the pushed change.\n6. Re-fetch the head SHA, checks, reviews, and GraphQL threads after every push.\n\nDo not post a generic top-level audit summary unless the user asks. Put actionable findings in review threads when review communication is authorized.\n\n## Apply the merge gate\n\nDo not call the PR ready until all of the following are true:\n\n- The latest head was audited against current `main` under the branch-update rules in `AGENTS.md`.\n- The final committed head passed the full-branch local review loop required by `AGENTS.md` against the current authoritative base, with no subsequent diff change.\n- Relevant focused and GitHub-required checks pass. Non-required checks may still be pending.\n- No actionable unresolved review thread remains.\n- Required reviews are satisfied.\n- GitHub reports the PR mergeable without conflicts. Interpret `BLOCKED` or `UNSTABLE` through the required-check, required-review, and thread gates above; do not require a `CLEAN` merge state when only advisory jobs remain.\n- Live or deterministic verification supports the claimed behavior.\n\nFor requested follow-up monitoring, use `$watch-asc-pr`. Approve and merge only under the authority, history, and exact-head rules in `AGENTS.md`.\n\n## Hand off\n\nReport findings, evidence, remaining gates, and the merge recommendation. Include any fixes, pushes, live mutations, and cleanup.\n",".agents/skills/audit-asc-pr/agents/openai.yaml":"interface:\n  display_name: \"Audit ASC Pull Request\"\n  short_description: \"Review ASC CLI PRs and identify concrete defects\"\n  default_prompt: \"Use $audit-asc-pr to audit this ASC CLI pull request end to end.\"\n",".agents/skills/develop-asc-change/SKILL.md":"---\nname: develop-asc-change\ndescription: Design, implement, and verify behavior changes in App-Store-Connect-CLI. Use when adding or changing a command, flag, API endpoint, output format, exit code, shared CLI behavior, or when fixing or refactoring behavior that requires code and tests.\n---\n\n# Develop an ASC CLI change\n\nFollow `AGENTS.md` for authority, CLI contracts, implementation invariants, validation, and review gates.\n\n## Write the design note\n\nFor a small fix, record the reproduced failure, intended behavior, and focused check. For new public behavior or compatibility decisions, also record:\n\n1. Placement in the existing command taxonomy and registry.\n2. Current `--help` behavior and expected invocation shape.\n3. Exact OpenAPI endpoint, method, request schema, query parameters, and response shape when API-facing.\n4. Flags, output formats, stdout/stderr behavior, and exit codes.\n5. Compatibility, lifecycle, migration, and deprecation impact.\n6. RED-GREEN tests, black-box checks, live verification, edge cases, and failure modes.\n7. Credible alternatives when a material design trade-off exists.\n\n## Establish RED\n\n- For a bug, reproduce it first and add the smallest regression test that fails for the expected reason.\n- For a feature, start with CLI-level coverage of the changed observable contract; add unit or HTTP tests for distinct behavior that those tests do not cover.\n- For a behavior-changing refactor, use existing characterization coverage where sufficient and add coverage for missing behavior before moving code.\n- Run the focused test and record the expected failure before implementation.\n\nRead [references/test-matrix.md](references/test-matrix.md) for applicable CLI, output, artifact, and auth cases. Reuse sufficient existing coverage; do not duplicate shared parser or renderer tests for every command. Every new test must meet the test rules in `AGENTS.md`.\n\n## Validate API support\n\n1. Search `docs/openapi/paths.txt`, then inspect the exact operation in `docs/openapi/latest.json`.\n2. Apply the endpoint-specific schema checks in `AGENTS.md`.\n3. If the API cannot support the behavior, implement explicit client-side behavior or document the limitation; do not ship a misleading flag.\n\n## Implement narrowly\n\nApply `AGENTS.md`'s implementation invariants. Return usage errors with exit code `2`.\n\n## Reach GREEN and verify\n\n1. Rerun the focused failing test after each small fix.\n2. Run adjacent package and command tests.\n3. Build a binary at a worktree-specific path and verify realistic invocations, output streams, and exit codes. Do not share a fixed `/tmp/asc` path with concurrent tasks.\n4. Run a minimal live smoke test when behavior depends on App Store Connect quirks. Prefer read-only calls; live mutations and cleanup require authority under `AGENTS.md`.\n5. Apply `AGENTS.md`'s validation gate, including command-doc generation when help changes. Public CLI behavior, shared code, release surfaces, and meaningful defect or security fixes require the full gate.\n\nBefore handoff, compare the exact branch head with current `main` read-only. Follow the branch-update rules in `AGENTS.md`; a newer base alone does not justify changing the branch.\n\n## Hand off\n\nUse `AGENTS.md`'s handoff contract; include invocation and compatibility details for public-contract changes.\n",".agents/skills/develop-asc-change/agents/openai.yaml":"interface:\n  display_name: \"Develop ASC Change\"\n  short_description: \"Design, implement, and verify ASC CLI changes\"\n  default_prompt: \"Use $develop-asc-change to implement this ASC CLI behavior change completely.\"\n",".agents/skills/develop-asc-change/references/test-matrix.md":"# ASC CLI behavior test matrix\n\nApply the cases relevant to the changed behavior, under the test rules in `AGENTS.md`. Use existing coverage when it proves the contract. Add tests only for distinct observable behavior or demonstrated regressions; do not repeat shared parser and renderer coverage for each command.\n\n## Flags and parsing\n\n- Cover the valid path and one invalid value (stderr and exit code `2`) of a new or changed flag, unless an existing test already does. Add them as rows in an existing table when one exists.\n- When parsing or dispatch changes, cover affected flag ordering and values that look like subcommand names.\n- Assert required-flag errors on stderr; do not test only for `flag.ErrHelp`.\n- Never accept and silently ignore an unsupported flag or value.\n\n## Output and exit behavior\n\n- Parse JSON or XML and assert fields instead of relying only on substring matching.\n- Assert representative table or Markdown structure and headers.\n- Verify stdout, stderr, and exit code with a built binary for changed CLI behavior.\n- Test successful artifact/report writes and write failures.\n- Prevent duplicate usage or duplicate error output.\n\n## HTTP and API behavior\n\n- Use `httptest` to assert method, path, query, headers, and request body.\n- Cover a realistic non-empty response per response family. Test validation and API errors only where the endpoint handles them differently from the shared client.\n- Keep representative response-decoding assertions when consolidating table-driven tests.\n- Test pagination and empty responses where applicable.\n\n## Auth and process isolation\n\n- Run repository tests with `ASC_BYPASS_KEYCHAIN=1`.\n- Use `t.Setenv` and a temporary `ASC_CONFIG_PATH` for auth-sensitive tests.\n- Set or clear `ASC_PROFILE`, `ASC_KEY_ID`, `ASC_ISSUER_ID`, `ASC_PRIVATE_KEY_PATH`, `ASC_PRIVATE_KEY`, `ASC_PRIVATE_KEY_B64`, and `ASC_STRICT_AUTH` locally when relevant.\n- Restore exact process state when a test cannot use `t.Setenv`.\n- Allow `t.Skip` only for a specific documented and reproducible condition; never use a broad error-string skip.\n\n## Live verification\n\n- Prefer read-only calls first.\n- For authorized mutations and cleanup, use a disposable resource, record its ID, and delete or cancel it afterward.\n- Assert the externally visible result, not only a successful HTTP status.\n- Report any state that could not be cleaned up.\n",".agents/skills/release-asc-cli/SKILL.md":"---\nname: release-asc-cli\ndescription: Publish and verify a new release of the App-Store-Connect-CLI repository. Use only when the user explicitly asks to release, tag, or publish a specific ASC CLI version, including the full GitHub release, artifact, Homebrew, WinGet, cleanup, and release-announcement workflow.\n---\n\n# Release the ASC CLI\n\n## Prove the release target\n\n1. Resolve the requested plain semantic version without a `v` prefix.\n2. Fetch `origin` and inspect the requested tag locally and remotely, any release, and its workflow runs before acting. For a new release, require the tag to be absent and inspect the release-worthy delta since the previous tag. When resuming, verify that the existing tag points to the previously approved release commit and resume only unfinished work; stop on a target mismatch.\n3. Query open PRs and confirm the intended changes are already merged.\n4. For a new release, create a clean detached worktree from the exact current `origin/main` commit. When resuming, use the tag's previously approved, verified release commit. Do not release from a dirty user checkout or an unmerged branch.\n5. Inspect `.github/workflows/release.yml` and current repository guidance instead of assuming an older release procedure still applies.\n\n## Run the release gate\n\nFor a new release, run and record the following checks. On resume, reuse completed checks only while their inputs remain valid under `AGENTS.md`; verify consumer-visible state freshly.\n\n```bash\nmake format\nmake check-docs\nmake check-wall-of-apps\nmake lint\nASC_BYPASS_KEYCHAIN=1 make test\nmake build\n./asc version\n```\n\nIf formatting changes files, inspect the diff and stop the release gate. Prepare necessary corrections on a branch only when authorized; they must pass repository review and validation and merge through the normal PR process before restarting from the updated `origin/main`. Never tag a correction committed only in the detached release worktree. Stop on unexplained failures; do not tag around a broken gate.\n\n## Publish\n\n1. For a new release, refresh `origin/main` and reconfirm the worktree HEAD equals the intended current `origin/main` commit. If `origin/main` advanced, inspect the delta and restart target selection and the release gate in a clean detached worktree at the newly selected commit before tagging. Checks run in the old worktree do not validate the new commit.\n2. Create an annotated tag using the exact requested version and push that tag explicitly. On resume, reuse the verified existing tag: skip the push if the remote tag already matches; if only the local tag exists, push it only within the established release authority. Never replace a mismatched remote tag.\n3. Locate the tag-triggered GitHub Actions run and watch it through completion.\n4. Do not retry by silently moving or recreating a published tag. Diagnose failures and preserve the immutable release history.\n\n## Verify consumer-visible state\n\nVerify:\n\n- The GitHub release is published, not draft or prerelease unless requested.\n- Expected macOS, Linux, Windows, and checksum assets exist.\n- A downloaded macOS binary reports the requested version and passes `codesign --verify`.\n- Downloaded artifact hashes match the published checksum file.\n- The Homebrew formula points to the new version and hashes.\n- The expected WinGet submission or PR exists and references the new version.\n- Any notarization step required by the current workflow succeeded.\n\nIf the `winget` job failed, inspect its rate-limit preflight, retry history, and current submission state first. For a transient failure, prefer one rerun of the failed job before manual repair; dispatch the full workflow only after confirming it will safely reuse the existing release. Wait for the logged reset time only when the primary quota bucket is zero; back off a few minutes for secondary throttles, 5xx responses, or transport failures. After a failed retry or a non-transient error, report the exact blocker instead of looping. See `docs/WINGET.md`.\n\n## Update the website changelog\n\nAfter every published release, prepare the changelog update for the root `CHANGELOG.md` in [rorkai/asc-website](https://github.com/rorkai/asc-website). It is the single source for [asccli.sh/changelog](https://asccli.sh/changelog); keep all release history in that file, without separate archives or a second CLI-repository changelog. Apply it to the website checkout when website edits are authorized by the request or session. Otherwise draft the entry text in the release handoff and report the website update as pending; do not modify the website checkout.\n\n1. Build the release inventory from the previous published tag through the released tag, using GitHub release notes, merged PRs, and tagged source. Include only changes shipped in that release. Verify command names, flags, and migration replacements against the released binary's help or tagged source, not a newer checkout.\n2. With website-edit authority, locate the website checkout by its remote and follow its `AGENTS.md`. Work from current website `origin/main` in an isolated worktree when needed. Inspect an existing entry or pending changelog PR before resuming so the same release is not added twice.\n3. Add the version under its UTC publication month, newest first, using the GitHub release publication date. Preserve older entries and update the month navigation when a new month begins.\n4. Write the entry using the rules and examples below. Keep one release link and one previous-tag comparison link at the end, with migration-guide links where relevant.\n5. Run the website's `pnpm run lint` and `pnpm build`, plus `git diff --check`. Verify the new entry renders, month links work, prior releases remain, and no inline PR references were introduced. Require session authority explicitly covering each website write: PR creation, merge, and deployment. A CLI release request alone does not grant those permissions. If a later website write is not authorized, retain the authorized edits and report that pending step separately from the binary release.\n\n### Changelog writing rules\n\n- Use short, flat bullets under `New features`, `Improvements and fixes`, and `Breaking changes` as applicable; omit empty sections. Split unrelated changes into separate bullets and use domain subheadings for large releases.\n- Describe the concrete behavior and its user impact, usually in one or two sentences. Keep important features, fixes, limitations, confirmation requirements, output or exit-code changes, and actionable migration replacements.\n- Omit PR numbers, inline PR links, commit hashes, introductory paragraphs, and generic claims such as “improved reliability.” PRs are evidence for writing the notes, not visible labels in the notes.\n- Cover significant shipped changes individually. Group routine dependency, CI, and test updates where appropriate; the release and comparison links retain the complete source history.\n- Omit Wall of Apps membership churn, including app additions, removals, renames, icon changes, and routine metadata refreshes. Include only significant user-facing changes to the Wall of Apps feature or contribution workflow.\n- Use backticks for commands, flags, environment variables, and JSON. Do not invent detail to expand a short entry or remove compatibility details merely to shorten a bullet.\n\nExample entry from the published 5.1.0 release (illustrative excerpt, not its complete notes):\n\n```markdown\n### 5.1.0 (2026-09-08)\n\n#### New features\n\n- `asc web api-keys list` accepts `--session-from-env` for CI reads.\n- `--session-from-env` reads `ASC_WEB_SESSION` in memory without changing the session cache or keychain.\n\n#### Improvements and fixes\n\n- Review-draft creation stops before writing when a successful preflight response omits `data`.\n\n[Release](https://github.com/rorkai/App-Store-Connect-CLI/releases/tag/5.1.0) · [Compare changes](https://github.com/rorkai/App-Store-Connect-CLI/compare/5.0.0...5.1.0)\n```\n\nMigration wording should name the replacement, for example: “App-scoped `--build-number` queries require `--platform` instead of assuming `IOS`.” Keep this behavior in its 5.0.0 entry; do not present historical examples as new changes in the next release.\n\n## Draft the announcement\n\nRead [references/release-announcement.md](references/release-announcement.md) after the release is visibly published and the website changelog entry exists. Render the release film from the `asc-motion` template, then prepare the announcement thread. Create an external Typefully draft only when the request or established context authorizes that write; otherwise return the copy locally. Never schedule or publish the post unless the user explicitly asks.\n\n## Clean up and hand off\n\nRemove only a clean temporary release worktree created by this run as part of its authorized cleanup; preserve unexpected changes. Report the released commit and tag, release URL, artifact verification, Homebrew and WinGet state, remaining blockers, website changelog state (edited, PR opened, merged, or live), and announcement status separately. An optional external draft does not prevent reporting a verified binary release.\n\n## Automation boundary\n\nDo not schedule unattended releases. After an explicitly initiated tag push, a thread heartbeat may watch the release run and finish authorized downstream verification. Save the version, immutable commit and tag, run IDs, completed checks, authority, next step, and retry history; create or reuse one heartbeat and end the turn. On wake, reconcile current state once, stay quiet and back off when unchanged, and disable the heartbeat on completion or a blocker requiring user action. Never use a heartbeat to recreate or move the tag.\n",".agents/skills/release-asc-cli/agents/openai.yaml":"interface:\n  display_name: \"Release ASC CLI\"\n  short_description: \"Publish and verify an ASC CLI repository release\"\n  default_prompt: \"Use $release-asc-cli to publish and verify the requested ASC CLI release.\"\n",".agents/skills/release-asc-cli/references/release-announcement.md":"# Release announcement\n\nEvery release gets a short film and a thread. The thread reuses the same posts on X, Threads, Bluesky, and Mastodon; LinkedIn stays off.\n\n## Render the release film\n\nThe films live in the private `rudrankriyam/asc-motion` repository (locally `~/Developer/CLIs/asc-motion`, Remotion with bun). If that checkout is unavailable, skip the film, say so in the handoff, and post the thread without it.\n\n1. From the repository root run `./new-release-film.sh NNNN-asc-X-Y X.Y.Z`, where `NNNN` is the next free folder number.\n2. Edit only `NNNN-asc-X-Y/src/content.ts`. Take three or four headline features from the website changelog entry for the version, each with one exact command from the matching guide. Never invent a flag; check every command against `asc <command> --help`. Put the remaining notable changes in the `FIXES` list, one line each under 60 characters.\n3. Inside the folder run `bun install && bun run render`. The music bed is synthesised on every render; nothing licensed is involved.\n4. Render one still per beat with `bunx remotion still AscRelease --frame N out/<beat>.png` and look at each one. Captions must stay clear of the `>_` mark and commands must finish typing before the beat ends; shorten the caption or command if not.\n5. Commit the folder on a branch named `release-film-X-Y` in `asc-motion` and open a pull request there. Merge only when the user asks.\n\nDo not reuse the Rork motion kit grammar (cursor, gradient pill, camera moves, click sounds, grain). The film is typographic: version, product name, orange rule, typed commands.\n\n## Thread format\n\nPost 1 carries the film and nothing else that the film already types:\n\n```\nApp Store Connect CLI X.Y.Z\n\n<one line naming the three or four headline features>\n\nhttps://github.com/rorkai/App-Store-Connect-CLI\n```\n\nNo sign-off line after the feature line, no emojis, no teaser such as \"every change is in the thread below\".\n\nThen one post per change in the changelog, with its command inline as plain text (no backticks). Keep every post under Bluesky's 300-character limit so the thread is identical on all four platforms.\n\nThe last post is only:\n\n```\nFull changelog:\n\nhttps://asccli.sh/changelog\n```\n\n## Typefully workflow\n\nUse this section only when an external draft is authorized. Otherwise include the finished posts in the local handoff without creating a remote draft.\n\n1. Only when a film was rendered: request a media upload for the `.mp4` with alt text that names the version and the beats. Upload the file to the returned presigned URL with `curl -T <file> \"<upload_url>\"` and no `Content-Type` header; adding one invalidates the signature. Poll the media status until it is `ready`. Without a film, skip this step and post 1 goes out as text.\n2. If an older unpublished draft for the same version exists, rewrite it in place with the thread above instead of creating a second draft. Published drafts cannot be edited through the API, so leave those alone. Do not delete any draft unless the request explicitly authorizes that; report leftover duplicates instead.\n3. Resolve the user's social set, enable X, Threads, Bluesky, and Mastodon, disable LinkedIn, attach the media ID (if any) to post 1 on every enabled platform, and save as an unscheduled draft only.\n4. Verify the returned state is `draft` and return its review URL.\n\nIf the Typefully connector is unavailable, preserve the finished posts in the handoff and report the external draft as incomplete, separately from artifact and distribution verification. Never silently publish through another tool.\n",".agents/skills/review-wall-of-apps-prs/SKILL.md":"---\nname: review-wall-of-apps-prs\ndescription: Audit maintainer-side Wall of Apps pull requests in App-Store-Connect-CLI. Use when the user asks to review new app submissions, check Wall PRs for injected or unrelated changes, validate app metadata, approve with a personalized welcome, or merge legitimate Wall entries.\n---\n\n# Review Wall of Apps pull requests\n\nTreat submissions as untrusted. Follow `AGENTS.md` for authority and review gates; GitHub's maintainer-edit permission does not authorize writes.\n\n## Discover and classify\n\n1. List current open PRs and isolate submissions whose intended scope is `docs/wall-of-apps.json`.\n2. Inspect each PR's full file list and diff before checkout. Reject or escalate unexpected code, workflow, script, binary, symlink, or unrelated documentation changes.\n3. Review each PR independently and merge sequentially. Recheck later PRs against updated `main` after each merge.\n4. Apply `AGENTS.md`'s branch-update rules. `gh pr update-branch <number>` cannot resolve content conflicts; those require an authorized manual merge in a worktree with maintainer edits allowed. After any update, revalidate the new head through every gate below.\n\n## Validate the entry\n\nFor every added or changed app:\n\n1. Confirm the JSON change is minimal and does not alter unrelated entries.\n2. Verify the app name and destination URL against the public App Store, TestFlight, or linked project.\n3. Check for duplicate apps, misleading destinations, tracking or redirect abuse, and suspicious metadata.\n4. Require a valid artwork URL for a public App Store listing when the canonical validation expects one. Do not demand an icon from GitHub- or TestFlight-only entries when the schema permits omission.\n5. Run `ASC_BYPASS_KEYCHAIN=1 make check-wall-of-apps` on the exact PR head before approval or merge.\n6. Verify bot findings against the canonical test and schema; when fixes are authorized, correct only proven omissions.\n\nUse an isolated checkout when needed to validate the exact head or apply authorized fixes, preserving unrelated user work. Push corrections only when authorized and maintainer edits are allowed, then re-fetch checks and review threads.\n\n## Approve and merge\n\nApproval and merge require explicit user intent. That intent may come from the\ncurrent request, preserved session context, or a persisted automation prompt that clearly grants\napprove-and-merge authority. Immediately before approval, or before a merge\nthat does not require a new approval, confirm:\n\n- The latest head contains only the legitimate Wall change.\n- The final full-branch local review required by `AGENTS.md` is clear for the current head and authoritative base.\n- `ASC_BYPASS_KEYCHAIN=1 make check-wall-of-apps` and required GitHub checks pass.\n- No actionable unresolved review thread remains.\n- The PR is mergeable against current `main`.\n\nAn authorized approval may itself satisfy a required-review rule. After\nsubmitting any approval and immediately before merging, re-fetch the exact head,\nrequired reviews, review threads, required checks, and mergeability. Require all\nrequired reviews to be satisfied at that point.\n\nDo not wait for advisory or otherwise non-required CI jobs after these gates pass. A pending non-required job does not make the exact-head evidence stale.\n\nWrite the approval body as a short personalized welcome: name the app, state the validation evidence in one clause (App Store, TestFlight, or linked-project verification as applicable, plus the wall checks), and welcome it to the wall with one app-relevant closing line or emoji. Keep it to one or two sentences and make it specific to what the app does; do not paste a generic template verbatim across a batch. When the user explicitly requests a no-comment approval, submit one app-relevant emoji as the entire approval body instead. Do not add separate summary comments beyond the approval; reply to review threads only when an actionable thread needs an explanation. Merge one PR at a time with a regular merge commit that preserves the PR commits, pinning the audited head, for example `gh pr merge <number> --merge --match-head-commit <sha>`. Do not squash unless the user explicitly requests squash for that PR.\n\nAfter each merge, confirm the resulting commit and entry reached `origin/main`. When the user asks whether the app appears on the live Wall, verify the rendered `asccli.sh` page separately; source presence is not deployment proof, and advisory CI is not a reason to delay the live check.\n\n## Automation contract\n\nA standalone automation needs explicit persisted approve-and-merge authority. Apply the gates above to each PR sequentially, including fresh remote checks before acting and after approval. Reuse local validation only while its inputs remain valid under `AGENTS.md`.\n\nIf authority is absent or any gate is uncertain, failing, suspicious, unrelated,\nor stale, remain read-only and report `safe`, `needs-fix`, `suspicious`, or\n`blocked` with evidence. Persisted task authority may cover later passes, but a changed head requires fresh validation; an earlier approval is not proof that the new head passes the gates.\n\n## Hand off\n\nList each app, what it does, files changed, metadata evidence, validation result, review action, merge result, and any suspicious or unresolved state.\n",".agents/skills/review-wall-of-apps-prs/agents/openai.yaml":"interface:\n  display_name: \"Review Wall of Apps PRs\"\n  short_description: \"Validate and safely review Wall of Apps PRs\"\n  default_prompt: \"Use $review-wall-of-apps-prs to audit the open Wall of Apps pull requests.\"\n",".agents/skills/sync-asc-skills/SKILL.md":"---\nname: sync-asc-skills\ndescription: Check rorkai/app-store-connect-cli-skills against the current ASC CLI surface and correct proven drift when authorized. Use for skill-drift questions, post-release syncs, or checks of command, flag, output, auth, and workflow examples.\n---\n\n# Synchronize ASC workflow skills\n\nDrift questions produce a read-only report; update requests authorize proven corrections. Follow `AGENTS.md` for commit, push, and PR-creation authority.\n\n## Establish both sources\n\n1. Resolve the current App-Store-Connect-CLI source commit and latest released version relevant to the request.\n2. Resolve a clean checkout of `rorkai/app-store-connect-cli-skills` and read its repository guidance.\n3. Inventory every skill and identify which commands, flags, environment variables, outputs, or workflows it claims to use.\n4. Run the current CLI's `--help` at each relevant command path. Use `asc search`, `asc schema`, or `asc capabilities` only when their own current help confirms they are appropriate.\n\nFollow `AGENTS.md` for parallel reads and serialized writes. Validate mutation-capable examples with help and schemas first; execution and cleanup require authority, and dry runs must be side-effect-free.\n\n## Prove drift\n\nCheck for:\n\n- Renamed, moved, deprecated, or removed commands.\n- Added, removed, or changed flags and accepted values.\n- Incorrect long-form examples, pagination, output, confirmation, or pretty-print behavior.\n- Auth, environment-variable, timeout, and default-output changes.\n- Workflow ordering changes that affect builds, TestFlight, metadata, review, signing, or release operations.\n- Examples that parse but no longer perform the claimed workflow.\n\nDo not update skills merely because a newer CLI version exists. Record exact help or runtime evidence for every edit.\n\n## Update minimally\n\n1. Change only affected skills and examples; avoid release-number churn and speculative prose.\n2. Keep each `SKILL.md` concise and move lengthy reference material behind progressive disclosure.\n3. Preserve the skills repository's naming, metadata, validation, and style conventions.\n4. Validate every changed command example against current built or released `asc` help and the relevant schema. Exercise runtime behavior when safe and authorized; report any path not executed.\n5. Run the skills repository's validators and the current skill-creator validator when available.\n6. When PR creation is authorized, open a separate draft PR in the skills repository with the CLI commit or release used as evidence and a summary of validation and unexecuted paths.\n\nNever modify the CLI merely to make stale skill documentation pass.\n\n## Automation contract\n\nA weekly or post-release automation may run a read-only drift audit and report proven mismatches. It may open a draft PR only when the automation has explicit write authorization and every change is deterministic; otherwise leave a precise change plan.\n\n## Hand off\n\nReport the CLI version and commit, skills commit, drift found, files changed, commands verified, validators run, PR URL, and any workflow that could not be tested safely.\n",".agents/skills/sync-asc-skills/agents/openai.yaml":"interface:\n  display_name: \"Sync ASC Skills\"\n  short_description: \"Audit ASC workflow skills for CLI surface drift\"\n  default_prompt: \"Use $sync-asc-skills to compare ASC workflow skills with the current CLI and report proven drift.\"\n",".agents/skills/triage-asc-issue/SKILL.md":"---\nname: triage-asc-issue\ndescription: Triage App-Store-Connect-CLI GitHub issues against current code, CLI behavior, and App Store Connect API support. Use when the user asks to audit, reproduce, classify, label, scope, prioritize, or decide whether an ASC CLI issue should be fixed or implemented.\n---\n\n# Triage an ASC CLI issue\n\nProduce a current, evidence-backed verdict and proposed repository labels. Apply label changes only when authorized under `AGENTS.md`; a read-only triage ends with recommendations.\n\n## Read current evidence\n\n1. Fetch the live issue body, comments, labels, linked PRs, and referenced documentation.\n2. Resolve the affected command through current `--help`, source, tests, and recent history. Do not infer support from an old command name.\n3. Reproduce reported behavior with the current built or installed CLI when safe.\n4. For API claims, verify the exact method and endpoint in `docs/openapi/latest.json`; use the `sosumi.ai` documentation mirror for explanatory context.\n5. Check whether the report is already fixed on current `origin/main`, duplicated, unsupported by the public API, or blocked by Apple/platform behavior.\n\nFollow `AGENTS.md` for parallel reads and serialized writes. Live reproductions require authority for mutations and cleanup, even on disposable resources; confirm dry runs are side-effect-free.\n\n## Classify the outcome\n\nChoose one primary verdict:\n\n- Confirmed bug with a reproducible expected-versus-actual mismatch.\n- Valid enhancement with a supported and coherent API or client-side design.\n- Question requiring clarification or support guidance.\n- Already fixed, duplicate, not reproducible, unsupported, or platform-limited.\n\nSeparate urgency from implementation size. Explain user impact, blast radius, workaround, compatibility risk, and the smallest proof needed for completion.\n\n## Recommend or apply labels\n\nRecommend one type, priority, and difficulty from `AGENTS.md`'s buckets using the meanings in `CONTRIBUTING.md`. Apply them only when authorized.\n\nFor authorized label updates, remove conflicting labels and add the selected replacements, then verify the resulting buckets. If evidence is incomplete, mark the recommendation provisional and identify the missing evidence; uncertainty alone does not establish low urgency or easy implementation.\n\n## Define implementation readiness\n\nWhen the issue is actionable, provide:\n\n1. Proposed command and UX shape.\n2. API endpoint or explicit client-side behavior.\n3. Files and shared surfaces likely affected.\n4. RED-GREEN test plan and black-box exit/output cases.\n5. Safe live verification and cleanup plan.\n6. Compatibility or deprecation requirements.\n\nIf implementation is requested, continue with `$develop-asc-change` in an isolated branch or worktree. Report the requested implementation and validation as complete when finished, with PR and merge gates separately. Do not close the issue or claim it resolved until merged and verified; closure still requires authority.\n\n## Automation contract\n\nA recurring issue-triage automation may classify new or incompletely labeled issues and report actionable findings. Apply labels or post comments only within its persisted write authority. It must not implement code or close issues without explicit authorization, and labels must follow evidence.\n",".agents/skills/triage-asc-issue/agents/openai.yaml":"interface:\n  display_name: \"Triage ASC Issue\"\n  short_description: \"Reproduce, classify, and scope an ASC CLI issue\"\n  default_prompt: \"Use $triage-asc-issue to triage this ASC CLI issue against the code and API.\"\n",".agents/skills/watch-asc-pr/SKILL.md":"---\nname: watch-asc-pr\ndescription: Recheck an in-progress App-Store-Connect-CLI pull request for new review feedback, CI results, head changes, and merge readiness. Use when the user says to check for new PR comments, continue polling, fix and loop, babysit a PR, or keep working until the PR is clean.\n---\n\n# Watch an ASC CLI pull request\n\nPreserve the PR context and authority under `AGENTS.md`: status reads once; watch repeats until a terminal state; fix-and-watch also applies authorized fixes. Watching alone grants no edit, commit, push, or reply authority. A one-time check ends after reporting its snapshot; do not start a full readiness audit or heartbeat unless requested or already authorized.\n\n## Recheck current state\n\n1. Resolve the exact PR and compare its current head SHA with the last audited or pushed SHA.\n2. Fetch checks, reviews, top-level comments, and GraphQL review threads in parallel where possible. Separate required checks from advisory jobs.\n3. Separate new actionable feedback from resolved, outdated, informational, duplicate, or bot-noise comments.\n4. If the head changed outside this workflow, inspect the new diff before relying on prior conclusions.\n5. If `main` advanced, refresh the merge-base diff and mergeability; follow the branch-update rules in `AGENTS.md`.\n\n## Address actionable feedback\n\nApply fixes and external writes only when authorized. Otherwise report the verified finding and proposed fix; if it prevents progress, return `blocked` with the exact missing authority.\n\n1. Verify new claims against code, API schemas, and existing behavior.\n2. Reproduce a valid defect and add or update a focused test before changing behavior.\n3. Implement the smallest coherent fix, run the affected checks and required local review, then commit and push when authorized. Complete the final full-branch review loop in `AGENTS.md` before returning `clean`.\n4. When review communication is authorized, reply to and resolve only the threads fully addressed by that push.\n5. Re-fetch the PR after pushing and confirm the live head, checks, and thread state.\n6. Continue from the fresh head while required checks or reviews remain pending; apply new authorized fixes in additive commits.\n\n## Return one state\n\n- `observed`: a one-time check completed; report the requested facts and mark readiness unverified unless separately established. An actionable finding does not make a completed read-only check blocked.\n- `changed`: pushed a fix; include commit and validation.\n- `pending`: required checks, required reviews, or actionable reviews are still running; identify exactly what remains. This is an intermediate state during a user-requested loop, not the final handoff.\n- `clean`: the final full-branch local review in `AGENTS.md` is clear for the current head and base, required checks pass, required reviews are satisfied, the latest head is mergeable, and no actionable unresolved thread remains. Report advisory jobs without treating them as blockers.\n- `blocked`: user input, permissions, an external outage, or an unsafe product decision prevents progress.\n\nFor an authorized merge, reapply `$audit-asc-pr`'s complete gate immediately before merging and follow the history rules in `AGENTS.md`.\n\n## Automation contract\n\nWhen only an expected external state change remains in an authorized watch, save a checkpoint with the objective, PR, head and base SHAs, authority, validation results and inputs, unresolved feedback, last checked time, next step, stop condition, and retry history. Create or reuse one thread heartbeat, verify it, and end the turn. If scheduling is unavailable, report the pending state and checkpoint without implying that monitoring continues.\n\nOn each wake, inspect decisive state once. Reuse still-valid evidence, stay quiet when unchanged, and back off the next check. Resume work on completion, failure, or a stall. After an uncertain write, reconcile remote state before a bounded retry. Disable the heartbeat when the PR is clean, blocked, merged, closed, superseded, or awaiting a material user decision. Advisory jobs may remain pending after the clean gate passes. Do not create an unattended auto-merge loop.\n",".agents/skills/watch-asc-pr/agents/openai.yaml":"interface:\n  display_name: \"Watch ASC Pull Request\"\n  short_description: \"Recheck ASC PR feedback, checks, and readiness\"\n  default_prompt: \"Use $watch-asc-pr to check this ASC CLI pull request for new actionable feedback.\"\n","AGENTS.md":"# AGENTS.md\n\nUnofficial, fast, lightweight, agent-assisted, reviewer-owned CLI for the App Store Connect API. Built in Go with [ffcli](https://github.com/peterbourgon/ff).\n\n## Skills\n\nSkills for using `asc` in app workflows live at https://github.com/rorkai/app-store-connect-cli-skills.\n\nRepository-maintainer workflows live under `.agents/skills/`:\n\n- `$develop-asc-change`: design, implement, and verify commands, flags, endpoints, bug fixes, and behavior-changing refactors.\n- `$audit-asc-pr`: audit a complete PR and, when authorized, fix proven defects.\n- `$watch-asc-pr`: recheck PR comments, checks, head changes, and merge readiness.\n- `$triage-asc-issue`: reproduce, classify, label, and scope an issue.\n- `$review-wall-of-apps-prs`: validate, approve, and merge Wall of Apps submissions safely.\n- `$release-asc-cli`: publish and verify an end-to-end CLI repository release, including the release film and the announcement thread.\n- `$sync-asc-skills`: check the external ASC workflow skills for CLI-surface drift.\n\nUse these skills for their matching workflows instead of expanding this always-loaded file with task-specific procedures.\n\n## Authority and follow-through\n\n- Audits, reviews, research, triage, status checks, and composing draft text are read-only. Creating or updating a remote draft is an external write. Edits, commits, pushes, PR creation, comments, labels, approval, merge, publication, external sends, and deletion require authority from the request or session context. One request may authorize several actions; do not ask again for granted authority. Creating a PR for agreed changes includes the necessary edits, checks, commit, branch push, and PR creation, but not merge.\n- User instructions override skill guidelines within system and developer constraints; skill selection grants no authority. Make routine choices from repository conventions. Ask only about material scope, compatibility, or authority gaps, after preparing authorized work for review; continue independent work while awaiting answers.\n- If a skill causes a pause or scope change, link its `SKILL.md`, quote the instruction, and explain the unresolved decision. Preserve the objective, targets, authority, and verified progress across follow-ups and skill handoffs unless the user changes scope. Switching skills continues the current task; a failing gate blocks dependent actions, not independent authorized work. Inspect state before retrying an interrupted or uncertain write.\n\n## Core CLI contract\n\n- Use long-form flags in docs, tests, and examples (`--app`, `--output`).\n- Output defaults are TTY-aware: `table` in terminals and minified `json` for pipes or CI. Explicit `--output` wins.\n- Do not add interactive prompts. Require `--confirm` for destructive operations.\n- Use `--paginate` when callers request every page.\n- Write data to stdout and errors or diagnostics to stderr.\n- Never accept and silently ignore an unsupported flag or value.\n- JSON output shape is part of the command contract: reads of ASC collections/resources print Apple's envelope unmodified; mutation receipts and computed results use exported camelCase structs in internal/asc/output_*.go with a registered renderer; added fields are additive and removals follow the stability ladder.\n- Website changelog entries must omit Wall of Apps membership churn, including app additions, removals, renames, icon changes, and routine metadata refreshes. Document only significant user-facing changes to the Wall of Apps feature or contribution workflow.\n\n## Discover current behavior\n\nNever rely on memorized command shapes. Before implementing, testing, or documenting a command, inspect its current help:\n\n```bash\nasc --help\nasc builds --help\nasc builds list --help\n```\n\nFor App Store Connect API documentation, prefer the `sosumi.ai` mirror over `developer.apple.com`.\n\nUse the offline OpenAPI snapshot for endpoint and schema truth:\n\n- `docs/openapi/latest.json`: complete snapshot.\n- `docs/openapi/paths.txt`: quick endpoint index.\n- `docs/openapi/README.md`: update procedure.\n\nValidate attributes against the exact create or update request schema. Validate filters and includes against the specific endpoint; related top-level and relationship endpoints often differ.\n\n## Development workflow\n\n- Work on a branch and use an isolated worktree when the main checkout is dirty or other work is in progress.\n- Do not push directly to `main`, bypass hooks, use `--no-verify`, or skip checks to force a result.\n- Use TDD for behavior changes: reproduce or establish RED, implement the smallest coherent change, then reach GREEN.\n- **IMPORTANT:** Before ending every implementation session, run `/review`. In a non-interactive environment, use the stable local Codex CLI command `codex exec --ignore-user-config review --disable apps --disable plugins --disable remote_plugin -c 'model_provider=\"openai\"' -c 'model=\"gpt-5.6-sol\"' -c 'review_model=\"gpt-5.6-sol\"' --uncommitted` as a pre-commit review of working-tree changes.\n- Run reviews from the local worktree with the exact provider, model, config-isolation, and connector-disable flags shown. Immediately before each review, confirm `codex login status` shows ChatGPT authentication and both `CODEX_API_KEY` and `OPENAI_API_KEY` are unset or empty. Stop on API-key authentication or overrides unless explicitly authorized; these can incur separate usage charges.\n- Before calling a PR ready, refresh its authoritative base with `git fetch origin +refs/heads/<base-branch>:refs/remotes/origin/<base-branch>` and run `codex exec --ignore-user-config review --disable apps --disable plugins --disable remote_plugin -c 'model_provider=\"openai\"' -c 'model=\"gpt-5.6-sol\"' -c 'review_model=\"gpt-5.6-sol\"' --base origin/<base-branch>` on the final committed head so the complete branch or PR diff is reviewed against the current base. If the applicable review mechanism is unavailable, report the review gate as blocked and do not call the PR ready. Fix and verify every valid finding, and explicitly verify and disposition any false positive or non-actionable finding. After any change, rerun the applicable review command and repeat until it reports no actionable findings.\n- PR readiness requires a clear final full-branch `/review` and the GitHub gates below. Any subsequent diff change invalidates the review. An investigation may finish with findings or blocked gates without implying PR readiness.\n- Keep one logical change per commit.\n- Preserve additive PR history. Do not squash, rebase, force-push, or otherwise rewrite commits unless the user explicitly requests that strategy.\n- Re-run the focused failing test after each fix before broad validation.\n- Delegate substantive independent reads or focused validation with distinct ownership; verify conclusions centrally. Handle small or dependent work locally. Serialize edits, commits, pushes, review communication, approvals, merges, releases, and cleanup; agents must not concurrently edit shared branches or files.\n- Treat repository-wide commands that compile, lint, or test broad package sets—including `make build`, `make lint`, `make test`, `go test ./...`, race tests over `./...`, and `golangci-lint run ./...`—as host-intensive gates. Give each gate a CPU budget and keep the sum of running gate budgets within the host's logical CPU count, for example three gates with a budget of 3 on a 10-CPU host. When several agents share a host, run gates concurrently only through a slot mechanism the coordinating agent provides, such as a counting lock that reserves a slot atomically and releases it on exit, and wait for a free slot instead of competing for the same CPUs; without one, run one gate at a time. Run a change's final gates together in one slot instead of queuing for each. Never terminate another task's process without explicit authorization.\n- Within a worktree, wait for each focused test to finish before starting a broad gate. Record the checked commit, relevant working-tree state, command, and environment. Reuse passing checks while their inputs remain unchanged, including during status-only follow-ups. Rerun affected checks when source, test inputs, commands, environment, toolchain, or requested verification changes; unrelated temporary files do not invalidate results. Complete every required gate for the final change, and preserve the separate full-branch review requirement after any diff change.\n- Tool flags are limits within a gate's budget, not values to add together. Avoid multiplying Go package and in-binary concurrency: for a budget of `B`, use `GOMAXPROCS=1 go test -p=B -parallel=1 ./...` for package fan-out or `GOMAXPROCS=B go test -p=1 -parallel=B ./...` for one package at a time. Use `golangci-lint run --concurrency=B ./...` for a linter gate.\n\nUser-facing commands and flags are stable until deprecated or removed. Do not delete stable behavior directly. Deprecations require warning text, transition tests, migration guidance, and a release-note entry.\n\n## Implementation invariants\n\n- Put command implementations in `internal/cli/<domain>` and register new top-level commands in `internal/cli/registry/registry.go`.\n- Set `UsageFunc: shared.DefaultUsageFunc` on command groups and subcommands.\n- Use `shared.ContextWithTimeout` or `shared.ContextWithUploadTimeout` for outbound HTTP.\n- Read and write repository-controlled or API-supplied paths through `internal/rootfs`, anchored to the operator-selected root for that command, instead of plain `os` file operations.\n- Validate required flags before side effects and assert stderr messages in tests.\n- Use `internal/cli/cmdtest` for CLI-level coverage and `httptest` for HTTP payload coverage.\n- Remove shared wrappers or helpers made obsolete by a refactor.\n\n## Tests\n\nWrite a test only when it fails if behavior a user or caller depends on breaks, and no existing test already fails for that break. Name that regression before writing the test.\n\nWrite:\n\n- A regression test that fails before every bug fix and passes after it.\n- CLI contract tests: flag validation with its stderr text, exit codes, JSON output fields, and request wiring (method, path, query, body) through `httptest`.\n- Error, partial-failure, and cancellation paths.\n- Security invariants: rootfs anchoring, secret redaction, keychain and `HOME` isolation, credential handling.\n- Concurrency ordering and bounds, run under `-race`.\n\nDo not write tests that:\n\n- Restate the implementation: constants, defaults copied from code, fields the test just set, or a stub returning its input.\n- Exercise the standard library or a dependency, such as a JSON round-trip of a plain struct.\n- Only check for no panic, non-nil, `err == nil`, or `strings.Contains` on one word.\n- Copy another test per endpoint, command, or flag with only names or IDs changed. Add a row to the existing table instead of a sibling test.\n- Drive the same code path with the same or weaker assertions as an existing test.\n- Cover an unexported helper that its callers' tests already cover.\n- Lock incidental text: whitespace, help prose, or the order of unordered output.\n- Target code no production path runs, or always skip.\n\nAlso:\n\n- Do not use `time.Sleep` or real timeouts. Inject intervals, clocks, and retry delays.\n- Keep test code proportionate to the change. A small fix gets one small test.\n- Justify every new test in the PR body by naming the regression it catches.\n- Before removing a test, show which remaining test still fails for the same break.\n\n## Build and validation\n\nEvery manual test command must use `ASC_BYPASS_KEYCHAIN=1` to prevent host keychain prompts and profile bleed-through. The `make test` target enforces the same environment internally.\n\nBefore opening or merging a substantive behavior PR, run `make build`, `make format`, `make check-docs`, `make lint`, and `ASC_BYPASS_KEYCHAIN=1 make test`. If command help changed, run `make generate-command-docs` and commit `docs/COMMANDS.md` before those checks. For a narrowly scoped documentation or skill change, run `make check-docs`, which includes the repository and skill validators, instead of the full Go suite unless the changed surface or repository policy requires more. For a Wall-only PR, run `make check-wall-of-apps` on the exact head.\n\nRequire GitHub-required checks before merge. Report relevant advisory failures, but do not wait for non-required jobs.\n\nDo not weaken CI: formatting, documentation, lint, and tests must run on PR and `main` workflows.\n\n## GitHub and issue guardrails\n\n- Inspect thread-aware GitHub review state before declaring a PR clean; flat comments do not prove every thread is resolved.\n- A PR is ready only when the latest head was reviewed, required checks pass, required reviews are satisfied, actionable threads are resolved, and GitHub reports it mergeable.\n- If `main` advances, recheck the exact PR head, merge-base diff, duplicate or overlap risk, review threads, required checks, and mergeability against current `main` without changing the branch. Do not update, rebase, or merge `main` into a clean PR merely to refresh its base. Update a branch only when GitHub already reports an actual merge conflict, or when an explicitly authorized merge attempt made with every readiness gate passing is refused under strict up-to-date branch protection. Never bypass branch protection with an admin merge.\n- For loop or babysit requests, follow `$watch-asc-pr` until ready or materially blocked, preserving the authorized actions. Use its checkpoint and heartbeat procedure when only waiting remains.\n- When merge is explicitly authorized, preserve the PR commits with a regular merge commit, for example `gh pr merge <number> --merge --match-head-commit <sha>`. Do not squash unless the user explicitly requests squash for that PR.\n- For read-only triage, recommend exactly one type (`bug`, `enhancement`, `question`), one priority (`p0`-`p3`), and one difficulty (`easy`, `medium`, `hard`). When issue creation or label changes are authorized, apply exactly one label from each bucket and remove conflicting labels.\n\n## Authentication and live testing\n\nApp Store Connect API keys come from https://appstoreconnect.apple.com/access/integrations/api and must never be committed.\n\nTests touching auth must isolate relevant environment and config state. For live verification, prefer read-only calls. Live mutations require authorization, including on disposable app `6759231657`; a disposable target does not itself grant permission. Include temporary-resource cleanup in the authorized verification plan and record anything left behind. Never mutate a non-disposable app without explicit approval.\n\n## Handoff contract\n\nReport the outcome, decisive evidence, material unknowns, and next action concisely. Include design or command details only when useful. Distinguish source review, tests, remote checks, merge, release artifacts, and provider state. Report pre-existing failures and unverified acceptance criteria.\n\n## References\n\n- Go standards: `docs/GO_STANDARDS.md`\n- Testing patterns: `docs/TESTING.md`\n- Git workflow and CLI structure: `docs/CONTRIBUTING.md`\n- API quirks: `docs/API_NOTES.md`\n- Development setup, PRs, labels, and Wall submissions: `CONTRIBUTING.md`\n","CLAUDE.md":"@Agents.md\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nUnofficial, fast, lightweight, agent-assisted, reviewer-owned CLI for the App Store Connect API. Built in Go with [ffcli](https://github.com/peterbourgon/ff).\n\n## Skills\n\nSkills for using `asc` in app workflows live at https://github.com/rorkai/app-store-connect-cli-skills.\n\nRepository-maintainer workflows live under `.agents/skills/`:\n\n- `$develop-asc-change`: design, implement, and verify commands, flags, endpoints, bug fixes, and behavior-changing refactors.\n- `$audit-asc-pr`: audit a complete PR and, when authorized, fix proven defects.\n- `$watch-asc-pr`: recheck PR comments, checks, head changes, and merge readiness.\n- `$triage-asc-issue`: reproduce, classify, label, and scope an issue.\n- `$review-wall-of-apps-prs`: validate, approve, and merge Wall of Apps submissions safely.\n- `$release-asc-cli`: publish and verify an end-to-end CLI repository release, including the release film and the announcement thread.\n- `$sync-asc-skills`: check the external ASC workflow skills for CLI-surface drift.\n\nUse these skills for their matching workflows instead of expanding this always-loaded file with task-specific procedures.\n\n## Authority and follow-through\n\n- Audits, reviews, research, triage, status checks, and composing draft text are read-only. Creating or updating a remote draft is an external write. Edits, commits, pushes, PR creation, comments, labels, approval, merge, publication, external sends, and deletion require authority from the request or session context. One request may authorize several actions; do not ask again for granted authority. Creating a PR for agreed changes includes the necessary edits, checks, commit, branch push, and PR creation, but not merge.\n- User instructions override skill guidelines within system and developer constraints; skill selection grants no authority. Make routine choices from repository conventions. Ask only about material scope, compatibility, or authority gaps, after preparing authorized work for review; continue independent work while awaiting answers.\n- If a skill causes a pause or scope change, link its `SKILL.md`, quote the instruction, and explain the unresolved decision. Preserve the objective, targets, authority, and verified progress across follow-ups and skill handoffs unless the user changes scope. Switching skills continues the current task; a failing gate blocks dependent actions, not independent authorized work. Inspect state before retrying an interrupted or uncertain write.\n\n## Core CLI contract\n\n- Use long-form flags in docs, tests, and examples (`--app`, `--output`).\n- Output defaults are TTY-aware: `table` in terminals and minified `json` for pipes or CI. Explicit `--output` wins.\n- Do not add interactive prompts. Require `--confirm` for destructive operations.\n- Use `--paginate` when callers request every page.\n- Write data to stdout and errors or diagnostics to stderr.\n- Never accept and silently ignore an unsupported flag or value.\n- JSON output shape is part of the command contract: reads of ASC collections/resources print Apple's envelope unmodified; mutation receipts and computed results use exported camelCase structs in internal/asc/output_*.go with a registered renderer; added fields are additive and removals follow the stability ladder.\n- Website changelog entries must omit Wall of Apps membership churn, including app additions, removals, renames, icon changes, and routine metadata refreshes. Document only significant user-facing changes to the Wall of Apps feature or contribution workflow.\n\n## Discover current behavior\n\nNever rely on memorized command shapes. Before implementing, testing, or documenting a command, inspect its current help:\n\n```bash\nasc --help\nasc builds --help\nasc builds list --help\n```\n\nFor App Store Connect API documentation, prefer the `sosumi.ai` mirror over `developer.apple.com`.\n\nUse the offline OpenAPI snapshot for endpoint and schema truth:\n\n- `docs/openapi/latest.json`: complete snapshot.\n- `docs/openapi/paths.txt`: quick endpoint index.\n- `docs/openapi/README.md`: update procedure.\n\nValidate attributes against the exact create or update request schema. Validate filters and includes against the specific endpoint; related top-level and relationship endpoints often differ.\n\n## Development workflow\n\n- Work on a branch and use an isolated worktree when the main checkout is dirty or other work is in progress.\n- Do not push directly to `main`, bypass hooks, use `--no-verify`, or skip checks to force a result.\n- Use TDD for behavior changes: reproduce or establish RED, implement the smallest coherent change, then reach GREEN.\n- **IMPORTANT:** Before ending every implementation session, run `/review`. In a non-interactive environment, use the stable local Codex CLI command `codex exec --ignore-user-config review --disable apps --disable plugins --disable remote_plugin -c 'model_provider=\"openai\"' -c 'model=\"gpt-5.6-sol\"' -c 'review_model=\"gpt-5.6-sol\"' --uncommitted` as a pre-commit review of working-tree changes.\n- Run reviews from the local worktree with the exact provider, model, config-isolation, and connector-disable flags shown. Immediately before each review, confirm `codex login status` shows ChatGPT authentication and both `CODEX_API_KEY` and `OPENAI_API_KEY` are unset or empty. Stop on API-key authentication or overrides unless explicitly authorized; these can incur separate usage charges.\n- Before calling a PR ready, refresh its authoritative base with `git fetch origin +refs/heads/<base-branch>:refs/remotes/origin/<base-branch>` and run `codex exec --ignore-user-config review --disable apps --disable plugins --disable remote_plugin -c 'model_provider=\"openai\"' -c 'model=\"gpt-5.6-sol\"' -c 'review_model=\"gpt-5.6-sol\"' --base origin/<base-branch>` on the final committed head so the complete branch or PR diff is reviewed against the current base. If the applicable review mechanism is unavailable, report the review gate as blocked and do not call the PR ready. Fix and verify every valid finding, and explicitly verify and disposition any false positive or non-actionable finding. After any change, rerun the applicable review command and repeat until it reports no actionable findings.\n- PR readiness requires a clear final full-branch `/review` and the GitHub gates below. Any subsequent diff change invalidates the review. An investigation may finish with findings or blocked gates without implying PR readiness.\n- Keep one logical change per commit.\n- Preserve additive PR history. Do not squash, rebase, force-push, or otherwise rewrite commits unless the user explicitly requests that strategy.\n- Re-run the focused failing test after each fix before broad validation.\n- Delegate substantive independent reads or focused validation with distinct ownership; verify conclusions centrally. Handle small or dependent work locally. Serialize edits, commits, pushes, review communication, approvals, merges, releases, and cleanup; agents must not concurrently edit shared branches or files.\n- Treat repository-wide commands that compile, lint, or test broad package sets—including `make build`, `make lint`, `make test`, `go test ./...`, race tests over `./...`, and `golangci-lint run ./...`—as host-intensive gates. Give each gate a CPU budget and keep the sum of running gate budgets within the host's logical CPU count, for example three gates with a budget of 3 on a 10-CPU host. When several agents share a host, run gates concurrently only through a slot mechanism the coordinating agent provides, such as a counting lock that reserves a slot atomically and releases it on exit, and wait for a free slot instead of competing for the same CPUs; without one, run one gate at a time. Run a change's final gates together in one slot instead of queuing for each. Never terminate another task's process without explicit authorization.\n- Within a worktree, wait for each focused test to finish before starting a broad gate. Record the checked commit, relevant working-tree state, command, and environment. Reuse passing checks while their inputs remain unchanged, including during status-only follow-ups. Rerun affected checks when source, test inputs, commands, environment, toolchain, or requested verification changes; unrelated temporary files do not invalidate results. Complete every required gate for the final change, and preserve the separate full-branch review requirement after any diff change.\n- Tool flags are limits within a gate's budget, not values to add together. Avoid multiplying Go package and in-binary concurrency: for a budget of `B`, use `GOMAXPROCS=1 go test -p=B -parallel=1 ./...` for package fan-out or `GOMAXPROCS=B go test -p=1 -parallel=B ./...` for one package at a time. Use `golangci-lint run --concurrency=B ./...` for a linter gate.\n\nUser-facing commands and flags are stable until deprecated or removed. Do not delete stable behavior directly. Deprecations require warning text, transition tests, migration guidance, and a release-note entry.\n\n## Implementation invariants\n\n- Put command implementations in `internal/cli/<domain>` and register new top-level commands in `internal/cli/registry/registry.go`.\n- Set `UsageFunc: shared.DefaultUsageFunc` on command groups and subcommands.\n- Use `shared.ContextWithTimeout` or `shared.ContextWithUploadTimeout` for outbound HTTP.\n- Read and write repository-controlled or API-supplied paths through `internal/rootfs`, anchored to the operator-selected root for that command, instead of plain `os` file operations.\n- Validate required flags before side effects and assert stderr messages in tests.\n- Use `internal/cli/cmdtest` for CLI-level coverage and `httptest` for HTTP payload coverage.\n- Remove shared wrappers or helpers made obsolete by a refactor.\n\n## Tests\n\nWrite a test only when it fails if behavior a user or caller depends on breaks, and no existing test already fails for that break. Name that regression before writing the test.\n\nWrite:\n\n- A regression test that fails before every bug fix and passes after it.\n- CLI contract tests: flag validation with its stderr text, exit codes, JSON output fields, and request wiring (method, path, query, body) through `httptest`.\n- Error, partial-failure, and cancellation paths.\n- Security invariants: rootfs anchoring, secret redaction, keychain and `HOME` isolation, credential handling.\n- Concurrency ordering and bounds, run under `-race`.\n\nDo not write tests that:\n\n- Restate the implementation: constants, defaults copied from code, fields the test just set, or a stub returning its input.\n- Exercise the standard library or a dependency, such as a JSON round-trip of a plain struct.\n- Only check for no panic, non-nil, `err == nil`, or `strings.Contains` on one word.\n- Copy another test per endpoint, command, or flag with only names or IDs changed. Add a row to the existing table instead of a sibling test.\n- Drive the same code path with the same or weaker assertions as an existing test.\n- Cover an unexported helper that its callers' tests already cover.\n- Lock incidental text: whitespace, help prose, or the order of unordered output.\n- Target code no production path runs, or always skip.\n\nAlso:\n\n- Do not use `time.Sleep` or real timeouts. Inject intervals, clocks, and retry delays.\n- Keep test code proportionate to the change. A small fix gets one small test.\n- Justify every new test in the PR body by naming the regression it catches.\n- Before removing a test, show which remaining test still fails for the same break.\n\n## Build and validation\n\nEvery manual test command must use `ASC_BYPASS_KEYCHAIN=1` to prevent host keychain prompts and profile bleed-through. The `make test` target enforces the same environment internally.\n\nBefore opening or merging a substantive behavior PR, run `make build`, `make format`, `make check-docs`, `make lint`, and `ASC_BYPASS_KEYCHAIN=1 make test`. If command help changed, run `make generate-command-docs` and commit `docs/COMMANDS.md` before those checks. For a narrowly scoped documentation or skill change, run `make check-docs`, which includes the repository and skill validators, instead of the full Go suite unless the changed surface or repository policy requires more. For a Wall-only PR, run `make check-wall-of-apps` on the exact head.\n\nRequire GitHub-required checks before merge. Report relevant advisory failures, but do not wait for non-required jobs.\n\nDo not weaken CI: formatting, documentation, lint, and tests must run on PR and `main` workflows.\n\n## GitHub and issue guardrails\n\n- Inspect thread-aware GitHub review state before declaring a PR clean; flat comments do not prove every thread is resolved.\n- A PR is ready only when the latest head was reviewed, required checks pass, required reviews are satisfied, actionable threads are resolved, and GitHub reports it mergeable.\n- If `main` advances, recheck the exact PR head, merge-base diff, duplicate or overlap risk, review threads, required checks, and mergeability against current `main` without changing the branch. Do not update, rebase, or merge `main` into a clean PR merely to refresh its base. Update a branch only when GitHub already reports an actual merge conflict, or when an explicitly authorized merge attempt made with every readiness gate passing is refused under strict up-to-date branch protection. Never bypass branch protection with an admin merge.\n- For loop or babysit requests, follow `$watch-asc-pr` until ready or materially blocked, preserving the authorized actions. Use its checkpoint and heartbeat procedure when only waiting remains.\n- When merge is explicitly authorized, preserve the PR commits with a regular merge commit, for example `gh pr merge <number> --merge --match-head-commit <sha>`. Do not squash unless the user explicitly requests squash for that PR.\n- For read-only triage, recommend exactly one type (`bug`, `enhancement`, `question`), one priority (`p0`-`p3`), and one difficulty (`easy`, `medium`, `hard`). When issue creation or label changes are authorized, apply exactly one label from each bucket and remove conflicting labels.\n\n## Authentication and live testing\n\nApp Store Connect API keys come from https://appstoreconnect.apple.com/access/integrations/api and must never be committed.\n\nTests touching auth must isolate relevant environment and config state. For live verification, prefer read-only calls. Live mutations require authorization, including on disposable app `6759231657`; a disposable target does not itself grant permission. Include temporary-resource cleanup in the authorized verification plan and record anything left behind. Never mutate a non-disposable app without explicit approval.\n\n## Handoff contract\n\nReport the outcome, decisive evidence, material unknowns, and next action concisely. Include design or command details only when useful. Distinguish source review, tests, remote checks, merge, release artifacts, and provider state. Report pre-existing failures and unverified acceptance criteria.\n\n## References\n\n- Go standards: `docs/GO_STANDARDS.md`\n- Testing patterns: `docs/TESTING.md`\n- Git workflow and CLI structure: `docs/CONTRIBUTING.md`\n- API quirks: `docs/API_NOTES.md`\n- Development setup, PRs, labels, and Wall submissions: `CONTRIBUTING.md`\n","isInternal":false,"tokens":3211,"sizeBytes":15233},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"@Agents.md\n","isInternal":false,"tokens":4,"sizeBytes":11},{"name":"openai.yaml","path":".agents/skills/audit-asc-pr/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/audit-asc-pr/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n  display_name: \"Audit ASC Pull Request\"\n  short_description: \"Review ASC CLI PRs and identify concrete defects\"\n  default_prompt: \"Use $audit-asc-pr to audit this ASC CLI pull request end to end.\"\n","isInternal":false,"tokens":49,"sizeBytes":209},{"name":"SKILL.md","path":".agents/skills/audit-asc-pr/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/audit-asc-pr/SKILL.md","title":"audit-asc-pr","category":"anthropic-skill","format":"markdown","content":"---\nname: audit-asc-pr\ndescription: Audit App-Store-Connect-CLI pull requests end to end and fix concrete defects when authorized. Use for PR review, value and blast-radius assessment, issue verification, or requested fixes before merge.\n---\n\n# Audit an ASC CLI pull request\n\nAudit the entire PR under the authority and review rules in `AGENTS.md`.\n\n## Establish the contract\n\n1. Read `AGENTS.md` and resolve the repository, PR number, base branch, head branch, and exact head SHA.\n2. Read the PR body, every commit, linked issues, current checks, reviews, and comments.\n3. Fetch thread-aware review state with GitHub GraphQL. Do not treat a flat comment list as proof that all review threads are resolved.\n4. State the behavior the PR claims to change and the evidence needed to prove it.\n\n## Isolate and inspect\n\n1. Use a dedicated worktree and local branch for the PR. Preserve the user's main checkout and unrelated worktrees.\n2. Inspect the full merge-base diff and all PR commits, not only the latest commit.\n3. Compare the implementation with the linked issue and current product behavior. Check architecture fit, compatibility, error paths, permissions, destructive operations, output contracts, and missing cleanup.\n4. Verify claims from bots or reviewers against code, schemas, and tests before editing.\n5. Flag added tests that do not meet the test rules in `AGENTS.md`, naming the rule each one breaks.\n6. Identify the blast radius: commands, shared helpers, API resources, output formats, auth modes, and release surfaces affected.\n\n## Verify behavior\n\n1. Run the relevant current `--help` paths before judging command shape.\n2. Build a binary when CLI behavior, flags, output, or exit codes changed. Exercise realistic invocations against the built binary.\n3. For API-facing changes, verify the exact endpoint and method in `docs/openapi/latest.json`, including create-versus-update attributes and endpoint-specific query parameters.\n4. Run focused tests first, then checks required by repository policy or proportional to the diff. Pending or unrelated advisory CI does not block the audit once required checks pass; report relevant advisory failures.\n5. Prefer read-only live App Store Connect verification. If live mutations and their cleanup are authorized, use the disposable app `6759231657` and record anything that could not be removed. Never mutate another app without explicit approval.\n6. Preserve uncertainty when live state cannot reproduce an edge case; use deterministic fixtures or tests instead of claiming success.\n\n## Fix forward\n\nFor authorized fixes:\n\n1. Reproduce each defect before changing code.\n2. Add or adjust a failing regression test, confirm the failure, implement the smallest coherent fix, and rerun the focused test.\n3. Add fixes as logical commits traceable to findings or review threads.\n4. Push to the PR head when permitted. If the contributor branch cannot accept maintainer pushes, report the exact limitation and prepare a separate fix PR only when authorized.\n5. When review communication is authorized, reply to and resolve only threads fully addressed by the pushed change.\n6. Re-fetch the head SHA, checks, reviews, and GraphQL threads after every push.\n\nDo not post a generic top-level audit summary unless the user asks. Put actionable findings in review threads when review communication is authorized.\n\n## Apply the merge gate\n\nDo not call the PR ready until all of the following are true:\n\n- The latest head was audited against current `main` under the branch-update rules in `AGENTS.md`.\n- The final committed head passed the full-branch local review loop required by `AGENTS.md` against the current authoritative base, with no subsequent diff change.\n- Relevant focused and GitHub-required checks pass. Non-required checks may still be pending.\n- No actionable unresolved review thread remains.\n- Required reviews are satisfied.\n- GitHub reports the PR mergeable without conflicts. Interpret `BLOCKED` or `UNSTABLE` through the required-check, required-review, and thread gates above; do not require a `CLEAN` merge state when only advisory jobs remain.\n- Live or deterministic verification supports the claimed behavior.\n\nFor requested follow-up monitoring, use `$watch-asc-pr`. Approve and merge only under the authority, history, and exact-head rules in `AGENTS.md`.\n\n## Hand off\n\nReport findings, evidence, remaining gates, and the merge recommendation. Include any fixes, pushes, live mutations, and cleanup.\n","frontmatter":{"name":"audit-asc-pr","description":"Audit App-Store-Connect-CLI pull requests end to end and fix concrete defects when authorized. Use for PR review, value and blast-radius assessment, issue verification, or requested fixes before merge."},"isInternal":false,"tokens":906,"sizeBytes":4479},{"name":"openai.yaml","path":".agents/skills/develop-asc-change/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/develop-asc-change/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n  display_name: \"Develop ASC Change\"\n  short_description: \"Design, implement, and verify ASC CLI changes\"\n  default_prompt: \"Use $develop-asc-change to implement this ASC CLI behavior change completely.\"\n","isInternal":false,"tokens":46,"sizeBytes":215},{"name":"test-matrix.md","path":".agents/skills/develop-asc-change/references/test-matrix.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/develop-asc-change/references/test-matrix.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# ASC CLI behavior test matrix\n\nApply the cases relevant to the changed behavior, under the test rules in `AGENTS.md`. Use existing coverage when it proves the contract. Add tests only for distinct observable behavior or demonstrated regressions; do not repeat shared parser and renderer coverage for each command.\n\n## Flags and parsing\n\n- Cover the valid path and one invalid value (stderr and exit code `2`) of a new or changed flag, unless an existing test already does. Add them as rows in an existing table when one exists.\n- When parsing or dispatch changes, cover affected flag ordering and values that look like subcommand names.\n- Assert required-flag errors on stderr; do not test only for `flag.ErrHelp`.\n- Never accept and silently ignore an unsupported flag or value.\n\n## Output and exit behavior\n\n- Parse JSON or XML and assert fields instead of relying only on substring matching.\n- Assert representative table or Markdown structure and headers.\n- Verify stdout, stderr, and exit code with a built binary for changed CLI behavior.\n- Test successful artifact/report writes and write failures.\n- Prevent duplicate usage or duplicate error output.\n\n## HTTP and API behavior\n\n- Use `httptest` to assert method, path, query, headers, and request body.\n- Cover a realistic non-empty response per response family. Test validation and API errors only where the endpoint handles them differently from the shared client.\n- Keep representative response-decoding assertions when consolidating table-driven tests.\n- Test pagination and empty responses where applicable.\n\n## Auth and process isolation\n\n- Run repository tests with `ASC_BYPASS_KEYCHAIN=1`.\n- Use `t.Setenv` and a temporary `ASC_CONFIG_PATH` for auth-sensitive tests.\n- Set or clear `ASC_PROFILE`, `ASC_KEY_ID`, `ASC_ISSUER_ID`, `ASC_PRIVATE_KEY_PATH`, `ASC_PRIVATE_KEY`, `ASC_PRIVATE_KEY_B64`, and `ASC_STRICT_AUTH` locally when relevant.\n- Restore exact process state when a test cannot use `t.Setenv`.\n- Allow `t.Skip` only for a specific documented and reproducible condition; never use a broad error-string skip.\n\n## Live verification\n\n- Prefer read-only calls first.\n- For authorized mutations and cleanup, use a disposable resource, record its ID, and delete or cancel it afterward.\n- Assert the externally visible result, not only a successful HTTP status.\n- Report any state that could not be cleaned up.\n","isInternal":false,"tokens":491,"sizeBytes":2380},{"name":"SKILL.md","path":".agents/skills/develop-asc-change/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/develop-asc-change/SKILL.md","title":"develop-asc-change","category":"anthropic-skill","format":"markdown","content":"---\nname: develop-asc-change\ndescription: Design, implement, and verify behavior changes in App-Store-Connect-CLI. Use when adding or changing a command, flag, API endpoint, output format, exit code, shared CLI behavior, or when fixing or refactoring behavior that requires code and tests.\n---\n\n# Develop an ASC CLI change\n\nFollow `AGENTS.md` for authority, CLI contracts, implementation invariants, validation, and review gates.\n\n## Write the design note\n\nFor a small fix, record the reproduced failure, intended behavior, and focused check. For new public behavior or compatibility decisions, also record:\n\n1. Placement in the existing command taxonomy and registry.\n2. Current `--help` behavior and expected invocation shape.\n3. Exact OpenAPI endpoint, method, request schema, query parameters, and response shape when API-facing.\n4. Flags, output formats, stdout/stderr behavior, and exit codes.\n5. Compatibility, lifecycle, migration, and deprecation impact.\n6. RED-GREEN tests, black-box checks, live verification, edge cases, and failure modes.\n7. Credible alternatives when a material design trade-off exists.\n\n## Establish RED\n\n- For a bug, reproduce it first and add the smallest regression test that fails for the expected reason.\n- For a feature, start with CLI-level coverage of the changed observable contract; add unit or HTTP tests for distinct behavior that those tests do not cover.\n- For a behavior-changing refactor, use existing characterization coverage where sufficient and add coverage for missing behavior before moving code.\n- Run the focused test and record the expected failure before implementation.\n\nRead [references/test-matrix.md](references/test-matrix.md) for applicable CLI, output, artifact, and auth cases. Reuse sufficient existing coverage; do not duplicate shared parser or renderer tests for every command. Every new test must meet the test rules in `AGENTS.md`.\n\n## Validate API support\n\n1. Search `docs/openapi/paths.txt`, then inspect the exact operation in `docs/openapi/latest.json`.\n2. Apply the endpoint-specific schema checks in `AGENTS.md`.\n3. If the API cannot support the behavior, implement explicit client-side behavior or document the limitation; do not ship a misleading flag.\n\n## Implement narrowly\n\nApply `AGENTS.md`'s implementation invariants. Return usage errors with exit code `2`.\n\n## Reach GREEN and verify\n\n1. Rerun the focused failing test after each small fix.\n2. Run adjacent package and command tests.\n3. Build a binary at a worktree-specific path and verify realistic invocations, output streams, and exit codes. Do not share a fixed `/tmp/asc` path with concurrent tasks.\n4. Run a minimal live smoke test when behavior depends on App Store Connect quirks. Prefer read-only calls; live mutations and cleanup require authority under `AGENTS.md`.\n5. Apply `AGENTS.md`'s validation gate, including command-doc generation when help changes. Public CLI behavior, shared code, release surfaces, and meaningful defect or security fixes require the full gate.\n\nBefore handoff, compare the exact branch head with current `main` read-only. Follow the branch-update rules in `AGENTS.md`; a newer base alone does not justify changing the branch.\n\n## Hand off\n\nUse `AGENTS.md`'s handoff contract; include invocation and compatibility details for public-contract changes.\n","frontmatter":{"name":"develop-asc-change","description":"Design, implement, and verify behavior changes in App-Store-Connect-CLI. Use when adding or changing a command, flag, API endpoint, output format, exit code, shared CLI behavior, or when fixing or refactoring behavior that requires code and tests."},"isInternal":false,"tokens":693,"sizeBytes":3328},{"name":"openai.yaml","path":".agents/skills/release-asc-cli/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/release-asc-cli/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n  display_name: \"Release ASC CLI\"\n  short_description: \"Publish and verify an ASC CLI repository release\"\n  default_prompt: \"Use $release-asc-cli to publish and verify the requested ASC CLI release.\"\n","isInternal":false,"tokens":46,"sizeBytes":211},{"name":"release-announcement.md","path":".agents/skills/release-asc-cli/references/release-announcement.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/release-asc-cli/references/release-announcement.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# Release announcement\n\nEvery release gets a short film and a thread. The thread reuses the same posts on X, Threads, Bluesky, and Mastodon; LinkedIn stays off.\n\n## Render the release film\n\nThe films live in the private `rudrankriyam/asc-motion` repository (locally `~/Developer/CLIs/asc-motion`, Remotion with bun). If that checkout is unavailable, skip the film, say so in the handoff, and post the thread without it.\n\n1. From the repository root run `./new-release-film.sh NNNN-asc-X-Y X.Y.Z`, where `NNNN` is the next free folder number.\n2. Edit only `NNNN-asc-X-Y/src/content.ts`. Take three or four headline features from the website changelog entry for the version, each with one exact command from the matching guide. Never invent a flag; check every command against `asc <command> --help`. Put the remaining notable changes in the `FIXES` list, one line each under 60 characters.\n3. Inside the folder run `bun install && bun run render`. The music bed is synthesised on every render; nothing licensed is involved.\n4. Render one still per beat with `bunx remotion still AscRelease --frame N out/<beat>.png` and look at each one. Captions must stay clear of the `>_` mark and commands must finish typing before the beat ends; shorten the caption or command if not.\n5. Commit the folder on a branch named `release-film-X-Y` in `asc-motion` and open a pull request there. Merge only when the user asks.\n\nDo not reuse the Rork motion kit grammar (cursor, gradient pill, camera moves, click sounds, grain). The film is typographic: version, product name, orange rule, typed commands.\n\n## Thread format\n\nPost 1 carries the film and nothing else that the film already types:\n\n```\nApp Store Connect CLI X.Y.Z\n\n<one line naming the three or four headline features>\n\nhttps://github.com/rorkai/App-Store-Connect-CLI\n```\n\nNo sign-off line after the feature line, no emojis, no teaser such as \"every change is in the thread below\".\n\nThen one post per change in the changelog, with its command inline as plain text (no backticks). Keep every post under Bluesky's 300-character limit so the thread is identical on all four platforms.\n\nThe last post is only:\n\n```\nFull changelog:\n\nhttps://asccli.sh/changelog\n```\n\n## Typefully workflow\n\nUse this section only when an external draft is authorized. Otherwise include the finished posts in the local handoff without creating a remote draft.\n\n1. Only when a film was rendered: request a media upload for the `.mp4` with alt text that names the version and the beats. Upload the file to the returned presigned URL with `curl -T <file> \"<upload_url>\"` and no `Content-Type` header; adding one invalidates the signature. Poll the media status until it is `ready`. Without a film, skip this step and post 1 goes out as text.\n2. If an older unpublished draft for the same version exists, rewrite it in place with the thread above instead of creating a second draft. Published drafts cannot be edited through the API, so leave those alone. Do not delete any draft unless the request explicitly authorizes that; report leftover duplicates instead.\n3. Resolve the user's social set, enable X, Threads, Bluesky, and Mastodon, disable LinkedIn, attach the media ID (if any) to post 1 on every enabled platform, and save as an unscheduled draft only.\n4. Verify the returned state is `draft` and return its review URL.\n\nIf the Typefully connector is unavailable, preserve the finished posts in the handoff and report the external draft as incomplete, separately from artifact and distribution verification. Never silently publish through another tool.\n","isInternal":false,"tokens":820,"sizeBytes":3578},{"name":"SKILL.md","path":".agents/skills/release-asc-cli/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/release-asc-cli/SKILL.md","title":"release-asc-cli","category":"anthropic-skill","format":"markdown","content":"---\nname: release-asc-cli\ndescription: Publish and verify a new release of the App-Store-Connect-CLI repository. Use only when the user explicitly asks to release, tag, or publish a specific ASC CLI version, including the full GitHub release, artifact, Homebrew, WinGet, cleanup, and release-announcement workflow.\n---\n\n# Release the ASC CLI\n\n## Prove the release target\n\n1. Resolve the requested plain semantic version without a `v` prefix.\n2. Fetch `origin` and inspect the requested tag locally and remotely, any release, and its workflow runs before acting. For a new release, require the tag to be absent and inspect the release-worthy delta since the previous tag. When resuming, verify that the existing tag points to the previously approved release commit and resume only unfinished work; stop on a target mismatch.\n3. Query open PRs and confirm the intended changes are already merged.\n4. For a new release, create a clean detached worktree from the exact current `origin/main` commit. When resuming, use the tag's previously approved, verified release commit. Do not release from a dirty user checkout or an unmerged branch.\n5. Inspect `.github/workflows/release.yml` and current repository guidance instead of assuming an older release procedure still applies.\n\n## Run the release gate\n\nFor a new release, run and record the following checks. On resume, reuse completed checks only while their inputs remain valid under `AGENTS.md`; verify consumer-visible state freshly.\n\n```bash\nmake format\nmake check-docs\nmake check-wall-of-apps\nmake lint\nASC_BYPASS_KEYCHAIN=1 make test\nmake build\n./asc version\n```\n\nIf formatting changes files, inspect the diff and stop the release gate. Prepare necessary corrections on a branch only when authorized; they must pass repository review and validation and merge through the normal PR process before restarting from the updated `origin/main`. Never tag a correction committed only in the detached release worktree. Stop on unexplained failures; do not tag around a broken gate.\n\n## Publish\n\n1. For a new release, refresh `origin/main` and reconfirm the worktree HEAD equals the intended current `origin/main` commit. If `origin/main` advanced, inspect the delta and restart target selection and the release gate in a clean detached worktree at the newly selected commit before tagging. Checks run in the old worktree do not validate the new commit.\n2. Create an annotated tag using the exact requested version and push that tag explicitly. On resume, reuse the verified existing tag: skip the push if the remote tag already matches; if only the local tag exists, push it only within the established release authority. Never replace a mismatched remote tag.\n3. Locate the tag-triggered GitHub Actions run and watch it through completion.\n4. Do not retry by silently moving or recreating a published tag. Diagnose failures and preserve the immutable release history.\n\n## Verify consumer-visible state\n\nVerify:\n\n- The GitHub release is published, not draft or prerelease unless requested.\n- Expected macOS, Linux, Windows, and checksum assets exist.\n- A downloaded macOS binary reports the requested version and passes `codesign --verify`.\n- Downloaded artifact hashes match the published checksum file.\n- The Homebrew formula points to the new version and hashes.\n- The expected WinGet submission or PR exists and references the new version.\n- Any notarization step required by the current workflow succeeded.\n\nIf the `winget` job failed, inspect its rate-limit preflight, retry history, and current submission state first. For a transient failure, prefer one rerun of the failed job before manual repair; dispatch the full workflow only after confirming it will safely reuse the existing release. Wait for the logged reset time only when the primary quota bucket is zero; back off a few minutes for secondary throttles, 5xx responses, or transport failures. After a failed retry or a non-transient error, report the exact blocker instead of looping. See `docs/WINGET.md`.\n\n## Update the website changelog\n\nAfter every published release, prepare the changelog update for the root `CHANGELOG.md` in [rorkai/asc-website](https://github.com/rorkai/asc-website). It is the single source for [asccli.sh/changelog](https://asccli.sh/changelog); keep all release history in that file, without separate archives or a second CLI-repository changelog. Apply it to the website checkout when website edits are authorized by the request or session. Otherwise draft the entry text in the release handoff and report the website update as pending; do not modify the website checkout.\n\n1. Build the release inventory from the previous published tag through the released tag, using GitHub release notes, merged PRs, and tagged source. Include only changes shipped in that release. Verify command names, flags, and migration replacements against the released binary's help or tagged source, not a newer checkout.\n2. With website-edit authority, locate the website checkout by its remote and follow its `AGENTS.md`. Work from current website `origin/main` in an isolated worktree when needed. Inspect an existing entry or pending changelog PR before resuming so the same release is not added twice.\n3. Add the version under its UTC publication month, newest first, using the GitHub release publication date. Preserve older entries and update the month navigation when a new month begins.\n4. Write the entry using the rules and examples below. Keep one release link and one previous-tag comparison link at the end, with migration-guide links where relevant.\n5. Run the website's `pnpm run lint` and `pnpm build`, plus `git diff --check`. Verify the new entry renders, month links work, prior releases remain, and no inline PR references were introduced. Require session authority explicitly covering each website write: PR creation, merge, and deployment. A CLI release request alone does not grant those permissions. If a later website write is not authorized, retain the authorized edits and report that pending step separately from the binary release.\n\n### Changelog writing rules\n\n- Use short, flat bullets under `New features`, `Improvements and fixes`, and `Breaking changes` as applicable; omit empty sections. Split unrelated changes into separate bullets and use domain subheadings for large releases.\n- Describe the concrete behavior and its user impact, usually in one or two sentences. Keep important features, fixes, limitations, confirmation requirements, output or exit-code changes, and actionable migration replacements.\n- Omit PR numbers, inline PR links, commit hashes, introductory paragraphs, and generic claims such as “improved reliability.” PRs are evidence for writing the notes, not visible labels in the notes.\n- Cover significant shipped changes individually. Group routine dependency, CI, and test updates where appropriate; the release and comparison links retain the complete source history.\n- Omit Wall of Apps membership churn, including app additions, removals, renames, icon changes, and routine metadata refreshes. Include only significant user-facing changes to the Wall of Apps feature or contribution workflow.\n- Use backticks for commands, flags, environment variables, and JSON. Do not invent detail to expand a short entry or remove compatibility details merely to shorten a bullet.\n\nExample entry from the published 5.1.0 release (illustrative excerpt, not its complete notes):\n\n```markdown\n### 5.1.0 (2026-09-08)\n\n#### New features\n\n- `asc web api-keys list` accepts `--session-from-env` for CI reads.\n- `--session-from-env` reads `ASC_WEB_SESSION` in memory without changing the session cache or keychain.\n\n#### Improvements and fixes\n\n- Review-draft creation stops before writing when a successful preflight response omits `data`.\n\n[Release](https://github.com/rorkai/App-Store-Connect-CLI/releases/tag/5.1.0) · [Compare changes](https://github.com/rorkai/App-Store-Connect-CLI/compare/5.0.0...5.1.0)\n```\n\nMigration wording should name the replacement, for example: “App-scoped `--build-number` queries require `--platform` instead of assuming `IOS`.” Keep this behavior in its 5.0.0 entry; do not present historical examples as new changes in the next release.\n\n## Draft the announcement\n\nRead [references/release-announcement.md](references/release-announcement.md) after the release is visibly published and the website changelog entry exists. Render the release film from the `asc-motion` template, then prepare the announcement thread. Create an external Typefully draft only when the request or established context authorizes that write; otherwise return the copy locally. Never schedule or publish the post unless the user explicitly asks.\n\n## Clean up and hand off\n\nRemove only a clean temporary release worktree created by this run as part of its authorized cleanup; preserve unexpected changes. Report the released commit and tag, release URL, artifact verification, Homebrew and WinGet state, remaining blockers, website changelog state (edited, PR opened, merged, or live), and announcement status separately. An optional external draft does not prevent reporting a verified binary release.\n\n## Automation boundary\n\nDo not schedule unattended releases. After an explicitly initiated tag push, a thread heartbeat may watch the release run and finish authorized downstream verification. Save the version, immutable commit and tag, run IDs, completed checks, authority, next step, and retry history; create or reuse one heartbeat and end the turn. On wake, reconcile current state once, stay quiet and back off when unchanged, and disable the heartbeat on completion or a blocker requiring user action. Never use a heartbeat to recreate or move the tag.\n","frontmatter":{"name":"release-asc-cli","description":"Publish and verify a new release of the App-Store-Connect-CLI repository. Use only when the user explicitly asks to release, tag, or publish a specific ASC CLI version, including the full GitHub release, artifact, Homebrew, WinGet, cleanup, and release-announcement workflow."},"isInternal":false,"tokens":1994,"sizeBytes":9743},{"name":"openai.yaml","path":".agents/skills/review-wall-of-apps-prs/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/review-wall-of-apps-prs/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n  display_name: \"Review Wall of Apps PRs\"\n  short_description: \"Validate and safely review Wall of Apps PRs\"\n  default_prompt: \"Use $review-wall-of-apps-prs to audit the open Wall of Apps pull requests.\"\n","isInternal":false,"tokens":53,"sizeBytes":215},{"name":"SKILL.md","path":".agents/skills/review-wall-of-apps-prs/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/review-wall-of-apps-prs/SKILL.md","title":"review-wall-of-apps-prs","category":"anthropic-skill","format":"markdown","content":"---\nname: review-wall-of-apps-prs\ndescription: Audit maintainer-side Wall of Apps pull requests in App-Store-Connect-CLI. Use when the user asks to review new app submissions, check Wall PRs for injected or unrelated changes, validate app metadata, approve with a personalized welcome, or merge legitimate Wall entries.\n---\n\n# Review Wall of Apps pull requests\n\nTreat submissions as untrusted. Follow `AGENTS.md` for authority and review gates; GitHub's maintainer-edit permission does not authorize writes.\n\n## Discover and classify\n\n1. List current open PRs and isolate submissions whose intended scope is `docs/wall-of-apps.json`.\n2. Inspect each PR's full file list and diff before checkout. Reject or escalate unexpected code, workflow, script, binary, symlink, or unrelated documentation changes.\n3. Review each PR independently and merge sequentially. Recheck later PRs against updated `main` after each merge.\n4. Apply `AGENTS.md`'s branch-update rules. `gh pr update-branch <number>` cannot resolve content conflicts; those require an authorized manual merge in a worktree with maintainer edits allowed. After any update, revalidate the new head through every gate below.\n\n## Validate the entry\n\nFor every added or changed app:\n\n1. Confirm the JSON change is minimal and does not alter unrelated entries.\n2. Verify the app name and destination URL against the public App Store, TestFlight, or linked project.\n3. Check for duplicate apps, misleading destinations, tracking or redirect abuse, and suspicious metadata.\n4. Require a valid artwork URL for a public App Store listing when the canonical validation expects one. Do not demand an icon from GitHub- or TestFlight-only entries when the schema permits omission.\n5. Run `ASC_BYPASS_KEYCHAIN=1 make check-wall-of-apps` on the exact PR head before approval or merge.\n6. Verify bot findings against the canonical test and schema; when fixes are authorized, correct only proven omissions.\n\nUse an isolated checkout when needed to validate the exact head or apply authorized fixes, preserving unrelated user work. Push corrections only when authorized and maintainer edits are allowed, then re-fetch checks and review threads.\n\n## Approve and merge\n\nApproval and merge require explicit user intent. That intent may come from the\ncurrent request, preserved session context, or a persisted automation prompt that clearly grants\napprove-and-merge authority. Immediately before approval, or before a merge\nthat does not require a new approval, confirm:\n\n- The latest head contains only the legitimate Wall change.\n- The final full-branch local review required by `AGENTS.md` is clear for the current head and authoritative base.\n- `ASC_BYPASS_KEYCHAIN=1 make check-wall-of-apps` and required GitHub checks pass.\n- No actionable unresolved review thread remains.\n- The PR is mergeable against current `main`.\n\nAn authorized approval may itself satisfy a required-review rule. After\nsubmitting any approval and immediately before merging, re-fetch the exact head,\nrequired reviews, review threads, required checks, and mergeability. Require all\nrequired reviews to be satisfied at that point.\n\nDo not wait for advisory or otherwise non-required CI jobs after these gates pass. A pending non-required job does not make the exact-head evidence stale.\n\nWrite the approval body as a short personalized welcome: name the app, state the validation evidence in one clause (App Store, TestFlight, or linked-project verification as applicable, plus the wall checks), and welcome it to the wall with one app-relevant closing line or emoji. Keep it to one or two sentences and make it specific to what the app does; do not paste a generic template verbatim across a batch. When the user explicitly requests a no-comment approval, submit one app-relevant emoji as the entire approval body instead. Do not add separate summary comments beyond the approval; reply to review threads only when an actionable thread needs an explanation. Merge one PR at a time with a regular merge commit that preserves the PR commits, pinning the audited head, for example `gh pr merge <number> --merge --match-head-commit <sha>`. Do not squash unless the user explicitly requests squash for that PR.\n\nAfter each merge, confirm the resulting commit and entry reached `origin/main`. When the user asks whether the app appears on the live Wall, verify the rendered `asccli.sh` page separately; source presence is not deployment proof, and advisory CI is not a reason to delay the live check.\n\n## Automation contract\n\nA standalone automation needs explicit persisted approve-and-merge authority. Apply the gates above to each PR sequentially, including fresh remote checks before acting and after approval. Reuse local validation only while its inputs remain valid under `AGENTS.md`.\n\nIf authority is absent or any gate is uncertain, failing, suspicious, unrelated,\nor stale, remain read-only and report `safe`, `needs-fix`, `suspicious`, or\n`blocked` with evidence. Persisted task authority may cover later passes, but a changed head requires fresh validation; an earlier approval is not proof that the new head passes the gates.\n\n## Hand off\n\nList each app, what it does, files changed, metadata evidence, validation result, review action, merge result, and any suspicious or unresolved state.\n","frontmatter":{"name":"review-wall-of-apps-prs","description":"Audit maintainer-side Wall of Apps pull requests in App-Store-Connect-CLI. Use when the user asks to review new app submissions, check Wall PRs for injected or unrelated changes, validate app metadata, approve with a personalized welcome, or merge legitimate Wall entries."},"isInternal":false,"tokens":1080,"sizeBytes":5313},{"name":"openai.yaml","path":".agents/skills/sync-asc-skills/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/sync-asc-skills/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n  display_name: \"Sync ASC Skills\"\n  short_description: \"Audit ASC workflow skills for CLI surface drift\"\n  default_prompt: \"Use $sync-asc-skills to compare ASC workflow skills with the current CLI and report proven drift.\"\n","isInternal":false,"tokens":51,"sizeBytes":234},{"name":"SKILL.md","path":".agents/skills/sync-asc-skills/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/sync-asc-skills/SKILL.md","title":"sync-asc-skills","category":"anthropic-skill","format":"markdown","content":"---\nname: sync-asc-skills\ndescription: Check rorkai/app-store-connect-cli-skills against the current ASC CLI surface and correct proven drift when authorized. Use for skill-drift questions, post-release syncs, or checks of command, flag, output, auth, and workflow examples.\n---\n\n# Synchronize ASC workflow skills\n\nDrift questions produce a read-only report; update requests authorize proven corrections. Follow `AGENTS.md` for commit, push, and PR-creation authority.\n\n## Establish both sources\n\n1. Resolve the current App-Store-Connect-CLI source commit and latest released version relevant to the request.\n2. Resolve a clean checkout of `rorkai/app-store-connect-cli-skills` and read its repository guidance.\n3. Inventory every skill and identify which commands, flags, environment variables, outputs, or workflows it claims to use.\n4. Run the current CLI's `--help` at each relevant command path. Use `asc search`, `asc schema`, or `asc capabilities` only when their own current help confirms they are appropriate.\n\nFollow `AGENTS.md` for parallel reads and serialized writes. Validate mutation-capable examples with help and schemas first; execution and cleanup require authority, and dry runs must be side-effect-free.\n\n## Prove drift\n\nCheck for:\n\n- Renamed, moved, deprecated, or removed commands.\n- Added, removed, or changed flags and accepted values.\n- Incorrect long-form examples, pagination, output, confirmation, or pretty-print behavior.\n- Auth, environment-variable, timeout, and default-output changes.\n- Workflow ordering changes that affect builds, TestFlight, metadata, review, signing, or release operations.\n- Examples that parse but no longer perform the claimed workflow.\n\nDo not update skills merely because a newer CLI version exists. Record exact help or runtime evidence for every edit.\n\n## Update minimally\n\n1. Change only affected skills and examples; avoid release-number churn and speculative prose.\n2. Keep each `SKILL.md` concise and move lengthy reference material behind progressive disclosure.\n3. Preserve the skills repository's naming, metadata, validation, and style conventions.\n4. Validate every changed command example against current built or released `asc` help and the relevant schema. Exercise runtime behavior when safe and authorized; report any path not executed.\n5. Run the skills repository's validators and the current skill-creator validator when available.\n6. When PR creation is authorized, open a separate draft PR in the skills repository with the CLI commit or release used as evidence and a summary of validation and unexecuted paths.\n\nNever modify the CLI merely to make stale skill documentation pass.\n\n## Automation contract\n\nA weekly or post-release automation may run a read-only drift audit and report proven mismatches. It may open a draft PR only when the automation has explicit write authorization and every change is deterministic; otherwise leave a precise change plan.\n\n## Hand off\n\nReport the CLI version and commit, skills commit, drift found, files changed, commands verified, validators run, PR URL, and any workflow that could not be tested safely.\n","frontmatter":{"name":"sync-asc-skills","description":"Check rorkai/app-store-connect-cli-skills against the current ASC CLI surface and correct proven drift when authorized. Use for skill-drift questions, post-release syncs, or checks of command, flag, output, auth, and workflow examples."},"isInternal":false,"tokens":624,"sizeBytes":3127},{"name":"openai.yaml","path":".agents/skills/triage-asc-issue/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/triage-asc-issue/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n  display_name: \"Triage ASC Issue\"\n  short_description: \"Reproduce, classify, and scope an ASC CLI issue\"\n  default_prompt: \"Use $triage-asc-issue to triage this ASC CLI issue against the code and API.\"\n","isInternal":false,"tokens":54,"sizeBytes":214},{"name":"SKILL.md","path":".agents/skills/triage-asc-issue/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/triage-asc-issue/SKILL.md","title":"triage-asc-issue","category":"anthropic-skill","format":"markdown","content":"---\nname: triage-asc-issue\ndescription: Triage App-Store-Connect-CLI GitHub issues against current code, CLI behavior, and App Store Connect API support. Use when the user asks to audit, reproduce, classify, label, scope, prioritize, or decide whether an ASC CLI issue should be fixed or implemented.\n---\n\n# Triage an ASC CLI issue\n\nProduce a current, evidence-backed verdict and proposed repository labels. Apply label changes only when authorized under `AGENTS.md`; a read-only triage ends with recommendations.\n\n## Read current evidence\n\n1. Fetch the live issue body, comments, labels, linked PRs, and referenced documentation.\n2. Resolve the affected command through current `--help`, source, tests, and recent history. Do not infer support from an old command name.\n3. Reproduce reported behavior with the current built or installed CLI when safe.\n4. For API claims, verify the exact method and endpoint in `docs/openapi/latest.json`; use the `sosumi.ai` documentation mirror for explanatory context.\n5. Check whether the report is already fixed on current `origin/main`, duplicated, unsupported by the public API, or blocked by Apple/platform behavior.\n\nFollow `AGENTS.md` for parallel reads and serialized writes. Live reproductions require authority for mutations and cleanup, even on disposable resources; confirm dry runs are side-effect-free.\n\n## Classify the outcome\n\nChoose one primary verdict:\n\n- Confirmed bug with a reproducible expected-versus-actual mismatch.\n- Valid enhancement with a supported and coherent API or client-side design.\n- Question requiring clarification or support guidance.\n- Already fixed, duplicate, not reproducible, unsupported, or platform-limited.\n\nSeparate urgency from implementation size. Explain user impact, blast radius, workaround, compatibility risk, and the smallest proof needed for completion.\n\n## Recommend or apply labels\n\nRecommend one type, priority, and difficulty from `AGENTS.md`'s buckets using the meanings in `CONTRIBUTING.md`. Apply them only when authorized.\n\nFor authorized label updates, remove conflicting labels and add the selected replacements, then verify the resulting buckets. If evidence is incomplete, mark the recommendation provisional and identify the missing evidence; uncertainty alone does not establish low urgency or easy implementation.\n\n## Define implementation readiness\n\nWhen the issue is actionable, provide:\n\n1. Proposed command and UX shape.\n2. API endpoint or explicit client-side behavior.\n3. Files and shared surfaces likely affected.\n4. RED-GREEN test plan and black-box exit/output cases.\n5. Safe live verification and cleanup plan.\n6. Compatibility or deprecation requirements.\n\nIf implementation is requested, continue with `$develop-asc-change` in an isolated branch or worktree. Report the requested implementation and validation as complete when finished, with PR and merge gates separately. Do not close the issue or claim it resolved until merged and verified; closure still requires authority.\n\n## Automation contract\n\nA recurring issue-triage automation may classify new or incompletely labeled issues and report actionable findings. Apply labels or post comments only within its persisted write authority. It must not implement code or close issues without explicit authorization, and labels must follow evidence.\n","frontmatter":{"name":"triage-asc-issue","description":"Triage App-Store-Connect-CLI GitHub issues against current code, CLI behavior, and App Store Connect API support. Use when the user asks to audit, reproduce, classify, label, scope, prioritize, or decide whether an ASC CLI issue should be fixed or implemented."},"isInternal":false,"tokens":641,"sizeBytes":3321},{"name":"openai.yaml","path":".agents/skills/watch-asc-pr/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/watch-asc-pr/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"interface:\n  display_name: \"Watch ASC Pull Request\"\n  short_description: \"Recheck ASC PR feedback, checks, and readiness\"\n  default_prompt: \"Use $watch-asc-pr to check this ASC CLI pull request for new actionable feedback.\"\n","isInternal":false,"tokens":51,"sizeBytes":224},{"name":"SKILL.md","path":".agents/skills/watch-asc-pr/SKILL.md","rawUrl":"https://raw.githubusercontent.com/rorkai/App-Store-Connect-CLI/HEAD/.agents/skills/watch-asc-pr/SKILL.md","title":"watch-asc-pr","category":"anthropic-skill","format":"markdown","content":"---\nname: watch-asc-pr\ndescription: Recheck an in-progress App-Store-Connect-CLI pull request for new review feedback, CI results, head changes, and merge readiness. Use when the user says to check for new PR comments, continue polling, fix and loop, babysit a PR, or keep working until the PR is clean.\n---\n\n# Watch an ASC CLI pull request\n\nPreserve the PR context and authority under `AGENTS.md`: status reads once; watch repeats until a terminal state; fix-and-watch also applies authorized fixes. Watching alone grants no edit, commit, push, or reply authority. A one-time check ends after reporting its snapshot; do not start a full readiness audit or heartbeat unless requested or already authorized.\n\n## Recheck current state\n\n1. Resolve the exact PR and compare its current head SHA with the last audited or pushed SHA.\n2. Fetch checks, reviews, top-level comments, and GraphQL review threads in parallel where possible. Separate required checks from advisory jobs.\n3. Separate new actionable feedback from resolved, outdated, informational, duplicate, or bot-noise comments.\n4. If the head changed outside this workflow, inspect the new diff before relying on prior conclusions.\n5. If `main` advanced, refresh the merge-base diff and mergeability; follow the branch-update rules in `AGENTS.md`.\n\n## Address actionable feedback\n\nApply fixes and external writes only when authorized. Otherwise report the verified finding and proposed fix; if it prevents progress, return `blocked` with the exact missing authority.\n\n1. Verify new claims against code, API schemas, and existing behavior.\n2. Reproduce a valid defect and add or update a focused test before changing behavior.\n3. Implement the smallest coherent fix, run the affected checks and required local review, then commit and push when authorized. Complete the final full-branch review loop in `AGENTS.md` before returning `clean`.\n4. When review communication is authorized, reply to and resolve only the threads fully addressed by that push.\n5. Re-fetch the PR after pushing and confirm the live head, checks, and thread state.\n6. Continue from the fresh head while required checks or reviews remain pending; apply new authorized fixes in additive commits.\n\n## Return one state\n\n- `observed`: a one-time check completed; report the requested facts and mark readiness unverified unless separately established. An actionable finding does not make a completed read-only check blocked.\n- `changed`: pushed a fix; include commit and validation.\n- `pending`: required checks, required reviews, or actionable reviews are still running; identify exactly what remains. This is an intermediate state during a user-requested loop, not the final handoff.\n- `clean`: the final full-branch local review in `AGENTS.md` is clear for the current head and base, required checks pass, required reviews are satisfied, the latest head is mergeable, and no actionable unresolved thread remains. Report advisory jobs without treating them as blockers.\n- `blocked`: user input, permissions, an external outage, or an unsafe product decision prevents progress.\n\nFor an authorized merge, reapply `$audit-asc-pr`'s complete gate immediately before merging and follow the history rules in `AGENTS.md`.\n\n## Automation contract\n\nWhen only an expected external state change remains in an authorized watch, save a checkpoint with the objective, PR, head and base SHAs, authority, validation results and inputs, unresolved feedback, last checked time, next step, stop condition, and retry history. Create or reuse one thread heartbeat, verify it, and end the turn. If scheduling is unavailable, report the pending state and checkpoint without implying that monitoring continues.\n\nOn each wake, inspect decisive state once. Reuse still-valid evidence, stay quiet when unchanged, and back off the next check. Resume work on completion, failure, or a stall. After an uncertain write, reconcile remote state before a bounded retry. Disable the heartbeat when the PR is clean, blocked, merged, closed, superseded, or awaiting a material user decision. Advisory jobs may remain pending after the clean gate passes. Do not create an unattended auto-merge loop.\n","frontmatter":{"name":"watch-asc-pr","description":"Recheck an in-progress App-Store-Connect-CLI pull request for new review feedback, CI results, head changes, and merge readiness. Use when the user says to check for new PR comments, continue polling, fix and loop, babysit a PR, or keep working until the PR is clean."},"isInternal":false,"tokens":844,"sizeBytes":4186}],"systemPromptSnippet":"<yakaai_skills repo=\"rorkai/App-Store-Connect-CLI\">\n<!-- File: AGENTS.md (Tokens: ~3211 | Category: root-instruction) -->\n# AGENTS.md\n\nUnofficial, fast, lightweight, agent-assisted, reviewer-owned CLI for the App Store Connect API. Built in Go with [ffcli](https://github.com/peterbourgon/ff).\n\n## Skills\n\nSkills for using `asc` in app workflows live at https://github.com/rorkai/app-store-connect-cli-skills.\n\nRepository-maintainer workflows live under `.agents/skills/`:\n\n- `$develop-asc-change`: design, implement, and verify commands, flags, endpoints, bug fixes, and behavior-changing refactors.\n- `$audit-asc-pr`: audit a complete PR and, when authorized, fix proven defects.\n- `$watch-asc-pr`: recheck PR comments, checks, head changes, and merge readiness.\n- `$triage-asc-issue`: reproduce, classify, label, and scope an issue.\n- `$review-wall-of-apps-prs`: validate, approve, and merge Wall of Apps submissions safely.\n- `$release-asc-cli`: publish and verify an end-to-end CLI repository release, including the release film and the announcement thread.\n- `$sync-asc-skills`: check the external ASC workflow skills for CLI-surface drift.\n\nUse these skills for their matching workflows instead of expanding this always-loaded file with task-specific procedures.\n\n## Authority and follow-through\n\n- Audits, reviews, research, triage, status checks, and composing draft text are read-only. Creating or updating a remote draft is an external write. Edits, commits, pushes, PR creation, comments, labels, approval, merge, publication, external sends, and deletion require authority from the request or session context. One request may authorize several actions; do not ask again for granted authority. Creating a PR for agreed changes includes the necessary edits, checks, commit, branch push, and PR creation, but not merge.\n- User instructions override skill guidelines within system and developer constraints; skill selection grants no authority. Make routine choices from repository conventions. Ask only about material scope, compatibility, or authority gaps, after preparing authorized work for review; continue independent work while awaiting answers.\n- If a skill causes a pause or scope change, link its `SKILL.md`, quote the instruction, and explain the unresolved decision. Preserve the objective, targets, authority, and verified progress across follow-ups and skill handoffs unless the user changes scope. Switching skills continues the current task; a failing gate blocks dependent actions, not independent authorized work. Inspect state before retrying an interrupted or uncertain write.\n\n## Core CLI contract\n\n- Use long-form flags in docs, tests, and examples (`--app`, `--output`).\n- Output defaults are TTY-aware: `table` in terminals and minified `json` for pipes or CI. Explicit `--output` wins.\n- Do not add interactive prompts. Require `--confirm` for destructive operations.\n- Use `--paginate` when callers request every page.\n- Write data to stdout and errors or diagnostics to stderr.\n- Never accept and silently ignore an unsupported flag or value.\n- JSON output shape is part of the command contract: reads of ASC collections/resources print Apple's envelope unmodified; mutation receipts and computed results use exported camelCase structs in internal/asc/output_*.go with a registered renderer; added fields are additive and removals follow the stability ladder.\n- Website changelog entries must omit Wall of Apps membership churn, including app additions, removals, renames, icon changes, and routine metadata refreshes. Document only significant user-facing changes to the Wall of Apps feature or contribution workflow.\n\n## Discover current behavior\n\nNever rely on memorized command shapes. Before implementing, testing, or documenting a command, inspect its current help:\n\n```bash\nasc --help\nasc builds --help\nasc builds list --help\n```\n\nFor App Store Connect API documentation, prefer the `sosumi.ai` mirror over `developer.apple.com`.\n\nUse the offline OpenAPI snapshot for endpoint and schema truth:\n\n- `docs/openapi/latest.json`: complete snapshot.\n- `docs/openapi/paths.txt`: quick endpoint index.\n- `docs/openapi/README.md`: update procedure.\n\nValidate attributes against the exact create or update request schema. Validate filters and includes against the specific endpoint; related top-level and relationship endpoints often differ.\n\n## Development workflow\n\n- Work on a branch and use an isolated worktree when the main checkout is dirty or other work is in progress.\n- Do not push directly to `main`, bypass hooks, use `--no-verify`, or skip checks to force a result.\n- Use TDD for behavior changes: reproduce or establish RED, implement the smallest coherent change, then reach GREEN.\n- **IMPORTANT:** Before ending every implementation session, run `/review`. In a non-interactive environment, use the stable local Codex CLI command `codex exec --ignore-user-config review --disable apps --disable plugins --disable remote_plugin -c 'model_provider=\"openai\"' -c 'model=\"gpt-5.6-sol\"' -c 'review_model=\"gpt-5.6-sol\"' --uncommitted` as a pre-commit review of working-tree changes.\n- Run reviews from the local worktree with the exact provider, model, config-isolation, and connector-disable flags shown. Immediately before each review, confirm `codex login status` shows ChatGPT authentication and both `CODEX_API_KEY` and `OPENAI_API_KEY` are unset or empty. Stop on API-key authentication or overrides unless explicitly authorized; these can incur separate usage charges.\n- Before calling a PR ready, refresh its authoritative base with `git fetch origin +refs/heads/<base-branch>:refs/remotes/origin/<base-branch>` and run `codex exec --ignore-user-config review --disable apps --disable plugins --disable remote_plugin -c 'model_provider=\"openai\"' -c 'model=\"gpt-5.6-sol\"' -c 'review_model=\"gpt-5.6-sol\"' --base origin/<base-branch>` on the final committed head so the complete branch or PR diff is reviewed against the current base. If the applicable review mechanism is unavailable, report the review gate as blocked and do not call the PR ready. Fix and verify every valid finding, and explicitly verify and disposition any false positive or non-actionable finding. After any change, rerun the applicable review command and repeat until it reports no actionable findings.\n- PR readiness requires a clear final full-branch `/review` and the GitHub gates below. Any subsequent diff change invalidates the review. An investigation may finish with findings or blocked gates without implying PR readiness.\n- Keep one logical change per commit.\n- Preserve additive PR history. Do not squash, rebase, force-push, or otherwise rewrite commits unless the user explicitly requests that strategy.\n- Re-run the focused failing test after each fix before broad validation.\n- Delegate substantive independent reads or focused validation with distinct ownership; verify conclusions centrally. Handle small or dependent work locally. Serialize edits, commits, pushes, review communication, approvals, merges, releases, and cleanup; agents must not concurrently edit shared branches or files.\n- Treat repository-wide commands that compile, lint, or test broad package sets—including `make build`, `make lint`, `make test`, `go test ./...`, race tests over `./...`, and `golangci-lint run ./...`—as host-intensive gates. Give each gate a CPU budget and keep the sum of running gate budgets within the host's logical CPU count, for example three gates with a budget of 3 on a 10-CPU host. When several agents share a host, run gates concurrently only through a slot mechanism the coordinating agent provides, such as a counting lock that reserves a slot atomically and releases it on exit, and wait for a free slot instead of competing for the same CPUs; without one, run one gate at a time. Run a change's final gates together in one slot instead of queuing for each. Never terminate another task's process without explicit authorization.\n- Within a worktree, wait for each focused test to finish before starting a broad gate. Record the checked commit, relevant working-tree state, command, and environment. Reuse passing checks while their inputs remain unchanged, including during status-only follow-ups. Rerun affected checks when source, test inputs, commands, environment, toolchain, or requested verification changes; unrelated temporary files do not invalidate results. Complete every required gate for the final change, and preserve the separate full-branch review requirement after any diff change.\n- Tool flags are limits within a gate's budget, not values to add together. Avoid multiplying Go package and in-binary concurrency: for a budget of `B`, use `GOMAXPROCS=1 go test -p=B -parallel=1 ./...` for package fan-out or `GOMAXPROCS=B go test -p=1 -parallel=B ./...` for one package at a time. Use `golangci-lint run --concurrency=B ./...` for a linter gate.\n\nUser-facing commands and flags are stable until deprecated or removed. Do not delete stable behavior directly. Deprecations require warning text, transition tests, migration guidance, and a release-note entry.\n\n## Implementation invariants\n\n- Put command implementations in `internal/cli/<domain>` and register new top-level commands in `internal/cli/registry/registry.go`.\n- Set `UsageFunc: shared.DefaultUsageFunc` on command groups and subcommands.\n- Use `shared.ContextWithTimeout` or `shared.ContextWithUploadTimeout` for outbound HTTP.\n- Read and write repository-controlled or API-supplied paths through `internal/rootfs`, anchored to the operator-selected root for that command, instead of plain `os` file operations.\n- Validate required flags before side effects and assert stderr messages in tests.\n- Use `internal/cli/cmdtest` for CLI-level coverage and `httptest` for HTTP payload coverage.\n- Remove shared wrappers or helpers made obsolete by a refactor.\n\n## Tests\n\nWrite a test only when it fails if behavior a user or caller depends on breaks, and no existing test already fails for that break. Name that regression before writing the test.\n\nWrite:\n\n- A regression test that fails before every bug fix and passes after it.\n- CLI contract tests: flag validation with its stderr text, exit codes, JSON output fields, and request wiring (method, path, query, body) through `httptest`.\n- Error, partial-failure, and cancellation paths.\n- Security invariants: rootfs anchoring, secret redaction, keychain and `HOME` isolation, credential handling.\n- Concurrency ordering and bounds, run under `-race`.\n\nDo not write tests that:\n\n- Restate the implementation: constants, defaults copied from code, fields the test just set, or a stub returning its input.\n- Exercise the standard library or a dependency, such as a JSON round-trip of a plain struct.\n- Only check for no panic, non-nil, `err == nil`, or `strings.Contains` on one word.\n- Copy another test per endpoint, command, or flag with only names or IDs changed. Add a row to the existing table instead of a sibling test.\n- Drive the same code path with the same or weaker assertions as an existing test.\n- Cover an unexported helper that its callers' tests already cover.\n- Lock incidental text: whitespace, help prose, or the order of unordered output.\n- Target code no production path runs, or always skip.\n\nAlso:\n\n- Do not use `time.Sleep` or real timeouts. Inject intervals, clocks, and retry delays.\n- Keep test code proportionate to the change. A small fix gets one small test.\n- Justify every new test in the PR body by naming the regression it catches.\n- Before removing a test, show which remaining test still fails for the same break.\n\n## Build and validation\n\nEvery manual test command must use `ASC_BYPASS_KEYCHAIN=1` to prevent host keychain prompts and profile bleed-through. The `make test` target enforces the same environment internally.\n\nBefore opening or merging a substantive behavior PR, run `make build`, `make format`, `make check-docs`, `make lint`, and `ASC_BYPASS_KEYCHAIN=1 make test`. If command help changed, run `make generate-command-docs` and commit `docs/COMMANDS.md` before those checks. For a narrowly scoped documentation or skill change, run `make check-docs`, which includes the repository and skill validators, instead of the full Go suite unless the changed surface or repository policy requires more. For a Wall-only PR, run `make check-wall-of-apps` on the exact head.\n\nRequire GitHub-required checks before merge. Report relevant advisory failures, but do not wait for non-required jobs.\n\nDo not weaken CI: formatting, documentation, lint, and tests must run on PR and `main` workflows.\n\n## GitHub and issue guardrails\n\n- Inspect thread-aware GitHub review state before declaring a PR clean; flat comments do not prove every thread is resolved.\n- A PR is ready only when the latest head was reviewed, required checks pass, required reviews are satisfied, actionable threads are resolved, and GitHub reports it mergeable.\n- If `main` advances, recheck the exact PR head, merge-base diff, duplicate or overlap risk, review threads, required checks, and mergeability against current `main` without changing the branch. Do not update, rebase, or merge `main` into a clean PR merely to refresh its base. Update a branch only when GitHub already reports an actual merge conflict, or when an explicitly authorized merge attempt made with every readiness gate passing is refused under strict up-to-date branch protection. Never bypass branch protection with an admin merge.\n- For loop or babysit requests, follow `$watch-asc-pr` until ready or materially blocked, preserving the authorized actions. Use its checkpoint and heartbeat procedure when only waiting remains.\n- When merge is explicitly authorized, preserve the PR commits with a regular merge commit, for example `gh pr merge <number> --merge --match-head-commit <sha>`. Do not squash unless the user explicitly requests squash for that PR.\n- For read-only triage, recommend exactly one type (`bug`, `enhancement`, `question`), one priority (`p0`-`p3`), and one difficulty (`easy`, `medium`, `hard`). When issue creation or label changes are authorized, apply exactly one label from each bucket and remove conflicting labels.\n\n## Authentication and live testing\n\nApp Store Connect API keys come from https://appstoreconnect.apple.com/access/integrations/api and must never be committed.\n\nTests touching auth must isolate relevant environment and config state. For live verification, prefer read-only calls. Live mutations require authorization, including on disposable app `6759231657`; a disposable target does not itself grant permission. Include temporary-resource cleanup in the authorized verification plan and record anything left behind. Never mutate a non-disposable app without explicit approval.\n\n## Handoff contract\n\nReport the outcome, decisive evidence, material unknowns, and next action concisely. Include design or command details only when useful. Distinguish source review, tests, remote checks, merge, release artifacts, and provider state. Report pre-existing failures and unverified acceptance criteria.\n\n## References\n\n- Go standards: `docs/GO_STANDARDS.md`\n- Testing patterns: `docs/TESTING.md`\n- Git workflow and CLI structure: `docs/CONTRIBUTING.md`\n- API quirks: `docs/API_NOTES.md`\n- Development setup, PRs, labels, and Wall submissions: `CONTRIBUTING.md`\n\n<!-- File: CLAUDE.md (Tokens: ~4 | Category: claude-rule) -->\n@Agents.md\n\n<!-- File: .agents/skills/audit-asc-pr/agents/openai.yaml (Tokens: ~49 | Category: anthropic-skill) -->\ninterface:\n  display_name: \"Audit ASC Pull Request\"\n  short_description: \"Review ASC CLI PRs and identify concrete defects\"\n  default_prompt: \"Use $audit-asc-pr to audit this ASC CLI pull request end to end.\"\n\n<!-- File: .agents/skills/audit-asc-pr/SKILL.md (Tokens: ~906 | Category: anthropic-skill) -->\n---\nname: audit-asc-pr\ndescription: Audit App-Store-Connect-CLI pull requests end to end and fix concrete defects when authorized. Use for PR review, value and blast-radius assessment, issue verification, or requested fixes before merge.\n---\n\n# Audit an ASC CLI pull request\n\nAudit the entire PR under the authority and review rules in `AGENTS.md`.\n\n## Establish the contract\n\n1. Read `AGENTS.md` and resolve the repository, PR number, base branch, head branch, and exact head SHA.\n2. Read the PR body, every commit, linked issues, current checks, reviews, and comments.\n3. Fetch thread-aware review state with GitHub GraphQL. Do not treat a flat comment list as proof that all review threads are resolved.\n4. State the behavior the PR claims to change and the evidence needed to prove it.\n\n## Isolate and inspect\n\n1. Use a dedicated worktree and local branch for the PR. Preserve the user's main checkout and unrelated worktrees.\n2. Inspect the full merge-base diff and all PR commits, not only the latest commit.\n3. Compare the implementation with the linked issue and current product behavior. Check architecture fit, compatibility, error paths, permissions, destructive operations, output contracts, and missing cleanup.\n4. Verify claims from bots or reviewers against code, schemas, and tests before editing.\n5. Flag added tests that do not meet the test rules in `AGENTS.md`, naming the rule each one breaks.\n6. Identify the blast radius: commands, shared helpers, API resources, output formats, auth modes, and release surfaces affected.\n\n## Verify behavior\n\n1. Run the relevant current `--help` paths before judging command shape.\n2. Build a binary when CLI behavior, flags, output, or exit codes changed. Exercise realistic invocations against the built binary.\n3. For API-facing changes, verify the exact endpoint and method in `docs/openapi/latest.json`, including create-versus-update attributes and endpoint-specific query parameters.\n4. Run focused tests first, then checks required by repository policy or proportional to the diff. Pending or unrelated advisory CI does not block the audit once required checks pass; report relevant advisory failures.\n5. Prefer read-only live App Store Connect verification. If live mutations and their cleanup are authorized, use the disposable app `6759231657` and record anything that could not be removed. Never mutate another app without explicit approval.\n6. Preserve uncertainty when live state cannot reproduce an edge case; use deterministic fixtures or tests instead of claiming success.\n\n## Fix forward\n\nFor authorized fixes:\n\n1. Reproduce each defect before changing code.\n2. Add or adjust a failing regression test, confirm the failure, implement the smallest coherent fix, and rerun the focused test.\n3. Add fixes as logical commits traceable to findings or review threads.\n4. Push to the PR head when permitted. If the contributor branch cannot accept maintainer pushes, report the exact limitation and prepare a separate fix PR only when authorized.\n5. When review communication is authorized, reply to and resolve only threads fully addressed by the pushed change.\n6. Re-fetch the head SHA, checks, reviews, and GraphQL threads after every push.\n\nDo not post a generic top-level audit summary unless the user asks. Put actionable findings in review threads when review communication is authorized.\n\n## Apply the merge gate\n\nDo not call the PR ready until all of the following are true:\n\n- The latest head was audited against current `main` under the branch-update rules in `AGENTS.md`.\n- The final committed head passed the full-branch local review loop required by `AGENTS.md` against the current authoritative base, with no subsequent diff change.\n- Relevant focused and GitHub-required checks pass. Non-required checks may still be pending.\n- No actionable unresolved review thread remains.\n- Required reviews are satisfied.\n- GitHub reports the PR mergeable without conflicts. Interpret `BLOCKED` or `UNSTABLE` through the required-check, required-review, and thread gates above; do not require a `CLEAN` merge state when only advisory jobs remain.\n- Live or deterministic verification supports the claimed behavior.\n\nFor requested follow-up monitoring, use `$watch-asc-pr`. Approve and merge only under the authority, history, and exact-head rules in `AGENTS.md`.\n\n## Hand off\n\nReport findings, evidence, remaining gates, and the merge recommendation. Include any fixes, pushes, live mutations, and cleanup.\n\n<!-- File: .agents/skills/develop-asc-change/agents/openai.yaml (Tokens: ~46 | Category: anthropic-skill) -->\ninterface:\n  display_name: \"Develop ASC Change\"\n  short_description: \"Design, implement, and verify ASC CLI changes\"\n  default_prompt: \"Use $develop-asc-change to implement this ASC CLI behavior change completely.\"\n\n<!-- File: .agents/skills/develop-asc-change/references/test-matrix.md (Tokens: ~491 | Category: anthropic-skill) -->\n# ASC CLI behavior test matrix\n\nApply the cases relevant to the changed behavior, under the test rules in `AGENTS.md`. Use existing coverage when it proves the contract. Add tests only for distinct observable behavior or demonstrated regressions; do not repeat shared parser and renderer coverage for each command.\n\n## Flags and parsing\n\n- Cover the valid path and one invalid value (stderr and exit code `2`) of a new or changed flag, unless an existing test already does. Add them as rows in an existing table when one exists.\n- When parsing or dispatch changes, cover affected flag ordering and values that look like subcommand names.\n- Assert required-flag errors on stderr; do not test only for `flag.ErrHelp`.\n- Never accept and silently ignore an unsupported flag or value.\n\n## Output and exit behavior\n\n- Parse JSON or XML and assert fields instead of relying only on substring matching.\n- Assert representative table or Markdown structure and headers.\n- Verify stdout, stderr, and exit code with a built binary for changed CLI behavior.\n- Test successful artifact/report writes and write failures.\n- Prevent duplicate usage or duplicate error output.\n\n## HTTP and API behavior\n\n- Use `httptest` to assert method, path, query, headers, and request body.\n- Cover a realistic non-empty response per response family. Test validation and API errors only where the endpoint handles them differently from the shared client.\n- Keep representative response-decoding assertions when consolidating table-driven tests.\n- Test pagination and empty responses where applicable.\n\n## Auth and process isolation\n\n- Run repository tests with `ASC_BYPASS_KEYCHAIN=1`.\n- Use `t.Setenv` and a temporary `ASC_CONFIG_PATH` for auth-sensitive tests.\n- Set or clear `ASC_PROFILE`, `ASC_KEY_ID`, `ASC_ISSUER_ID`, `ASC_PRIVATE_KEY_PATH`, `ASC_PRIVATE_KEY`, `ASC_PRIVATE_KEY_B64`, and `ASC_STRICT_AUTH` locally when relevant.\n- Restore exact process state when a test cannot use `t.Setenv`.\n- Allow `t.Skip` only for a specific documented and reproducible condition; never use a broad error-string skip.\n\n## Live verification\n\n- Prefer read-only calls first.\n- For authorized mutations and cleanup, use a disposable resource, record its ID, and delete or cancel it afterward.\n- Assert the externally visible result, not only a successful HTTP status.\n- Report any state that could not be cleaned up.\n\n<!-- File: .agents/skills/develop-asc-change/SKILL.md (Tokens: ~693 | Category: anthropic-skill) -->\n---\nname: develop-asc-change\ndescription: Design, implement, and verify behavior changes in App-Store-Connect-CLI. Use when adding or changing a command, flag, API endpoint, output format, exit code, shared CLI behavior, or when fixing or refactoring behavior that requires code and tests.\n---\n\n# Develop an ASC CLI change\n\nFollow `AGENTS.md` for authority, CLI contracts, implementation invariants, validation, and review gates.\n\n## Write the design note\n\nFor a small fix, record the reproduced failure, intended behavior, and focused check. For new public behavior or compatibility decisions, also record:\n\n1. Placement in the existing command taxonomy and registry.\n2. Current `--help` behavior and expected invocation shape.\n3. Exact OpenAPI endpoint, method, request schema, query parameters, and response shape when API-facing.\n4. Flags, output formats, stdout/stderr behavior, and exit codes.\n5. Compatibility, lifecycle, migration, and deprecation impact.\n6. RED-GREEN tests, black-box checks, live verification, edge cases, and failure modes.\n7. Credible alternatives when a material design trade-off exists.\n\n## Establish RED\n\n- For a bug, reproduce it first and add the smallest regression test that fails for the expected reason.\n- For a feature, start with CLI-level coverage of the changed observable contract; add unit or HTTP tests for distinct behavior that those tests do not cover.\n- For a behavior-changing refactor, use existing characterization coverage where sufficient and add coverage for missing behavior before moving code.\n- Run the focused test and record the expected failure before implementation.\n\nRead [references/test-matrix.md](references/test-matrix.md) for applicable CLI, output, artifact, and auth cases. Reuse sufficient existing coverage; do not duplicate shared parser or renderer tests for every command. Every new test must meet the test rules in `AGENTS.md`.\n\n## Validate API support\n\n1. Search `docs/openapi/paths.txt`, then inspect the exact operation in `docs/openapi/latest.json`.\n2. Apply the endpoint-specific schema checks in `AGENTS.md`.\n3. If the API cannot support the behavior, implement explicit client-side behavior or document the limitation; do not ship a misleading flag.\n\n## Implement narrowly\n\nApply `AGENTS.md`'s implementation invariants. Return usage errors with exit code `2`.\n\n## Reach GREEN and verify\n\n1. Rerun the focused failing test after each small fix.\n2. Run adjacent package and command tests.\n3. Build a binary at a worktree-specific path and verify realistic invocations, output streams, and exit codes. Do not share a fixed `/tmp/asc` path with concurrent tasks.\n4. Run a minimal live smoke test when behavior depends on App Store Connect quirks. Prefer read-only calls; live mutations and cleanup require authority under `AGENTS.md`.\n5. Apply `AGENTS.md`'s validation gate, including command-doc generation when help changes. Public CLI behavior, shared code, release surfaces, and meaningful defect or security fixes require the full gate.\n\nBefore handoff, compare the exact branch head with current `main` read-only. Follow the branch-update rules in `AGENTS.md`; a newer base alone does not justify changing the branch.\n\n## Hand off\n\nUse `AGENTS.md`'s handoff contract; include invocation and compatibility details for public-contract changes.\n\n<!-- File: .agents/skills/release-asc-cli/agents/openai.yaml (Tokens: ~46 | Category: anthropic-skill) -->\ninterface:\n  display_name: \"Release ASC CLI\"\n  short_description: \"Publish and verify an ASC CLI repository release\"\n  default_prompt: \"Use $release-asc-cli to publish and verify the requested ASC CLI release.\"\n\n<!-- File: .agents/skills/release-asc-cli/references/release-announcement.md (Tokens: ~820 | Category: anthropic-skill) -->\n# Release announcement\n\nEvery release gets a short film and a thread. The thread reuses the same posts on X, Threads, Bluesky, and Mastodon; LinkedIn stays off.\n\n## Render the release film\n\nThe films live in the private `rudrankriyam/asc-motion` repository (locally `~/Developer/CLIs/asc-motion`, Remotion with bun). If that checkout is unavailable, skip the film, say so in the handoff, and post the thread without it.\n\n1. From the repository root run `./new-release-film.sh NNNN-asc-X-Y X.Y.Z`, where `NNNN` is the next free folder number.\n2. Edit only `NNNN-asc-X-Y/src/content.ts`. Take three or four headline features from the website changelog entry for the version, each with one exact command from the matching guide. Never invent a flag; check every command against `asc <command> --help`. Put the remaining notable changes in the `FIXES` list, one line each under 60 characters.\n3. Inside the folder run `bun install && bun run render`. The music bed is synthesised on every render; nothing licensed is involved.\n4. Render one still per beat with `bunx remotion still AscRelease --frame N out/<beat>.png` and look at each one. Captions must stay clear of the `>_` mark and commands must finish typing before the beat ends; shorten the caption or command if not.\n5. Commit the folder on a branch named `release-film-X-Y` in `asc-motion` and open a pull request there. Merge only when the user asks.\n\nDo not reuse the Rork motion kit grammar (cursor, gradient pill, camera moves, click sounds, grain). The film is typographic: version, product name, orange rule, typed commands.\n\n## Thread format\n\nPost 1 carries the film and nothing else that the film already types:\n\n```\nApp Store Connect CLI X.Y.Z\n\n<one line naming the three or four headline features>\n\nhttps://github.com/rorkai/App-Store-Connect-CLI\n```\n\nNo sign-off line after the feature line, no emojis, no teaser such as \"every change is in the thread below\".\n\nThen one post per change in the changelog, with its command inline as plain text (no backticks). Keep every post under Bluesky's 300-character limit so the thread is identical on all four platforms.\n\nThe last post is only:\n\n```\nFull changelog:\n\nhttps://asccli.sh/changelog\n```\n\n## Typefully workflow\n\nUse this section only when an external draft is authorized. Otherwise include the finished posts in the local handoff without creating a remote draft.\n\n1. Only when a film was rendered: request a media upload for the `.mp4` with alt text that names the version and the beats. Upload the file to the returned presigned URL with `curl -T <file> \"<upload_url>\"` and no `Content-Type` header; adding one invalidates the signature. Poll the media status until it is `ready`. Without a film, skip this step and post 1 goes out as text.\n2. If an older unpublished draft for the same version exists, rewrite it in place with the thread above instead of creating a second draft. Published drafts cannot be edited through the API, so leave those alone. Do not delete any draft unless the request explicitly authorizes that; report leftover duplicates instead.\n3. Resolve the user's social set, enable X, Threads, Bluesky, and Mastodon, disable LinkedIn, attach the media ID (if any) to post 1 on every enabled platform, and save as an unscheduled draft only.\n4. Verify the returned state is `draft` and return its review URL.\n\nIf the Typefully connector is unavailable, preserve the finished posts in the handoff and report the external draft as incomplete, separately from artifact and distribution verification. Never silently publish through another tool.\n\n<!-- File: .agents/skills/release-asc-cli/SKILL.md (Tokens: ~1994 | Category: anthropic-skill) -->\n---\nname: release-asc-cli\ndescription: Publish and verify a new release of the App-Store-Connect-CLI repository. Use only when the user explicitly asks to release, tag, or publish a specific ASC CLI version, including the full GitHub release, artifact, Homebrew, WinGet, cleanup, and release-announcement workflow.\n---\n\n# Release the ASC CLI\n\n## Prove the release target\n\n1. Resolve the requested plain semantic version without a `v` prefix.\n2. Fetch `origin` and inspect the requested tag locally and remotely, any release, and its workflow runs before acting. For a new release, require the tag to be absent and inspect the release-worthy delta since the previous tag. When resuming, verify that the existing tag points to the previously approved release commit and resume only unfinished work; stop on a target mismatch.\n3. Query open PRs and confirm the intended changes are already merged.\n4. For a new release, create a clean detached worktree from the exact current `origin/main` commit. When resuming, use the tag's previously approved, verified release commit. Do not release from a dirty user checkout or an unmerged branch.\n5. Inspect `.github/workflows/release.yml` and current repository guidance instead of assuming an older release procedure still applies.\n\n## Run the release gate\n\nFor a new release, run and record the following checks. On resume, reuse completed checks only while their inputs remain valid under `AGENTS.md`; verify consumer-visible state freshly.\n\n```bash\nmake format\nmake check-docs\nmake check-wall-of-apps\nmake lint\nASC_BYPASS_KEYCHAIN=1 make test\nmake build\n./asc version\n```\n\nIf formatting changes files, inspect the diff and stop the release gate. Prepare necessary corrections on a branch only when authorized; they must pass repository review and validation and merge through the normal PR process before restarting from the updated `origin/main`. Never tag a correction committed only in the detached release worktree. Stop on unexplained failures; do not tag around a broken gate.\n\n## Publish\n\n1. For a new release, refresh `origin/main` and reconfirm the worktree HEAD equals the intended current `origin/main` commit. If `origin/main` advanced, inspect the delta and restart target selection and the release gate in a clean detached worktree at the newly selected commit before tagging. Checks run in the old worktree do not validate the new commit.\n2. Create an annotated tag using the exact requested version and push that tag explicitly. On resume, reuse the verified existing tag: skip the push if the remote tag already matches; if only the local tag exists, push it only within the established release authority. Never replace a mismatched remote tag.\n3. Locate the tag-triggered GitHub Actions run and watch it through completion.\n4. Do not retry by silently moving or recreating a published tag. Diagnose failures and preserve the immutable release history.\n\n## Verify consumer-visible state\n\nVerify:\n\n- The GitHub release is published, not draft or prerelease unless requested.\n- Expected macOS, Linux, Windows, and checksum assets exist.\n- A downloaded macOS binary reports the requested version and passes `codesign --verify`.\n- Downloaded artifact hashes match the published checksum file.\n- The Homebrew formula points to the new version and hashes.\n- The expected WinGet submission or PR exists and references the new version.\n- Any notarization step required by the current workflow succeeded.\n\nIf the `winget` job failed, inspect its rate-limit preflight, retry history, and current submission state first. For a transient failure, prefer one rerun of the failed job before manual repair; dispatch the full workflow only after confirming it will safely reuse the existing release. Wait for the logged reset time only when the primary quota bucket is zero; back off a few minutes for secondary throttles, 5xx responses, or transport failures. After a failed retry or a non-transient error, report the exact blocker instead of looping. See `docs/WINGET.md`.\n\n## Update the website changelog\n\nAfter every published release, prepare the changelog update for the root `CHANGELOG.md` in [rorkai/asc-website](https://github.com/rorkai/asc-website). It is the single source for [asccli.sh/changelog](https://asccli.sh/changelog); keep all release history in that file, without separate archives or a second CLI-repository changelog. Apply it to the website checkout when website edits are authorized by the request or session. Otherwise draft the entry text in the release handoff and report the website update as pending; do not modify the website checkout.\n\n1. Build the release inventory from the previous published tag through the released tag, using GitHub release notes, merged PRs, and tagged source. Include only changes shipped in that release. Verify command names, flags, and migration replacements against the released binary's help or tagged source, not a newer checkout.\n2. With website-edit authority, locate the website checkout by its remote and follow its `AGENTS.md`. Work from current website `origin/main` in an isolated worktree when needed. Inspect an existing entry or pending changelog PR before resuming so the same release is not added twice.\n3. Add the version under its UTC publication month, newest first, using the GitHub release publication date. Preserve older entries and update the month navigation when a new month begins.\n4. Write the entry using the rules and examples below. Keep one release link and one previous-tag comparison link at the end, with migration-guide links where relevant.\n5. Run the website's `pnpm run lint` and `pnpm build`, plus `git diff --check`. Verify the new entry renders, month links work, prior releases remain, and no inline PR references were introduced. Require session authority explicitly covering each website write: PR creation, merge, and deployment. A CLI release request alone does not grant those permissions. If a later website write is not authorized, retain the authorized edits and report that pending step separately from the binary release.\n\n### Changelog writing rules\n\n- Use short, flat bullets under `New features`, `Improvements and fixes`, and `Breaking changes` as applicable; omit empty sections. Split unrelated changes into separate bullets and use domain subheadings for large releases.\n- Describe the concrete behavior and its user impact, usually in one or two sentences. Keep important features, fixes, limitations, confirmation requirements, output or exit-code changes, and actionable migration replacements.\n- Omit PR numbers, inline PR links, commit hashes, introductory paragraphs, and generic claims such as “improved reliability.” PRs are evidence for writing the notes, not visible labels in the notes.\n- Cover significant shipped changes individually. Group routine dependency, CI, and test updates where appropriate; the release and comparison links retain the complete source history.\n- Omit Wall of Apps membership churn, including app additions, removals, renames, icon changes, and routine metadata refreshes. Include only significant user-facing changes to the Wall of Apps feature or contribution workflow.\n- Use backticks for commands, flags, environment variables, and JSON. Do not invent detail to expand a short entry or remove compatibility details merely to shorten a bullet.\n\nExample entry from the published 5.1.0 release (illustrative excerpt, not its complete notes):\n\n```markdown\n### 5.1.0 (2026-09-08)\n\n#### New features\n\n- `asc web api-keys list` accepts `--session-from-env` for CI reads.\n- `--session-from-env` reads `ASC_WEB_SESSION` in memory without changing the session cache or keychain.\n\n#### Improvements and fixes\n\n- Review-draft creation stops before writing when a successful preflight response omits `data`.\n\n[Release](https://github.com/rorkai/App-Store-Connect-CLI/releases/tag/5.1.0) · [Compare changes](https://github.com/rorkai/App-Store-Connect-CLI/compare/5.0.0...5.1.0)\n```\n\nMigration wording should name the replacement, for example: “App-scoped `--build-number` queries require `--platform` instead of assuming `IOS`.” Keep this behavior in its 5.0.0 entry; do not present historical examples as new changes in the next release.\n\n## Draft the announcement\n\nRead [references/release-announcement.md](references/release-announcement.md) after the release is visibly published and the website changelog entry exists. Render the release film from the `asc-motion` template, then prepare the announcement thread. Create an external Typefully draft only when the request or established context authorizes that write; otherwise return the copy locally. Never schedule or publish the post unless the user explicitly asks.\n\n## Clean up and hand off\n\nRemove only a clean temporary release worktree created by this run as part of its authorized cleanup; preserve unexpected changes. Report the released commit and tag, release URL, artifact verification, Homebrew and WinGet state, remaining blockers, website changelog state (edited, PR opened, merged, or live), and announcement status separately. An optional external draft does not prevent reporting a verified binary release.\n\n## Automation boundary\n\nDo not schedule unattended releases. After an explicitly initiated tag push, a thread heartbeat may watch the release run and finish authorized downstream verification. Save the version, immutable commit and tag, run IDs, completed checks, authority, next step, and retry history; create or reuse one heartbeat and end the turn. On wake, reconcile current state once, stay quiet and back off when unchanged, and disable the heartbeat on completion or a blocker requiring user action. Never use a heartbeat to recreate or move the tag.\n\n<!-- File: .agents/skills/review-wall-of-apps-prs/agents/openai.yaml (Tokens: ~53 | Category: anthropic-skill) -->\ninterface:\n  display_name: \"Review Wall of Apps PRs\"\n  short_description: \"Validate and safely review Wall of Apps PRs\"\n  default_prompt: \"Use $review-wall-of-apps-prs to audit the open Wall of Apps pull requests.\"\n\n<!-- File: .agents/skills/review-wall-of-apps-prs/SKILL.md (Tokens: ~1080 | Category: anthropic-skill) -->\n---\nname: review-wall-of-apps-prs\ndescription: Audit maintainer-side Wall of Apps pull requests in App-Store-Connect-CLI. Use when the user asks to review new app submissions, check Wall PRs for injected or unrelated changes, validate app metadata, approve with a personalized welcome, or merge legitimate Wall entries.\n---\n\n# Review Wall of Apps pull requests\n\nTreat submissions as untrusted. Follow `AGENTS.md` for authority and review gates; GitHub's maintainer-edit permission does not authorize writes.\n\n## Discover and classify\n\n1. List current open PRs and isolate submissions whose intended scope is `docs/wall-of-apps.json`.\n2. Inspect each PR's full file list and diff before checkout. Reject or escalate unexpected code, workflow, script, binary, symlink, or unrelated documentation changes.\n3. Review each PR independently and merge sequentially. Recheck later PRs against updated `main` after each merge.\n4. Apply `AGENTS.md`'s branch-update rules. `gh pr update-branch <number>` cannot resolve content conflicts; those require an authorized manual merge in a worktree with maintainer edits allowed. After any update, revalidate the new head through every gate below.\n\n## Validate the entry\n\nFor every added or changed app:\n\n1. Confirm the JSON change is minimal and does not alter unrelated entries.\n2. Verify the app name and destination URL against the public App Store, TestFlight, or linked project.\n3. Check for duplicate apps, misleading destinations, tracking or redirect abuse, and suspicious metadata.\n4. Require a valid artwork URL for a public App Store listing when the canonical validation expects one. Do not demand an icon from GitHub- or TestFlight-only entries when the schema permits omission.\n5. Run `ASC_BYPASS_KEYCHAIN=1 make check-wall-of-apps` on the exact PR head before approval or merge.\n6. Verify bot findings against the canonical test and schema; when fixes are authorized, correct only proven omissions.\n\nUse an isolated checkout when needed to validate the exact head or apply authorized fixes, preserving unrelated user work. Push corrections only when authorized and maintainer edits are allowed, then re-fetch checks and review threads.\n\n## Approve and merge\n\nApproval and merge require explicit user intent. That intent may come from the\ncurrent request, preserved session context, or a persisted automation prompt that clearly grants\napprove-and-merge authority. Immediately before approval, or before a merge\nthat does not require a new approval, confirm:\n\n- The latest head contains only the legitimate Wall change.\n- The final full-branch local review required by `AGENTS.md` is clear for the current head and authoritative base.\n- `ASC_BYPASS_KEYCHAIN=1 make check-wall-of-apps` and required GitHub checks pass.\n- No actionable unresolved review thread remains.\n- The PR is mergeable against current `main`.\n\nAn authorized approval may itself satisfy a required-review rule. After\nsubmitting any approval and immediately before merging, re-fetch the exact head,\nrequired reviews, review threads, required checks, and mergeability. Require all\nrequired reviews to be satisfied at that point.\n\nDo not wait for advisory or otherwise non-required CI jobs after these gates pass. A pending non-required job does not make the exact-head evidence stale.\n\nWrite the approval body as a short personalized welcome: name the app, state the validation evidence in one clause (App Store, TestFlight, or linked-project verification as applicable, plus the wall checks), and welcome it to the wall with one app-relevant closing line or emoji. Keep it to one or two sentences and make it specific to what the app does; do not paste a generic template verbatim across a batch. When the user explicitly requests a no-comment approval, submit one app-relevant emoji as the entire approval body instead. Do not add separate summary comments beyond the approval; reply to review threads only when an actionable thread needs an explanation. Merge one PR at a time with a regular merge commit that preserves the PR commits, pinning the audited head, for example `gh pr merge <number> --merge --match-head-commit <sha>`. Do not squash unless the user explicitly requests squash for that PR.\n\nAfter each merge, confirm the resulting commit and entry reached `origin/main`. When the user asks whether the app appears on the live Wall, verify the rendered `asccli.sh` page separately; source presence is not deployment proof, and advisory CI is not a reason to delay the live check.\n\n## Automation contract\n\nA standalone automation needs explicit persisted approve-and-merge authority. Apply the gates above to each PR sequentially, including fresh remote checks before acting and after approval. Reuse local validation only while its inputs remain valid under `AGENTS.md`.\n\nIf authority is absent or any gate is uncertain, failing, suspicious, unrelated,\nor stale, remain read-only and report `safe`, `needs-fix`, `suspicious`, or\n`blocked` with evidence. Persisted task authority may cover later passes, but a changed head requires fresh validation; an earlier approval is not proof that the new head passes the gates.\n\n## Hand off\n\nList each app, what it does, files changed, metadata evidence, validation result, review action, merge result, and any suspicious or unresolved state.\n\n<!-- File: .agents/skills/sync-asc-skills/agents/openai.yaml (Tokens: ~51 | Category: anthropic-skill) -->\ninterface:\n  display_name: \"Sync ASC Skills\"\n  short_description: \"Audit ASC workflow skills for CLI surface drift\"\n  default_prompt: \"Use $sync-asc-skills to compare ASC workflow skills with the current CLI and report proven drift.\"\n\n<!-- File: .agents/skills/sync-asc-skills/SKILL.md (Tokens: ~624 | Category: anthropic-skill) -->\n---\nname: sync-asc-skills\ndescription: Check rorkai/app-store-connect-cli-skills against the current ASC CLI surface and correct proven drift when authorized. Use for skill-drift questions, post-release syncs, or checks of command, flag, output, auth, and workflow examples.\n---\n\n# Synchronize ASC workflow skills\n\nDrift questions produce a read-only report; update requests authorize proven corrections. Follow `AGENTS.md` for commit, push, and PR-creation authority.\n\n## Establish both sources\n\n1. Resolve the current App-Store-Connect-CLI source commit and latest released version relevant to the request.\n2. Resolve a clean checkout of `rorkai/app-store-connect-cli-skills` and read its repository guidance.\n3. Inventory every skill and identify which commands, flags, environment variables, outputs, or workflows it claims to use.\n4. Run the current CLI's `--help` at each relevant command path. Use `asc search`, `asc schema`, or `asc capabilities` only when their own current help confirms they are appropriate.\n\nFollow `AGENTS.md` for parallel reads and serialized writes. Validate mutation-capable examples with help and schemas first; execution and cleanup require authority, and dry runs must be side-effect-free.\n\n## Prove drift\n\nCheck for:\n\n- Renamed, moved, deprecated, or removed commands.\n- Added, removed, or changed flags and accepted values.\n- Incorrect long-form examples, pagination, output, confirmation, or pretty-print behavior.\n- Auth, environment-variable, timeout, and default-output changes.\n- Workflow ordering changes that affect builds, TestFlight, metadata, review, signing, or release operations.\n- Examples that parse but no longer perform the claimed workflow.\n\nDo not update skills merely because a newer CLI version exists. Record exact help or runtime evidence for every edit.\n\n## Update minimally\n\n1. Change only affected skills and examples; avoid release-number churn and speculative prose.\n2. Keep each `SKILL.md` concise and move lengthy reference material behind progressive disclosure.\n3. Preserve the skills repository's naming, metadata, validation, and style conventions.\n4. Validate every changed command example against current built or released `asc` help and the relevant schema. Exercise runtime behavior when safe and authorized; report any path not executed.\n5. Run the skills repository's validators and the current skill-creator validator when available.\n6. When PR creation is authorized, open a separate draft PR in the skills repository with the CLI commit or release used as evidence and a summary of validation and unexecuted paths.\n\nNever modify the CLI merely to make stale skill documentation pass.\n\n## Automation contract\n\nA weekly or post-release automation may run a read-only drift audit and report proven mismatches. It may open a draft PR only when the automation has explicit write authorization and every change is deterministic; otherwise leave a precise change plan.\n\n## Hand off\n\nReport the CLI version and commit, skills commit, drift found, files changed, commands verified, validators run, PR URL, and any workflow that could not be tested safely.\n\n<!-- File: .agents/skills/triage-asc-issue/agents/openai.yaml (Tokens: ~54 | Category: anthropic-skill) -->\ninterface:\n  display_name: \"Triage ASC Issue\"\n  short_description: \"Reproduce, classify, and scope an ASC CLI issue\"\n  default_prompt: \"Use $triage-asc-issue to triage this ASC CLI issue against the code and API.\"\n\n<!-- File: .agents/skills/triage-asc-issue/SKILL.md (Tokens: ~641 | Category: anthropic-skill) -->\n---\nname: triage-asc-issue\ndescription: Triage App-Store-Connect-CLI GitHub issues against current code, CLI behavior, and App Store Connect API support. Use when the user asks to audit, reproduce, classify, label, scope, prioritize, or decide whether an ASC CLI issue should be fixed or implemented.\n---\n\n# Triage an ASC CLI issue\n\nProduce a current, evidence-backed verdict and proposed repository labels. Apply label changes only when authorized under `AGENTS.md`; a read-only triage ends with recommendations.\n\n## Read current evidence\n\n1. Fetch the live issue body, comments, labels, linked PRs, and referenced documentation.\n2. Resolve the affected command through current `--help`, source, tests, and recent history. Do not infer support from an old command name.\n3. Reproduce reported behavior with the current built or installed CLI when safe.\n4. For API claims, verify the exact method and endpoint in `docs/openapi/latest.json`; use the `sosumi.ai` documentation mirror for explanatory context.\n5. Check whether the report is already fixed on current `origin/main`, duplicated, unsupported by the public API, or blocked by Apple/platform behavior.\n\nFollow `AGENTS.md` for parallel reads and serialized writes. Live reproductions require authority for mutations and cleanup, even on disposable resources; confirm dry runs are side-effect-free.\n\n## Classify the outcome\n\nChoose one primary verdict:\n\n- Confirmed bug with a reproducible expected-versus-actual mismatch.\n- Valid enhancement with a supported and coherent API or client-side design.\n- Question requiring clarification or support guidance.\n- Already fixed, duplicate, not reproducible, unsupported, or platform-limited.\n\nSeparate urgency from implementation size. Explain user impact, blast radius, workaround, compatibility risk, and the smallest proof needed for completion.\n\n## Recommend or apply labels\n\nRecommend one type, priority, and difficulty from `AGENTS.md`'s buckets using the meanings in `CONTRIBUTING.md`. Apply them only when authorized.\n\nFor authorized label updates, remove conflicting labels and add the selected replacements, then verify the resulting buckets. If evidence is incomplete, mark the recommendation provisional and identify the missing evidence; uncertainty alone does not establish low urgency or easy implementation.\n\n## Define implementation readiness\n\nWhen the issue is actionable, provide:\n\n1. Proposed command and UX shape.\n2. API endpoint or explicit client-side behavior.\n3. Files and shared surfaces likely affected.\n4. RED-GREEN test plan and black-box exit/output cases.\n5. Safe live verification and cleanup plan.\n6. Compatibility or deprecation requirements.\n\nIf implementation is requested, continue with `$develop-asc-change` in an isolated branch or worktree. Report the requested implementation and validation as complete when finished, with PR and merge gates separately. Do not close the issue or claim it resolved until merged and verified; closure still requires authority.\n\n## Automation contract\n\nA recurring issue-triage automation may classify new or incompletely labeled issues and report actionable findings. Apply labels or post comments only within its persisted write authority. It must not implement code or close issues without explicit authorization, and labels must follow evidence.\n\n<!-- File: .agents/skills/watch-asc-pr/agents/openai.yaml (Tokens: ~51 | Category: anthropic-skill) -->\ninterface:\n  display_name: \"Watch ASC Pull Request\"\n  short_description: \"Recheck ASC PR feedback, checks, and readiness\"\n  default_prompt: \"Use $watch-asc-pr to check this ASC CLI pull request for new actionable feedback.\"\n\n<!-- File: .agents/skills/watch-asc-pr/SKILL.md (Tokens: ~844 | Category: anthropic-skill) -->\n---\nname: watch-asc-pr\ndescription: Recheck an in-progress App-Store-Connect-CLI pull request for new review feedback, CI results, head changes, and merge readiness. Use when the user says to check for new PR comments, continue polling, fix and loop, babysit a PR, or keep working until the PR is clean.\n---\n\n# Watch an ASC CLI pull request\n\nPreserve the PR context and authority under `AGENTS.md`: status reads once; watch repeats until a terminal state; fix-and-watch also applies authorized fixes. Watching alone grants no edit, commit, push, or reply authority. A one-time check ends after reporting its snapshot; do not start a full readiness audit or heartbeat unless requested or already authorized.\n\n## Recheck current state\n\n1. Resolve the exact PR and compare its current head SHA with the last audited or pushed SHA.\n2. Fetch checks, reviews, top-level comments, and GraphQL review threads in parallel where possible. Separate required checks from advisory jobs.\n3. Separate new actionable feedback from resolved, outdated, informational, duplicate, or bot-noise comments.\n4. If the head changed outside this workflow, inspect the new diff before relying on prior conclusions.\n5. If `main` advanced, refresh the merge-base diff and mergeability; follow the branch-update rules in `AGENTS.md`.\n\n## Address actionable feedback\n\nApply fixes and external writes only when authorized. Otherwise report the verified finding and proposed fix; if it prevents progress, return `blocked` with the exact missing authority.\n\n1. Verify new claims against code, API schemas, and existing behavior.\n2. Reproduce a valid defect and add or update a focused test before changing behavior.\n3. Implement the smallest coherent fix, run the affected checks and required local review, then commit and push when authorized. Complete the final full-branch review loop in `AGENTS.md` before returning `clean`.\n4. When review communication is authorized, reply to and resolve only the threads fully addressed by that push.\n5. Re-fetch the PR after pushing and confirm the live head, checks, and thread state.\n6. Continue from the fresh head while required checks or reviews remain pending; apply new authorized fixes in additive commits.\n\n## Return one state\n\n- `observed`: a one-time check completed; report the requested facts and mark readiness unverified unless separately established. An actionable finding does not make a completed read-only check blocked.\n- `changed`: pushed a fix; include commit and validation.\n- `pending`: required checks, required reviews, or actionable reviews are still running; identify exactly what remains. This is an intermediate state during a user-requested loop, not the final handoff.\n- `clean`: the final full-branch local review in `AGENTS.md` is clear for the current head and base, required checks pass, required reviews are satisfied, the latest head is mergeable, and no actionable unresolved thread remains. Report advisory jobs without treating them as blockers.\n- `blocked`: user input, permissions, an external outage, or an unsafe product decision prevents progress.\n\nFor an authorized merge, reapply `$audit-asc-pr`'s complete gate immediately before merging and follow the history rules in `AGENTS.md`.\n\n## Automation contract\n\nWhen only an expected external state change remains in an authorized watch, save a checkpoint with the objective, PR, head and base SHAs, authority, validation results and inputs, unresolved feedback, last checked time, next step, stop condition, and retry history. Create or reuse one thread heartbeat, verify it, and end the turn. If scheduling is unavailable, report the pending state and checkpoint without implying that monitoring continues.\n\nOn each wake, inspect decisive state once. Reuse still-valid evidence, stay quiet when unchanged, and back off the next check. Resume work on completion, failure, or a stall. After an uncertain write, reconcile remote state before a bounded retry. Disable the heartbeat when the PR is clean, blocked, merged, closed, superseded, or awaiting a material user decision. Advisory jobs may remain pending after the clean gate passes. Do not create an unattended auto-merge loop.\n</yakaai_skills>"}