diff --git a/.codex/skills/cpa-upgrade-deploy/SKILL.md b/.codex/skills/cpa-upgrade-deploy/SKILL.md
new file mode 100644
index 0000000..a892193
--- /dev/null
+++ b/.codex/skills/cpa-upgrade-deploy/SKILL.md
@@ -0,0 +1,86 @@
+---
+name: cpa-upgrade-deploy
+description: Upgrade, build, package, upload, or deploy CLIProxyAPI (CPA) cores and native plugins using a repository's maintained release workflow. Use for CPA submodule upgrades, patched host releases, billing/keeper plugin publishing, and deployment to an existing CPA server. Distinguish packaging, upload, and deployment instead of silently expanding scope.
+---
+
+# CPA Upgrade and Deploy
+
+Treat the repository's `AGENTS.md`, development documentation, operations guide, patch README, and maintained release scripts as the source of truth. Read the applicable files before changing or deploying anything. Do not copy version numbers or secrets from this skill when the repository can provide them.
+
+## Match the requested scope
+
+Classify the request before acting:
+
+- **Build/package:** build the requested existing source and produce artifacts. Do not update dependencies, commit, upload, or deploy unless requested.
+- **Upload:** transfer already built or newly requested artifacts to the configured upload directory and verify checksums. Upload does not imply installation or restart.
+- **Plugin deploy:** rebuild and replace only the named plugin. Do not replace the CPA core.
+- **CPA deploy:** deploy the already selected CPA revision. Do not move the submodule or rewrite patches.
+- **CPA upgrade and deploy:** update the submodule to the requested/latest upstream revision, adapt maintained host patches, validate, build, upload, and deploy.
+
+When wording genuinely combines operations, perform the combination. For example, “update the submodule and package/upload” authorizes the upgrade and upload, but not an unrequested Git commit or remote installation. “Update the server” or “deploy” authorizes installation and restart.
+
+Do not add a commit unless the user asks for one or the repository's documented release command explicitly requires it. Never push Git changes unless requested.
+
+## Prefer the shortest maintained path
+
+1. Inspect existing release scripts before writing commands. Prefer a maintained script such as `scripts/push.ps1` or the repository's documented equivalent.
+2. Use one canonical build artifact per revision. Verify its embedded version and SHA-256, then reuse it for local acceptance, packaging, upload, and deployment.
+3. Do not rebuild or rerun tests after inputs are unchanged. Do not repeat clean-baseline patch checks once reproducibility is established.
+4. Create a temporary helper script only when quoting or remote orchestration cannot be expressed safely through the maintained workflow. Keep one helper per operation and remove or leave it only in the repository's ignored temporary directory.
+5. If the maintained script lacks a required combined operation, make the smallest extension or use one transactional deployment script; do not accumulate overlapping ad-hoc scripts.
+
+## Upgrade a patched CPA core
+
+Only use this section when an upstream revision change is in scope.
+
+1. Confirm the latest upstream tag/commit without mutating the submodule.
+2. Confirm the current submodule changes are exactly the repository-maintained patches. Preserve any unrelated user changes and stop if they overlap.
+3. Reverse patches in the documented reverse order, move the submodule to the selected official revision, then reapply patches in the documented forward order.
+4. If a patch conflicts, adapt it to the new upstream structure while preserving both the patch's invariant and new upstream behavior. Update the patch file and baseline documentation.
+5. Verify a clean-baseline sequential patch replay once. Do not keep replaying it after the patch files and baseline are unchanged.
+6. Run the repository-mandated focused/race tests and the minimum additional tests required by changed upstream areas. Treat documented failures as upstream exceptions only after reproducing them on the clean new baseline when the operations guide requires it.
+7. Build with the upstream release workflow's version, commit, and build-date linker fields. Execute the binary locally and verify the complete version line before upload.
+
+Avoid running `gofmt` over whole upstream directories on a Windows/WSL checkout. Format only files changed by maintained patches; otherwise line-ending conversions can make the entire submodule appear dirty.
+
+## Validate proportionally
+
+Follow mandatory repository acceptance rules, but avoid expanding them:
+
+- A source upgrade requires patch compatibility, compilation, and the documented focused tests.
+- A plugin-only rebuild with unchanged source does not require a CPA full-suite rerun.
+- Reusing a previously validated artifact requires checksum and embedded-version verification, not a rebuild.
+- Run real model requests only in the local CPA when the repository requires protocol or billing acceptance.
+- Never send model, compact, chat-completions, or responses requests to the production server when repository policy forbids them.
+
+For billing releases, local acceptance should prove only the required invariants: authentication behavior, one request producing one detail and one charge, Request ID/token presence, compact classification and zero cost when relevant, cancellation cleanup when host lifecycle code changed, and `active_requests=0`.
+
+## Deploy transactionally
+
+Before changing the server:
+
+1. Verify local and uploaded archive hashes and the embedded CPA version.
+2. Verify the server is healthy and required plugins are effective.
+3. Read management/downstream keys from server secret files inside the script; never print them.
+4. Drain active billing requests, then stop the CPA through its configured manager.
+5. Back up the old core, all maintained plugin binaries, configuration, and the repository-specified database sidecars.
+6. Replace only the components in scope and preserve configuration, secrets, unrelated plugins, and keeper state.
+7. Restart and verify health, exact hashes/version, billing and keeper registration, logs, and `active_requests=0` without making a production model request.
+8. Automatically restore the backup and restart the previous service state if installation or verification fails.
+
+Upload compressed artifacts; do not transfer an uncompressed CPA binary when the operations guide prohibits it.
+
+## Communicate without ceremony
+
+Give one short update at each meaningful phase: scope selected, build/validation result, upload complete, deployment result. Do not narrate every shell command or internal detour.
+
+On completion report:
+
+- what was upgraded, packaged, uploaded, and/or deployed;
+- CPA tag/commit and project commit only if one was created;
+- artifact paths and SHA-256 values;
+- tests and local acceptance actually run, including documented upstream exceptions;
+- remote health/plugin status and backup path when deployed;
+- confirmation that no production model request was sent.
+
+If work becomes larger because of an actual patch conflict, dirty user change, failed validation, or rollback, state that concrete reason immediately. Do not perform unrelated cleanup or redesign under the label of deployment.
diff --git a/.codex/skills/cpa-upgrade-deploy/agents/openai.yaml b/.codex/skills/cpa-upgrade-deploy/agents/openai.yaml
new file mode 100644
index 0000000..2e83693
--- /dev/null
+++ b/.codex/skills/cpa-upgrade-deploy/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "CPA Upgrade & Deploy"
+  short_description: "Upgrade, package, and deploy CPA safely without scope creep"
+  default_prompt: "Use $cpa-upgrade-deploy to upgrade or deploy CPA using the repository's maintained release workflow."