easyai-ai-gateway/apps/api/internal/skillbundle/content/skills/ai-gateway-ops-management/SKILL.md

name, description

name

description

ai-gateway-ops-management

Operate and verify EasyAI AI Gateway administration capabilities. Use when Codex or an Agent needs to inspect, create, update, disable, restore, or troubleshoot AI Gateway providers, base models, pricing and billing configuration, price estimates and wallet deduction reconciliation, runtime policies, runner policies, integration platforms, platform-model bindings, or universal custom-script platforms; also use this skill as the extensible entry point for future AI Gateway operations modules.

AI Gateway Operations Management

Use this skill to operate AI Gateway administration APIs through documented, evidence-first workflows.

Operating Rules

• Obtain the Gateway API base URL and an administrator JWT before calling management APIs. Admin APIs reject sk-* API keys.
• Read references/api-discovery-and-safety.md before any write operation.
• Select only the references for the requested module. Do not load unrelated future operations modules.
• Read current state before changing it. Treat PATCH bodies as complete resource configurations unless the reference explicitly says otherwise.
• Never write credentials, tokens, script authValues, raw upstream responses, or other secrets into Skill files, logs, commands shown to users, or final summaries.
• Execute ordinary creates and updates only when the user requested the change. Before DELETE, full replacement, bulk reset, platform disablement, or credential clearing, show the current snapshot and impact and obtain explicit confirmation.
• Reuse existing pricing rules, runtime policy sets, providers, protocol clients, base models, and platforms whenever their effective behavior satisfies the target. Do not create a near-duplicate resource merely because the upstream account, base URL, or provider-side model name differs.
• Prefer a supported standard client before using universal scripts. Use custom scripts only when the upstream contract cannot be represented by the existing OpenAI, Gemini, or provider-specific clients.
• Do not invent platform config fields or assume an arbitrary config key is enforced. For universal, use only the recognized keys documented in references/model-universal-platforms.md; treat any extra key as script-owned data available through context.env.
• Use the module references as the primary API source. Only when the required API is absent, inspect <gateway-origin>/api/v1/openapi.json; continue only when path, method, schema, authentication, permission, and side effects are unambiguous.

Module Routing

Model Runtime

Use these references for the current v1 module:

• references/model-providers-and-base-models.md: provider catalog and base-model lifecycle.
• references/model-pricing-and-policies.md: pricing rule sets, runtime policy sets, runner policy, priority, and recovery.
• references/model-billing-configuration-and-estimation.md: effective billing configuration, price-estimate calls, simulation/real charge comparison, and wallet reconciliation.
• references/model-platforms-and-bindings.md: integration platforms, credentials, platform-model upsert, replacement, and deletion.
• references/model-universal-platforms.md: universal custom platform triage, configuration, script contracts, and examples.
• references/model-acceptance-runbook.md: read-back, catalog, simulation, runtime, billing, and rollback verification.

Standard Workflow

1. Read references/api-discovery-and-safety.md and confirm the API base URL, identity mode, administrator JWT, target documentation, and required credentials.
2. Read the current provider, base-model, pricing, policy, platform, and platform-model records relevant to the request.
3. Reuse an existing pricing rule when its base prices and calculators, combined with the effective platform or platform-model discount, produce the required price. Create a pricing rule only when that combination cannot represent the target.
4. Reuse an existing runtime policy set when its limits, scopes, retry, auto-disable, and degradation behavior match the requirement. Create a policy only for a real semantic difference.
5. Classify the upstream protocol against existing platforms and clients. If compatible, keep the existing specType and change only instance configuration such as baseUrl, credentials, and bindings. Use universal only for an unsupported protocol.
6. Reuse the base model across platforms. Put a platform-specific upstream invocation name in the platform-model providerModelName; do not duplicate the base model just because providers use different names.
7. Apply the minimum changes in dependency order: provider, base model, pricing/policy, platform, platform-model binding.
8. Read every changed resource back and verify the effective model catalog.
9. For billing work, read references/model-billing-configuration-and-estimation.md, call /api/v1/pricing/estimate with the same user identity and request parameters intended for execution, and reconcile the returned candidate, line items, discounts, quantities, and total.
10. Run a simulation or approved real request only after the estimate is accepted. Inspect task billing and wallet transactions; do not assume simulation is free or side-effect-free.
11. Report reused and created resource IDs, effective pricing evidence, protocol-fit evidence, verification results, unresolved risks, and whether the Swagger fallback was used, without exposing secrets.

Extending This Skill

• Add future modules as one-level files under references/ with stable prefixes such as storage-, runtime-, identity-, or network-.
• Add the module to this routing section and to skill.json.
• Increment the skill.json version whenever downloadable contents change.
• Keep the same skill name and public download route.