How do I install the Develop Asc Change skill?

Run npx skillmds@latest add rorkai/develop-asc-change in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Develop Asc Change safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Develop Asc Change?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Develop Asc Change free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Develop Asc Change?

rorkai (@rorkai) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Develop Asc Change by rorkai — Agent Skill

Name: Develop Asc Change
Author: rorkai

Develop Asc Change

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.

rorkai 5b6df94 3 files · 5.5 KB Updated Sep 17, 2026

File contents

Develop an ASC CLI change

Follow AGENTS.md for authority, CLI contracts, implementation invariants, validation, and review gates.

Write the design note

For a small fix, record the reproduced failure, intended behavior, and focused check. For new public behavior or compatibility decisions, also record:

Placement in the existing command taxonomy and registry.
Current --help behavior and expected invocation shape.
Exact OpenAPI endpoint, method, request schema, query parameters, and response shape when API-facing.
Flags, output formats, stdout/stderr behavior, and exit codes.
Compatibility, lifecycle, migration, and deprecation impact.
RED-GREEN tests, black-box checks, live verification, edge cases, and failure modes.
Credible alternatives when a material design trade-off exists.

Establish RED

For a bug, reproduce it first and add the smallest regression test that fails for the expected reason.
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.
For a behavior-changing refactor, use existing characterization coverage where sufficient and add coverage for missing behavior before moving code.
Run the focused test and record the expected failure before implementation.

Read 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.

Validate API support

Search docs/openapi/paths.txt, then inspect the exact operation in docs/openapi/latest.json.
Apply the endpoint-specific schema checks in AGENTS.md.
If the API cannot support the behavior, implement explicit client-side behavior or document the limitation; do not ship a misleading flag.

Implement narrowly

Apply AGENTS.md's implementation invariants. Return usage errors with exit code 2.

Reach GREEN and verify

Rerun the focused failing test after each small fix.
Run adjacent package and command tests.
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.
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.
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.

Before 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.

Hand off

Use AGENTS.md's handoff contract; include invocation and compatibility details for public-contract changes.

---name: develop-asc-changedescription: 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.---# Develop an ASC CLI changeFollow `AGENTS.md` for authority, CLI contracts, implementation invariants, validation, and review gates.## Write the design noteFor a small fix, record the reproduced failure, intended behavior, and focused check. For new public behavior or compatibility decisions, also record:1. Placement in the existing command taxonomy and registry.2. Current `--help` behavior and expected invocation shape.3. Exact OpenAPI endpoint, method, request schema, query parameters, and response shape when API-facing.4. Flags, output formats, stdout/stderr behavior, and exit codes.5. Compatibility, lifecycle, migration, and deprecation impact.6. RED-GREEN tests, black-box checks, live verification, edge cases, and failure modes.7. Credible alternatives when a material design trade-off exists.## Establish RED- For a bug, reproduce it first and add the smallest regression test that fails for the expected reason.- 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.- For a behavior-changing refactor, use existing characterization coverage where sufficient and add coverage for missing behavior before moving code.- Run the focused test and record the expected failure before implementation.Read [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.## Validate API support1. Search `docs/openapi/paths.txt`, then inspect the exact operation in `docs/openapi/latest.json`.2. Apply the endpoint-specific schema checks in `AGENTS.md`.3. If the API cannot support the behavior, implement explicit client-side behavior or document the limitation; do not ship a misleading flag.## Implement narrowlyApply `AGENTS.md`'s implementation invariants. Return usage errors with exit code `2`.## Reach GREEN and verify1. Rerun the focused failing test after each small fix.2. Run adjacent package and command tests.3. 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.4. 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`.5. 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.Before 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.## Hand offUse `AGENTS.md`'s handoff contract; include invocation and compatibility details for public-contract changes.

Frequently asked questions