SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsbyted-vefaas-skills

byted-vefaas-skills

Coding & development

View repository

Updated 10-15 17:30

About this skill

vefaas

This skill guides you to use @volcengine/vefaas-cli to operate Volcano Engine veFaaS, including application deployment, function management, sandbox management, environment variables, configuration, diagnostics, and other operations that can be performed in the Volcano Engine Function Service console as well as OpenAPI calls.

Prerequisites

CRITICAL — Before performing any veFaaS operation, you MUST first confirm that the local vefaas CLI version >= 0.2.7.

vefaas --version
vefaas update --check

If the command does not exist, or the version is lower than 0.2.7, you must upgrade first; if vefaas update --check finds an updatable version, you should prompt the user to upgrade before continuing:

npm i -g @volcengine/vefaas-cli@latest
vefaas --version

Document retrieval capability (no login required) — vefaas doc can retrieve official veFaaS documentation in the terminal,no login required, read-only, no billing. This is theauthoritative knowledge sourcefor this skill when answering questions about veFaaS concepts/capabilities/selection/billing/SDK usage, and when writing SDK/OpenAPI code. See the "doc-first protocol" below for details. Run vefaas doc --help to confirm availability; if unavailable, first vefaas update upgrade the CLI.

Applicable scenarios

Use this skill:

  • The user wants to deploy a local project, website, API service, Node.js service, Python service, or static site to Volcano Engine veFaaS.
  • The user wants to create a serverless application based on a template, or connect an existing project to veFaaS.
  • The user wants to view the console overview, online access address, release records, logs, or resource usage.
  • The user wants to configure environment variables, adjust build commands, startup commands, ports, or resource configurations, or delete an existing application.
  • The user wants to manage online functions: create, view, publish, roll back, invoke, logs, instances, tasks, scaling policies, triggers, dependencies, WebShell.
  • The user wants to pull cloud function code, modify it locally, then push or redeploy.
  • The user wants to manage sandbox applications, sandbox instances, sandbox images, sandbox logs, sandbox WebShell.
  • The user wants to troubleshoot deployment failures, authentication failures, framework detection errors, missing gateways, configuration inconsistencies, or OpenAPI call failures.
  • The user explicitly wants to call a veFaaS OpenAPI action, or high-level commands cannot cover the target operation.
  • The user is encountering veFaaS for the first time and is unclear what it is or how to get started, and needs landing guidance (can start without logging in first).
  • The user asks about veFaaS concepts, capability boundaries, resource selection, billing, quotas, triggers, and other questions, and needs accurate answers based on official documentation.
  • The user wants to integrate the veFaaS SDK (Go/Python/Node) into their own code or call OpenAPI, and needs to refer to official examples to assist development.

Resource mental model

  • Functions are the core resource of veFaaS (Function Service), carrying code/images, versions, instances, logs, resource specifications, and scaling policies; function instances are usually dynamically scaled by the platform based on traffic and policies.
  • An application is a product form that orchestrates application-level logic on top of functions. It includes overall version management, APIG trigger association, and automatic deployment triggered by Git repositories, etc., making it easier for users to publish and access applications.
  • A sandbox is a special/customized function. Its Function, Revision, and Instance models are similar to those of a function, but it must be created based on a pre-warmed image. It is suitable for scenarios such as code sandboxes and model evaluation that require isolated environments to be spun up in seconds; sandbox instances must be created proactively and support pause, resume, close, and adjustment of expiration time.
  • When you need more detailed resource relationships, ID usage rules, or CLI target mappings, read CLI and versions。

CRITICAL workflow triage

CRITICAL — First determine whether the user's intent is "knowledge type" or "execution type", then triage:

  • Knowledge type(asking about concepts/capabilities/selection/billing/limits; using it for the first time and wanting landing onboarding guidance; wanting to write SDK/OpenAPI integration code) → follow the "documentation-first (doc-first) workflow":First use vefaas doc to search the official documentation, answer or write code based on the documentation, usually no login required. Before continuing, MUST read Documentation search and doc-first。
  • Execution type(real resource operations such as deploy, publish, rollback, invoke, and manage functions/applications/sandboxes/gateways) → follow the corresponding execution workflow below.
  • Mixed type(e.g., "help me deploy this project, and also explain billing") → first use doc-first to answer questions, then follow the execution workflow.

Below are the triage rules for execution-type workflows:

CRITICAL — When the user says "deploy project / website launch / API launch / serverless application / check access address", follow the application workflow by default, and do not directly create a function.

The application workflow uses vefaas init、vefaas inspect、vefaas link、vefaas deploy、vefaas domains、vefaas env、vefaas config、vefaas app、vefaas overview、vefaas resource. Before continuing, MUST read Application workflow。

CRITICAL — Only when the user gives an existing function ID/name, or explicitly says "function / fn / pull function code / publish function / rollback function / function logs", follow the function workflow.

The function workflow uses vefaas fn ...、vefaas pull、vefaas push、vefaas deploy --funcId. Before continuing, MUST read Function management。

CRITICAL — When the user says "sandbox / sandbox instance / temporary instance / instance pause resume kill / sandbox image", follow the sandbox workflow.

The sandbox workflow must distinguish between sandbox application and sandbox instance; application ID and instance name cannot be used interchangeably. Before continuing, MUST read Sandbox management。

CRITICAL — When a high-level command can complete the task, do not directly use vefaas api。

Only use the OpenAPI workflow when high-level commands are missing, the user explicitly requests OpenAPI, or low-level action fields are needed. Before continuing, MUST read OpenAPI invocation, and first run vefaas api <Action> --help to view the parameter structure.

Required Reference protocol

Before executing the corresponding task, MUST read the corresponding reference; do not execute complex operations based only on the quick-reference commands in this file.

Scenario Required file
Answering questions, landing onboarding, checking official documentation, writing SDK/OpenAPI integration code Documentation search and doc-first
Install, upgrade, confirm CLI version CLI and versions
Log in, check credentials, restore authentication Authentication and credentials
Initialize template, deploy application, link, inspect, domains, application env/config Application workflow
Manage functions, code, publish, rollback, logs, invoke, config, scaling Function management
Function APIG triggers, sandbox gateway route configuration, APIG route binding and editing Triggers and APIG Route
Manage sandbox application / instance Sandbox management
Call veFaaS OpenAPI directly OpenAPI calls
Troubleshoot failures, diagnose environment Troubleshooting

Global execution rules

  • In non-interactive AI/CI scenarios, when the goal is clear, prefer adding --yes。
  • When output needs to be parsed, prefer using --output json, then combine with --jq、--fields、--limit。
  • When unsure about a command or flag, first run vefaas <command> --help, do not guess parameters.
  • When encountering issues with credentials, project configuration, local environment, or OpenAPI connectivity, first execute vefaas doctor。
  • --debug is for diagnosis only; debug output and ~/.vefaas/logs/ may contain sensitive request/response information.
  • Do not echo Access Key ID, Secret Access Key, session token, OAuth/OIDC token, database connection string,.env value in plaintext to the user.
  • vefaas doc series is read-only, login-free, not billed, can be called freely multiple times, and is not subject to the "high-risk operation protocol" below. When the agent uses documents for itself, always add -o json, read data.markdown(body) or data.results[](search results); only use the default text mode when the documents are to be rendered for a human to read.

Doc-first protocol

When it involves veFaaS concepts, capabilities, selection, billing, quotas, SDK usage, or OpenAPI parameters, MUST first use vefaas doc to search the official documentation, then answer or write code; it is forbidden to answer these specific facts directly from memory。

  1. Use built-in aliases to jump directly to high-frequency topics:intro(product introduction),quickstart(quick start),cli、sdk(SDK overview),api. Use subcommands for each SDK language vefaas doc sdk go|python|node -o json。
  2. For long-tail questions (billing, quotas, triggers, gateway, a specific feature), first vefaas doc search <关键词> -o json, from data.results[] by title + path(breadcrumbs) pick the most matchingleaf document, take its documentId, then vefaas doc --id <id> -o json read data.markdown。
  3. Q&A: answers must not go beyond data.markdown; billing/quotas/limits must cite the original numeric values from the documentation; append the source at the end of the answer data.url and update time data.updatedTime。
  4. Writing SDK/OpenAPI code: first obtain the official example (vefaas doc sdk go|python|node -o json) as the skeleton; use vefaas doc sdk methods <Action> -o json to look up the request fields for that Action (type + description + nesting), and you may add --lang to get a request example. It is forbidden to generate SDK calls from memory.
  5. vefaas doc --id Hitting a directory node will report not-found (directory nodes have no body) → return to the search results and choose a deeper leaf document.
  6. When search has no results, use vefaas doc tree -o json to browse the directory; if still not found, truthfully state that the official documentation does not cover it, do not fabricate.

For the complete three types of scenario workflows (landing / Q&A / SDK integration), see Document retrieval and doc-first。

High-risk operation protocol

The following operations affect online behavior or destroy resources. Before executing, the target resources and user intent must be confirmed:

  • Delete application, delete function, delete sandbox application, delete sandbox image.
  • kill / pause / resume sandbox instance。
  • Function or sandbox rollback.
  • Modify production environment triggers, etc.

Handling rules:

  1. First show the resource identifiers to be operated on (app/function/sandbox ID or name) and the action.
  2. If the target is not unique or the source is only a name spoken by the user, first use list/info to disambiguate.
  3. Execute only after the user explicitly confirms; do not silently add --yes to bypass confirmation.
  4. If the user refuses or the target is unclear, stop; do not guess a replacement target on your own.

Special rules for application deletion: Before deleting a veFaaS Application, first execute vefaas app delete --id <app-id> --check -o json to perform a pre-check. If the check finds shared or potentially continuously billed resources such as APIG/NAT/EIP, non-interactive scenarios must explicitly pass --ack-shared-resources; do not use the global --yes in place of this type of risk confirmation. Only when the user explicitly accepts skipping the pre-blocking should --force --yesbe used, and explain that associated resources may not be automatically cleaned up.

Target disambiguation rules

  • App name, function name, and sandbox name may not be unique; for write operations, prefer using IDs.
  • When there is only a name and no ID, first use list / info / config list / config pull to obtain the real resource information.
  • Deploying a new application requires a gateway name; first execute vefaas gateway list --first. If nothing is returned, stop and ask the user to provide an existing gateway or create a gateway first.
  • When .vefaas/config.json exists in the current directory, it does not necessarily mean it is the target the user wants to operate on; before online write operations, first vefaas config list confirm.
  • sandbox application ID and sandbox instance name are not interchangeable; before instance operations, first vefaas sandbox instance list --id <sandbox-application-id>。