CloudVeil (Yunyin) Skill

Workflow

1. Check Environment        → Verify CLOUDVEIL_BASE_URL / CLOUDVEIL_ACCOUNT / CLOUDVEIL_PASSWORD
2. Authentication            → Use SSO getSecret + SM2 encryption + accountLogin to obtain access_token
3. Understand Intent        → Locate functional group → Read references/capabilities.md and the hit group documents
4. Normalize Parameter Names    → Map user input fields to the actual field names specified in the interface specification
5. Build and Execute Request  → Read method, query, requestBody, schema from assets/*.openapi.json
6. Display Results        → Consider it successful only if HTTP status is 200 and message === "SUCCESS"; otherwise, display as failed

Step 1: Check Environment

Before any actual call, read

references/request-sdk.md

and check the following:

Variable	Function
`CLOUDVEIL_BASE_URL`	CloudVeil server base URL, e.g., `https://cloudveil.example.com`
`CLOUDVEIL_ACCOUNT`	CloudVeil login account
`CLOUDVEIL_PASSWORD`	CloudVeil login password

If any variable is missing, stop execution and prompt the user to complete it. Do not use default demo URLs, and do not write accounts, passwords, access tokens, or encrypted credentials into repository files.

Step 2: Authentication

CloudVeil uses the SSO/SM2 login process:

GET /openapi/sso/api/v1/secret/getSecret

Use the returned

data.secret

to encrypt

CLOUDVEIL_ACCOUNT

and

CLOUDVEIL_PASSWORD

with SM2

POST /openapi/sso/api/v1/account/accountLogin

Use
```
data.access_token
```
to call the target OpenAPI

For specific call rules, token header overrides, and usage of

scripts/cloudveil-request.js

, refer to

references/request-sdk.md

Step 3: Understand Intent and Locate Interface

First read

references/capabilities.md

, locate the functional group based on the user's description, then only open the hit group documents and assets.

Functional Group	Detailed Document	OpenAPI Asset	Typical Scenarios
Common Interfaces	`references/capabilities-common.md`	`assets/common.openapi.json`	Stores, maps, robot groups, locations
Robot Information	`references/capabilities-robot-info.md`	`assets/robot-info.openapi.json`	Robot status, task status
Robot Tasks	`references/capabilities-robot-tasks.md`	`assets/robot-tasks.openapi.json`	Calling, delivery, transport, errand, lifting, pallet, hosting
Control Commands	`references/capabilities-control.md`	`assets/control.openapi.json`	Position reporting, map switching, one-click recharge, card swiping, device shadow
Statistical Data	`references/capabilities-statistics.md`	`assets/statistics.openapi.json`	Data board, analysis, task details, logs
Order-to-Person (Beta)	`references/capabilities-order-to-person.md`	`assets/order-to-person.openapi.json`	Orders, pallet configuration, aisles, picking, batches, warehouses
Callback Notifications	`references/capabilities-callbacks.md`	Not covered	Passive callback parameter description
Robot Dispatch	`references/capabilities-dispatch.md`	Not covered	Traffic control zone / dispatch interfaces

Groups marked as Not covered do not have bundled OpenAPI assets. Do not fabricate paths, parameters, callbacks, or request bodies.

Step 4: Normalize Parameter Names

Parameter names entered by users may use camelCase, snake_case, or kebab-case formats. Before building query or JSON request bodies, you must automatically map user fields to the actual field names required by the interface according to the

parameters

and

requestBody

schema in the current interface specification:

```
shopId
```
/
```
shop_id
```
/
```
shop-id
```
→ Convert to
```
shopId
```
or
```
shop_id
```
according to the current interface specification
```
groupId
```
/
```
group_id
```
/
```
group-id
```
→ Convert to
```
groupId
```
or
```
group_id
```
according to the current interface specification
```
payload.startPoint
```
/
```
payload.start_point
```
/
```
payload.start-point
```
→ Convert to the actual nested field name according to the schema

Normalization Rules:

Build a whitelist of field names using the current interface specification; do not determine the final field names based on common sense
Ignore case,
```
_
```
, and
```
-
```
during matching, but the final output must retain the original field name format specified in the specification
Apply the same rules recursively to objects and array objects in the request body
Only convert field names, do not change field values
If an input field matches multiple specification fields, or the field is not in the specification, confirm with the user first; do not send unknown fields directly to the interface

Step 5: Build and Execute Request

Read the exact method, query parameters, JSON requestBody, Schema, and response structure from the corresponding

assets/*.openapi.json

. Do not guess field names based solely on natural language; parameter name normalization must be completed before sending the request to ensure all field names are exactly consistent with the specification.

Use

jq

rg

for large-scale searches instead of loading the entire asset into the context:

bash

jq -r '.paths | keys[]' assets/robot-tasks.openapi.json
jq '.paths["/openapi/open-platform-service/v1/custom_call"].post.requestBody' assets/robot-tasks.openapi.json
jq '.paths["/openapi/data-board/v1/brief/shop"].get.parameters' assets/statistics.openapi.json
jq '.paths["/openapi/order_to_user/v1/order/import"].post.requestBody' assets/order-to-person.openapi.json

For actual calls, use:

bash

node scripts/cloudveil-request.js --path <api-path> [--method GET|POST] [--param key=value] [--body-json '<json>']

Step 6: Display Results

Success must meet both of the following conditions:

HTTP status code is
```
200
```
```
message === "SUCCESS"
```
in the response JSON

If HTTP status is 200 but

message

is not

SUCCESS

, treat it as a business failure. When displaying results, retain the interface, method, key parameters, and returned JSON; credentials, tokens, passwords, and SM2 encryption results must be desensitized.

Quick Reference for Common Interfaces

text

# Robot Status
GET /openapi/open-platform-service/v2/status/get_by_sn
GET /openapi/open-platform-service/v2/status/get_by_group_id

# Maps and Locations
GET /openapi/map-service/v1/open/current
GET /openapi/open-platform-service/v1/robot/get_position
POST /openapi/map-service/v1/open/group

# Tasks
POST /openapi/open-platform-service/v1/custom_call
POST /openapi/open-platform-service/v1/delivery_task
POST /openapi/open-platform-service/v1/transport_task
POST /openapi/open-platform-service/v1/task_errand
POST /openapi/open-platform-service/v1/lifting_task

# Control
GET /openapi/open-platform-service/v2/recharge
POST /openapi/open-platform-service/v1/switch_map

# Statistics
GET /openapi/data-board/v1/brief/shop
GET /openapi/data-board/v1/analysis/run

# Order-to-Person
POST /openapi/order_to_user/v1/order/import
GET /openapi/order_to_user/v1/batch/query
GET /openapi/order_to_user/v1/warehouse/query_points

pudu-cloudveil-skill

NPX Install

Tags

SKILL.md Content (Chinese)