aicade-create-service

Use when registering, updating, querying, or disabling aicade service-management APIs under /services, especially when preparing service metadata, billing, r...

Security Scan

The skill appears to implement the advertised service-registration helpers, but it reads and will reuse local secrets (AICADE_API_KEY and AICADE_WALLET_ADDRESS) without declaring them in registry metadata or always prompting the user — this mismatch and the automatic use of env secrets is concerning.

Purpose & Capability

The skill's name/description and included files (references, templates, scripts) align with a service-registration helper and legitimately need node and the ability to read AICADE_API_KEY and AICADE_WALLET_ADDRESS. However, the registry metadata lists no required environment variables or primary credential while SKILL.md and scripts clearly expect and use those env vars. That metadata omission is an incoherence the user should note.

Instruction Scope

SKILL.md and the bundled scripts instruct the agent to check local environment variables and, if present, use AICADE_API_KEY as X-API-Key and AICADE_WALLET_ADDRESS as X-Address 'without asking the user to confirm it again.' The runtime instructions also direct writing confirmed JSON to a local file and generating curl commands. The instructions do not instruct contacting arbitrary remote endpoints beyond the documented AICADE URLs, but the automatic, unconditional reuse of local secrets expands scope beyond mere guidance and could expose secrets in generated output.

Install Mechanism

No installer or remote download is included; the skill is instruction-only with a bundled Node script. This is low-risk in terms of install-time code execution or third-party downloads. The only runtime requirement is node, which is declared in SKILL.md and the registry metadata's required binaries list.

Credentials

The environment variables referenced (AICADE_API_KEY and AICADE_WALLET_ADDRESS) are relevant and proportionate to the stated purpose. However, they are not declared in the skill's registry metadata as required credentials, creating an inconsistency. Moreover, the instructions explicitly tell the agent to use these env values without user confirmation when present, which increases the risk of inadvertent secret exposure.

Persistence & Privilege

The skill does not request permanent 'always' inclusion and does not modify other skills or system-wide settings. It can be invoked autonomously by the agent (default behavior), and if invoked autonomously it will check process.env and may emit curl lines containing secrets. Autonomous invocation combined with the auto-use of local secrets raises the potential blast radius, but autonomous invocation alone is expected behavior.

What to consider before installing

This skill appears to do what it claims (prepare/validate registration JSON and generate curl for /services), but pay attention to how it handles secrets: SKILL.md and scripts will check process.env for AICADE_API_KEY and AICADE_WALLET_ADDRESS and will reuse them without asking if they exist. Before installing or enabling this skill, consider: 1) Require the skill author or registry metadata to declare the required env vars explicitly. 2) Ask for an explicit confirmation step before any secret is read or included in generated outputs (the skill currently instructs to skip confirmation). 3) If you must use it, avoid setting real secrets as persistent environment variables — use temporary shells or placeholders and paste secrets only when you explicitly confirm. 4) Inspect generated curl commands before copying/executing them (they will include headers with the API key and address). 5) If you want lower risk, request a version that always asks for explicit consent before reading any AICADE_* env var or that supports placeholder tokens for sensitive upstream credentials. If you want more certainty about intent or safety, ask the author to explain why the registry metadata omits env var declarations and to update the manifest to list required credentials.

READ BEFORE INSTALL This skill is built from the bundled service-management API reference. It covers exactly these three operations:

1. Register or update a service: POST /services
2. Query service detail: GET /services/{serviceId}
3. Disable a service: POST /services/disable?serviceId=... READ BEFORE INSTALL

Use this skill when you need to prepare, validate, or generate requests for aicade service registration and management.

Core Principle

Treat every service-management operation as a guided flow, not a one-shot dynamic call.

For POST /services, do not immediately fill the request from a generic example. First ask the user multiple focused questions, confirm the answers, then generate the final registration JSON and curl.

For GET /services/{serviceId} and POST /services/disable, also ask for the required operation inputs first. Do not infer serviceId or base_url from previous turns unless the user explicitly confirms reusing them.

Environment variables are different: check the local environment first. If AICADE_API_KEY already exists locally, use it without asking the user to confirm it again. For register/update, if AICADE_WALLET_ADDRESS already exists locally, use it without asking again.

Before generating a request, make sure the user has confirmed:

• stable service_id, service_name, endpoint_url, and route_path
• correct outbound auth settings
• valid input_schema and output_schema
• explicit billing and fallback rules
• rate limits when the service needs operational protection
• AICADE_API_KEY supplied by the platform before calling any endpoint
• AICADE_WALLET_ADDRESS supplied by the caller before register/update; it is sent as X-Address

Quick Start

Set the platform API key first:

export AICADE_API_KEY=YOUR_AICADE_API_KEY
export AICADE_WALLET_ADDRESS=YOUR_AICADE_WALLET_ADDRESS

After the user confirms the generated registration JSON, write it to a local spec file and generate the register/update request:

node {baseDir}/scripts/build-service-request.mjs \
  register \
  --base-url https://api.example.com \
  --spec /path/to/confirmed-register-service.json

After the user confirms the query inputs, generate a query request:

node {baseDir}/scripts/build-service-request.mjs \
  detail \
  --base-url https://api.example.com \
  --service-id my-llm-service

After the user confirms the disable inputs, generate a disable request:

node {baseDir}/scripts/build-service-request.mjs \
  disable \
  --base-url https://api.example.com \
  --service-id my-llm-service

Workflow

1. Check Local Environment First

Before asking for platform credentials, check whether the required environment variables are already present:

node {baseDir}/scripts/build-service-request.mjs env-check --operation register
node {baseDir}/scripts/build-service-request.mjs env-check --operation detail
node {baseDir}/scripts/build-service-request.mjs env-check --operation disable

If AICADE_API_KEY is already present, do not ask the user to confirm it. Use it as X-API-Key.

For register/update, if AICADE_WALLET_ADDRESS is already present, do not ask the user to confirm it. Use it as X-Address.

Ask only for missing environment values. If the user does not have platform access yet, point them to:

• https://www.aicadegalaxy.com/
• https://docs.aicadegalaxy.com/white-paper/application-document

Explain briefly that only after obtaining app access can they get the AICADE environment variables required by this skill:

• AICADE_API_KEY
• AICADE_WALLET_ADDRESS

AICADE_API_KEY is sent as X-API-Key. AICADE_WALLET_ADDRESS is sent as X-Address for register/update requests.

2. Identify The Operation

• Register/update: use when creating a service or replacing the configuration for an existing service_id
• Detail: use when checking the registered gateway contract
• Disable: use when turning off a service

Always run the matching guided intake before generating the final request:

• Register/update: collect and confirm the full registration JSON
• Detail: collect and confirm base_url and serviceId; use local AICADE_API_KEY when present
• Disable: collect and confirm base_url and serviceId; use local AICADE_API_KEY when present

3. Load The API Reference When Needed

Read these references when needed:

• references/register-intake.md for the required multi-step questions
• references/service-operations-intake.md for query/detail and disable question flows
• references/service-management-api.md for field rules, enum guidance, auth examples, billing rules, or rate-limit structure

4. Ask Register Intake Questions

Collect the registration fields in small groups. Do not ask for every field in one wall of text.

Use this order:

1. Service identity: service_id, service_name, description, tags
2. Endpoint and gateway route: endpoint_url, route_path, strip_prefix, route_order, timeout_ms
3. Outbound auth: auth_type, auth_location, outbound_auth
4. Input/output contract: input_schema, output_schema
5. Billing: billing_type, currency, prices, limits, fallback_strategy
6. Rate limits: service/user/IP limits and token limits
7. Final review: show the assembled JSON and ask for confirmation before generating curl

When the user has not supplied a value, ask a direct question and offer a reasonable default when the API supports one. For sensitive values such as API keys or tokens, ask for placeholders unless the user explicitly wants to include the real value.

5. Prepare Register Input

Start from:

• {baseDir}/assets/register-service.template.json for a minimal fill-in template
• {baseDir}/assets/register-service.example.json only as a shape reference, not as the user's final registration

Keep request body fields in snake_case. The API supports a few camelCase aliases, but generated requests should prefer snake_case.

6. Validate Critical Fields

Before presenting or sending a register request, check:

• AICADE_API_KEY is available as an environment variable or passed explicitly with --api-key
• AICADE_WALLET_ADDRESS is available as an environment variable or passed explicitly with --address
• service_id uses lowercase letters, digits, and hyphens only, length 3-64
• route_path starts with /
• timeout_ms is between 1000 and 300000 when set
• strip_prefix is between 0 and 10 when set
• input_schema and output_schema are JSON Schema compatible
• billing.billing_type, billing.currency, and billing.fallback_strategy are present
• outbound_auth.type matches auth_type unless auth_type is NONE

7. Generate Requests

Use scripts/build-service-request.mjs to print a ready-to-run curl command. The script reads AICADE_API_KEY and AICADE_WALLET_ADDRESS by default, or accepts --api-key and --address for one-off generation. The script does not call the remote API; it only reads local input and prints the command.

Endpoint Summary

Operation	Method	Path	Required headers
Register/update	POST	/services	X-Address, X-API-Key, Content-Type: application/json
Detail	GET	/services/{serviceId}	X-API-Key
Disable	POST	/services/disable?serviceId=...	X-API-Key

Common Mistakes

• Do not skip the platform access check; AICADE_API_KEY must be obtained before using these APIs.
• Do not ask the user to reconfirm AICADE_API_KEY when it already exists in the local environment.
• Do not ask the user to reconfirm AICADE_WALLET_ADDRESS for register/update when it already exists in the local environment.
• Do not generate a register/update request without AICADE_WALLET_ADDRESS; it is required for X-Address.
• Do not use assets/register-service.example.json as the user's final service config without asking questions.
• Do not generate the final register curl before the user confirms the assembled JSON.
• Do not generate query/detail curl before asking and confirming serviceId and base_url.
• Do not silently reuse a previous serviceId; ask whether to reuse it.
• Do not omit X-API-Key; all three operations require it and the value should come from AICADE_API_KEY.
• Do not put registration body fields in random casing; prefer documented snake_case.
• Do not register without input_schema, output_schema, and billing.
• Do not put serviceId in the disable body; it is a query parameter.
• Do not treat POST /services as create-only; it is idempotent and updates existing service_id.

Files Included

• references/service-management-api.md
• references/register-intake.md
• references/service-operations-intake.md
• scripts/build-service-request.mjs
• assets/register-service.template.json
• assets/register-service.example.json