Openclaw Kaipai AI

Kaipai Skill

When to Use This Skill

Activate when the user wants any of the following:

• Watermark removal on images or video (remove watermark, eraser watermark, etc.)
• Image quality restoration (restore, upscale, enhance, super-resolution)
• Video quality restoration (video restore, upscale, hdvideo-style enhancement)

Billing and user-facing claims (MANDATORY)

• Fact: Each successful run-task (including inside a sessions_spawn worker) goes through server-side quota / credit consumption for the MT_AK tenant. This is a paid, metered commercial API, not free compute bundled with the skill or the host.
• Forbidden: Do not state or imply that the service is free, costs nothing, uses no quota, has unlimited trial, or similar. Do not invent prices, plan names, promotions, or trial rules.
• Allowed: Neutral wording — e.g. processing uses the Kaipai account quota tied to the configured keys; billing and plans are per your console or administrator. If the user asks about cost, point them to admin / official billing docs / console; do not guess. When the API returns quota or membership errors, follow Step 3 — MANDATORY (quota / consume failures) using server detail and pricing_url when present.
• On success too: Success summaries must stay factual (task completed, delivery). Do not add “free” or zero-cost implications.

Supported Algorithms

Video tasks — default execution

For videoscreenclear and hdvideoallinone: spawn-run-task → pass sessions_spawn_args to sessions_spawn (main session does not block on run-task). Command shape, runTimeoutSeconds (default 3600), worker install-deps / run-task / Step 4, polling and recovery: §3b and docs/errors-and-polling.md.

Multi-stage pipelines (chaining tasks) / 多阶段管线

When the user asks for more than one Kaipai step on the same media (e.g. remove watermark then restore quality), treat each step as a separate job:

Rules:

1. After stage A completes with skill_status: "completed", use primary_result_url or output_urls[0] as --input for stage B with a new --task. That is a new job, not a retry of stage A. For video, stage B means a new spawn-run-task + sessions_spawn (each spawn embeds a single run-task), not a second run-task inside the same embed.
2. “Do not re-run run-task” in this skill means: do not submit run-task again for the same task_id / the same submitted job (use query-task to resume polling instead). It does not forbid the next pipeline stage with a different task_name and the previous result URL as input.
3. Step 4 (delivery): Prefer final-stage native delivery when the user wanted the full pipeline; intermediate stages may still run embedded Step 4 per worker (one spawn per video stage) — tune the user-facing copy if they only care about the last asset.
4. Video chains (medeo-style): One sessions_spawn = one embedded run-task. Do not put two run-task calls in one spawn. Chain = multiple spawns: after stage A, read primary_result_url from stdout or last-task / history, then spawn-run-task for stage B with that URL as --input. No video run-task in the main session. Optional one-line user update before the second spawn.

See also Step 3 success bullets and agent_instruction in the JSON.

API submission path (MANDATORY)

• New jobs: Submit only via python3 {baseDir}/scripts/kaipai_ai.py run-task … (§3a / §3b), or the same run-task command embedded in spawn-run-task → sessions_spawn. Do not hand-craft HTTP to wapi.kaipai.ai or AIGC / invoke endpoints to replace that flow — that skips POST /skill/consume.json (quota and permission) and breaks the supported pipeline.
• Exception: query-task --task-id is only for resuming status polling on an existing full task_id (no upload, no second consume). Do not use it instead of run-task for a new submission.
• No curl replay: This skill does not emit debug curl for API calls. Do not hand-craft HTTP to wapi / AIGC to mimic requests — always use the CLI above so /skill/consume.json runs before algorithm submit.

0. Pre-Flight Check (MANDATORY — run before anything else)

Verify AK/SK are configured (only run this command; do not read other Python sources first):

python3 {baseDir}/scripts/kaipai_ai.py preflight

• Output ok → continue to Step 1
• Output missing → stop and send the user the configuration message below

Feishu — send an interactive card via the Feishu API (do not use the message tool for this):

import json, urllib.request
cfg = json.loads(open("~/.openclaw/openclaw.json").read())
feishu = cfg["channels"]["feishu"]["accounts"]["default"]
token = json.loads(urllib.request.urlopen(urllib.request.Request(
    "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal",
    data=json.dumps({"app_id": feishu["appId"], "app_secret": feishu["appSecret"]}).encode(),
    headers={"Content-Type": "application/json"}
)).read())["tenant_access_token"]
card = {
    "config": {"wide_screen_mode": True},
    "header": {"title": {"tag": "plain_text", "content": "🖼️ Kaipai — credentials required"}, "template": "blue"},
    "elements": [{"tag": "div", "text": {"tag": "lark_md", "content": "Set **MT_AK** and **MT_SK** in `scripts/.env`, then run:\n```\nsource scripts/.env\n```\nIf you do not have keys, contact your administrator."}}],
}
urllib.request.urlopen(urllib.request.Request(
    "https://open.feishu.cn/open-apis/im/v1/messages?receive_id_type=open_id",
    data=json.dumps({"receive_id": "<USER_OPEN_ID>", "msg_type": "interactive", "content": json.dumps(card)}).encode(),
    headers={"Authorization": f"Bearer {token}", "Content-Type": "application/json"}
))

Telegram / Discord / other channels — use the message tool with plain text:

🖼️ Kaipai — credentials required

Set MT_AK and MT_SK in scripts/.env, then run:
  source scripts/.env

If you do not have keys, contact your administrator.

Step 1 — Pick task and input

Choose task_name from the table above and confirm the input file location.

Media type → task_name (MANDATORY checklist):

1. Video — Path or URL ends with common video extensions (e.g. .mp4, .mov, .webm, .mkv, .m4v) or the user / attachment clearly indicates video / clip / footage → choose only videoscreenclear (watermark) or hdvideoallinone (quality). Then use §3b (spawn-run-task + sessions_spawn), not blocking run-task in the main session.
2. Image — Extensions like .jpg, .jpeg, .png, .webp, .gif, .bmp or the user says photo / picture / screenshot / 图 (static image) → choose only eraser_watermark or image_restoration. Use §3a (run-task in the main session). Do not use spawn-run-task for these tasks (the CLI rejects it).
3. Watermark vs quality — “Remove watermark / 去水印” → eraser_watermark (image) or videoscreenclear (video). “Restore / upscale / enhance / 画质修复 / 清晰化” → image_restoration (image) or hdvideoallinone (video).
4. Uncertain — If media type is ambiguous (e.g. user only says “去水印” with no file), ask one short clarifying question (image or video?) or infer from IM attachment type per docs/im-attachments.md; do not guess the wrong modality.
5. Same message: video + extra still image — IM payloads often include both a video and a separate still (Feishu preview / image_key, Telegram or other cover / thumbnail, or an extra photo next to the clip). If the user’s wording targets the video (watermark or quality on the clip), use only that video as --input for videoscreenclear or hdvideoallinone (§3b). Do not submit eraser_watermark or image_restoration for the sibling image unless the user explicitly asks to process that picture too. Optional cover for sending the result is a delivery helper concern (docs/feishu-send-video.md, Telegram --cover-url), not a second Kaipai job.

Getting media from IM messages (full detail: docs/im-attachments.md):

python3 {baseDir}/scripts/kaipai_ai.py resolve-input --file /tmp/saved.jpg --output-dir /tmp
# or: --url, --telegram-file-id, --feishu-image-key + --feishu-message-id

Use the JSON path field as --input.

--input as http(s):// URL: In shells, quote the whole URL so & in query strings (e.g. signed OSS links) is not split. Large or slow downloads: defaults are 120s read timeout and 100MB max (same as resolve-input --url); override with MT_AI_URL_READ_TIMEOUT, MT_AI_URL_CONNECT_TIMEOUT, MT_AI_URL_MAX_BYTES. For very large video or flaky links, prefer resolve-input --url then --input with the local path.

If the user already gave a path or URL when triggering the skill, go to Step 2 without asking again.

Reply immediately to acknowledge the task, for example:

"🖼️ Processing — please wait a moment…"

Step 2 — Install dependencies

python3 {baseDir}/scripts/kaipai_ai.py install-deps

If dependencies are already installed this step is quick; then continue to Step 3.

Step 3 — Run the task

If task is videoscreenclear or hdvideoallinone, use only §3b (spawn-run-task + sessions_spawn). Use §3a only for image tasks (eraser_watermark, image_restoration).

3a — Inline (blocking, image tasks only)

Use when the host can wait on the shell until the command returns (eraser_watermark, image_restoration).

python3 {baseDir}/scripts/kaipai_ai.py run-task \
  --task "<task_name>" \
  --input "<image_url_or_path>"

Replace <task_name> and <image_url_or_path> with the real values.

Default params include rsp_media_type: url. For custom JSON params:

python3 {baseDir}/scripts/kaipai_ai.py run-task \
  --task "<task_name>" \
  --input "<url_or_path>" \
  --params '{"parameter":{"rsp_media_type":"url"}}'

When run-task exits 0, stdout is JSON that includes:

• skill_status: "completed" — the algorithm and polling are finished; the result is in this response. If the user asked for only this stage, proceed to Step 4. If they asked for a multi-stage pipeline, use primary_result_url as --input for the next --task (see Multi-stage pipelines above); Step 4 after the last stage. Do not re-submit run-task for the same task_id (same job); use query-task to resume polling if needed.
• output_urls — ordered http(s) links (same extraction as before: data.result.urls, images, media_info_list, etc.).
• primary_result_url — same as output_urls[0] when present; convenient for delivery scripts.
• task_id — full task id as a top-level string when known (from data.result.id or the polling session). Keep it for manual status recovery or support handoff; do not truncate. Some synchronous completions may omit it if the API does not return an id.
• agent_instruction — short reminder for the model.
• meta / data — full API payload for debugging.

MANDATORY (user-visible outcome): When stdout JSON has skill_status: "completed" (from run-task or query-task), you must (1) send the user a short natural-language summary (success + what was done), and (2) complete Step 4 on their channel (delivery scripts below) using primary_result_url or output_urls[0], unless the user explicitly asked only for the URL with no IM delivery. Do not end the turn with only raw JSON in the tool transcript — the user should see a normal reply and the media or link in the chat.

When run-task exits non-zero, stdout is JSON with skill_status: "failed" (or an error field) — explain it to the user; do not treat as success or Step 4 delivery.

MANDATORY (quota / consume failures): When stdout JSON has failure_stage: "consume_quota" and error is credit_required (typically api_code 60002): you must send the user a clear, user-visible message grounded in the server detail (API msg). If the JSON includes pricing_url (extracted from that message when it contains an https link), must include it as a clickable link; if pricing_url is absent, must quote or paste the full detail so any links or instructions from the API still reach the user. Do not only dump raw JSON; do not retry run-task expecting success from tweaking --task / --params alone. When error is membership_required (60001): same rule (pricing_url when present, else full detail). When error is consume_param_error: treat as parameter / invocation mistakes — fix --task, --input, --params per SKILL and remote config; do not tell the user to recharge.

Video tasks use §3b in the main session. Polling, stderr, MT_AI_*, timeouts, SIGKILL / host caps, query-task / last-task recovery: docs/errors-and-polling.md and §3c–§3d. Optional: raise host tool/session wait limits — does not replace §3b for video.