volcengine-sdk-generator

What this skill does

# Volcengine SDK Code Generator

Generate complete, runnable Volcengine SDK code from natural-language descriptions, and answer SDK configuration questions.

## Workflow

When a user describes a Volcengine API operation, follow these steps:

### Step 1: Identify Target Service, Operation, and Advanced Configuration Needs

Parse the user's description to determine:
- **Target service**: which Volcengine service (e.g., ECS, VPC, TOS, billing)
- **Target operation**: what operation to perform (e.g., list instances, create a VPC, query billing)
- **Target language**: which programming language (Go, Python, PHP, Java, Node.js). If not specified, ask the user.
- **Advanced configuration needs**: whether the user mentions or the scenario implies any of the following:
  - **Retry**: user mentions "retry", "fault tolerance", or the operation is a write/create type (prone to throttling)
  - **Timeout**: user mentions "timeout", or the operation involves large data volumes (batch queries, file uploads)
  - **Credentials**: user mentions "STS", "AssumeRole", "temporary credentials", "OIDC", or explicitly wants to avoid hardcoding AK/SK
  - **Proxy/network**: user mentions "proxy" or "internal network"
  - **Debug mode**: user mentions "debug" or "logging"
  - **Connection pooling**: user mentions "connection pool", "high concurrency", or "pool"

  If the user explicitly requests these, include the corresponding configuration in the generated code. If not explicitly requested but implied by the scenario (e.g., resource creation naturally warrants retry), include suggested configuration as comments.

### Step 2: Query Service Metadata via Volcengine API Explorer

Use the following APIs to find the correct service code, version, and action name. This step is critical because guessing often produces incorrect code — the API Explorer is the authoritative source.

**2a. Find the ServiceCode**

Fetch the service catalog:
```
GET https://api.volcengine.com/api/common/explorer/services
```
Response structure:
```json
{
  "Result": {
    "Categories": [
      {
        "CategoryName": "...",
        "Services": [
          {
            "ServiceCn": "Cloud Server",
            "ServiceCode": "ecs",
            "Product": "ECS",
            "IsSdkAvailable": true,
            "RegionType": "regional"
          }
        ]
      }
    ]
  }
}
```
Match the user's intent to the correct `ServiceCode` based on `ServiceCn`, `Product`, and category name.

**2b. Find the API version**

```
GET https://api.volcengine.com/api/common/explorer/versions?ServiceCode={ServiceCode}
```
Response:
```json
{
  "Result": {
    "Versions": [
      {
        "ServiceCode": "billing",
        "Version": "2022-01-01",
        "IsDefault": 0
      }
    ]
  }
}
```
Use the version with `IsDefault == 1`. If no default version exists, use the latest available.

**2c. Find the Action name**

```
GET https://api.volcengine.com/api/common/explorer/apis?ServiceCode={ServiceCode}&Version={Version}&APIVersion={Version}
```
Response:
```json
{
  "Result": {
    "Groups": [
      {
        "Name": "Instance",
        "Apis": [
          {
            "Action": "DescribeInstances",
            "NameCn": "Query instance list",
            "Description": "..."
          }
        ]
      }
    ]
  }
}
```
Match user intent using the `Action` name and `NameCn` (Chinese name).

**2c-alt: Search API (when direct lookup fails)**

If the service catalog or API list cannot clearly match the user's description — for example, the user uses vague terms, Chinese names that don't map directly to a ServiceCode, or the API list doesn't seem to contain what the user wants — use the search API as a fallback:

```
GET https://api.volcengine.com/api/common/search/all?Query={URL-encoded search term}&Channel=api&Limit=10
```

Search terms can be Chinese or English — use whichever best matches the user's description.

Response structure:
```json
{
  "Result": {
    "List": [
      {
        "BizInfo": {
          "Action": "ListProjects",
          "ServiceCn": "Access Control",
          "ServiceCode": "iam",
          "Version": "2021-08-01"
        },
        "Highlight": [
          {"Field": "title", "Summary": "Get <em>project</em> <em>list</em>"}
        ]
      }
    ],
    "Total": 200
  }
}
```

Select the best match based on `ServiceCn`, `Action`, and highlight text, then continue to step 2d.

The search API is particularly useful when:
- The user describes the operation in natural language but doesn't know which service owns it
- A service has too many APIs to browse manually
- The description spans multiple services (search returns results across all services)

**2d. Get full API parameter details**

```
GET https://api.volcengine.com/api/common/explorer/api-swagger?ServiceCode={ServiceCode}&Version={Version}&APIVersion={Version}&ActionName={Action}
```
Returns the full Swagger/OpenAPI specification, including:
- HTTP method (GET/POST)
- All request parameters with types, required flags, and descriptions
- Response structure
- Constraints and validation rules
- **`x-demo` field**: contains `requestDemo` and `responseDemo` with official examples

Read this specification carefully — it is essential for generating accurate code.

**2e. Extract parameter example values (from x-demo requestDemo)**

The `info.x-demo` array in the Swagger response contains `requestDemo` — official request examples. Extract realistic parameter values from these to populate generated code.

Extraction process:
1. Locate `info.x-demo[0].requestDemo` and parse the request body JSON
2. Use requestDemo values as example values in generated code — they are more accurate and realistic than invented values
3. For masked values (e.g., `cc5silum********`), keep the masked format and add a comment prompting the user to replace with real values
4. If a parameter value is a JSON string (e.g., a `Config` field), format it clearly and comment each sub-field

Example: for VKE CreateAddon, requestDemo contains:
```json
{
    "ClusterId": "cc5silum********",
    "Name": "ingress-nginx",
    "DeployMode": "Unmanaged",
    "DeployNodeType": ["VirtualNode"],
    "Config": "{\"Replica\":1,\"Resource\":{\"Request\":{\"Cpu\":\"0.25\",\"Memory\":\"512Mi\"},\"Limit\":{\"Cpu\":\"0.5\",\"Memory\":\"1024Mi\"}},\"PrivateNetwork\":{\"SubnetId\":\"subnet-2d61qn69iji****\",\"IpVersion\":\"IPV4\"}}"
}
```
Use these example values directly instead of empty placeholders.

**2f. Retrieve detailed configuration for complex parameters**

Some parameter `description` fields contain documentation links (e.g., `https://www.volcengine.com/docs/...`) pointing to detailed configuration guides. For complex parameters, fetch these links for more information:

When to consult documentation:
- The parameter value is a JSON string with a "see detailed configuration" reference in the description (e.g., VKE `Config`)
- The parameter is a nested structure whose sub-field format is documented externally
- The `enum` values have unclear meanings that are explained in the documentation

Processing flow:
1. Check whether the parameter `description` contains a `volcengine.com/docs` link
2. If so, use WebFetch to retrieve the linked page and extract configuration details relevant to the parameter
3. Incorporate documentation examples into the generated code as comments or structured parameters
4. If the documentation is inaccessible, fall back to requestDemo example values

**2g. Determine required and recommended parameters**

Required-field detection relies on multiple sources, not just the `required` array:

1. **Explicitly required**: listed in the Swagger `required` array
2. **Implied by description**: the description contains phrases like "must specify", "required", or equivalent
3. **Logically required**: semantically essential even if not formally marked (e.g., instance type and network config when creating resources)
4. **Conditionally required**: the description states "required when X