← 返回 Skills 市场
alesys

Knods

作者 Rolf · GitHub ↗ · v1.0.2 · MIT-0
linux ⚠ suspicious
355
总下载
0
收藏
0
当前安装
3
版本数
在 OpenClaw 中安装
/install knods
功能描述
Build and modify Knods visual AI workflows using either the OpenClaw Gateway polling protocol or the Knods headless flows API. Use for Knods polling payloads...
使用说明 (SKILL.md)

Knods

Overview

Handle two Knods modes:

  1. Interactive canvas chat via the polling gateway
  2. Headless flow execution via the REST API

Use the polling bridge for Knods Iris/chat payloads. Use the headless API when the task is to discover a flow, inspect inputs, run it, wait, cancel, or fetch outputs programmatically.

Mode Selection

  • Use polling gateway mode when input arrives as a Knods chat envelope with messageId, message, and history, and the response must stream back with optional [KNODS_ACTION]...[/KNODS_ACTION].
  • Use headless API mode when the user wants to:
    • list flows
    • search flows by name/description
    • inspect a flow's input schema
    • start a run
    • poll until completion
    • cancel a run
    • retrieve outputs programmatically

Workflow

A. Polling Gateway Flow

  1. Parse incoming payload fields.
  • Treat message as the primary request.
  • Use history for continuity.
  • On first turn in a conversation, expect prepended context in message describing node types and action rules. Always prefer the node catalog from this context over the defaults below.
  • Use messageId to map all response chunks to the correct message.
  1. Choose whether to emit a canvas action block.
  • Use addNode for single-node additions.
  • Use addFlow for multi-node workflows or any request requiring edges.
  • If the user only asks a question, respond with normal text and no action block.
  1. Build strict action JSON.
  • Wrap each action exactly as:
    • [KNODS_ACTION]{"action":"addNode","nodeType":"FluxImage"}[/KNODS_ACTION]
    • [KNODS_ACTION]{"action":"addFlow","nodes":[...],"edges":[...]}[/KNODS_ACTION]
  • Use "nodeType" (not "type") in node objects. Do NOT include position or data fields — Knods handles layout automatically.
  • For addFlow, ensure every edge source and target references an existing node id.
  • Always end flows with an Output node.
  • Never connect two generator nodes directly; route through Output.
  • Use stable node IDs (for example n1, n2, n3) so follow-up edits are easy.
  • Avoid unknown keys in action JSON.
  1. Stream response back to Knods.
  • Send assistant text as delta chunks to /respond for the same messageId.
  • Send {"messageId":"...","done":true} when complete.
  • Keep first chunk quick to avoid timeout perception.

B. Headless API Flow

  1. Discover candidate flows.
  • Run:
    • python3 {baseDir}/scripts/knods_headless.py list
    • or python3 {baseDir}/scripts/knods_headless.py resolve --query "\x3Ctext>"
  1. Inspect the selected flow.
  • Run:
    • python3 {baseDir}/scripts/knods_headless.py get --flow-id "\x3CflowId>"
  • Read inputs and preserve every nodeId exactly.
  1. Start a run.
  • Build inputs as JSON array with nodeId, content, and type.
  • Run:
    • python3 {baseDir}/scripts/knods_headless.py run --flow-id "\x3CflowId>" --inputs-json '[...]'
  1. Poll until terminal state.
  • Prefer:
    • python3 {baseDir}/scripts/knods_headless.py wait --run-id "\x3CrunId>"
  • Or use:
    • python3 {baseDir}/scripts/knods_headless.py run-wait --flow-id "\x3CflowId>" --inputs-json '[...]'
  1. Handle result.
  • On completed, read outputs
  • On failed, surface error.message and error.nodeId if present
  • On timeout, optionally cancel the run

Output Rules

  • Return normal assistant text; do not wrap the full reply in a custom envelope.
  • Include [KNODS_ACTION]...[/KNODS_ACTION] inline only when a canvas mutation is intended.
  • Do not mention internal polling URLs/tokens in user-facing text.
  • Keep action JSON valid and compact.

Node Catalog

IMPORTANT: Every generator node listed below has a built-in prompt textarea. Do NOT add a DocumentPanel before a single generator — just connect the generator directly to an Output. Only use DocumentPanel when one shared prompt feeds multiple generators in parallel.

When the first message includes a node catalog context, always use that list over these defaults. The context catalog is always more up-to-date.

Text Generators (output: text)

All text generators accept text + image input and have a built-in prompt textarea.

  • ChatGPT — OpenAI models. Best all-rounder.
  • Claude — Anthropic models. Great for reasoning and creative writing.

Image Generators (output: image)

All image generators have a built-in prompt textarea and accept optional image input for image-to-image editing.

  • GPTImage — OpenAI. Best at following complex instructions and text rendering.
  • FluxImage — FLUX by Black Forest Labs. Industry-leading quality for portraits and artistic styles. Fast.
  • ImagePrompt — Google Gemini. Great for photorealistic images and concept art.
  • ZImageTurbo — Lightning-fast (\x3C2 seconds). Best for rapid prototyping.
  • QwenImage — Alibaba Qwen. Strong at anime, illustrations, and Asian-inspired aesthetics.
  • Seedream — ByteDance. Dreamy, surreal compositions. Good at text rendering in images.
  • GrokImage — xAI. Text-to-image and image editing.

Video Generators (output: video)

All video generators below have a built-in prompt textarea and support both text-to-video and image-to-video (connect an ImagePanel for image-to-video).

  • Veo3FalAI — Google Veo 3.1. Cinematic video up to 8s with native audio. Best overall quality.
  • Sora2Video — OpenAI Sora 2. Realistic motion and physics, up to 12s.
  • Kling26Video — Kling 2.6 Surreal Engine. Cinematic with audio, up to 10s.
  • KlingO3Video — Kling 3.0. Latest generation, Standard/Pro quality, up to 10s.
  • Wan26Video — Wan 2.6. Multi-shot videos, 720p/1080p, up to 15s.
  • LTXVideo — LTX-2 Pro. High-fidelity cinematic with synchronized audio.
  • GrokVideo — xAI. Video with native audio.

Special Video Node

  • WanAnimateVideo — Character animation. REQUIRES two inputs: a VIDEO (motion reference) + an IMAGE (character to animate). Does NOT have a text prompt. Only use when user wants to animate a character image using motion from another video.

Input/Container Nodes

  • ImagePanel — Upload or paste an image. Output: image. Use when user wants to provide a reference image or a starting frame for image-to-video.
  • DocumentPanel — Editable text container. Output: text. Use ONLY when one shared prompt feeds multiple generators in parallel.
  • Output — Displays generated results (text, image, video). REQUIRED at the end of every flow.

Flow Design Rules

  1. Every generator has a built-in prompt textarea. Never prepend a DocumentPanel to a single generator.
  2. Use DocumentPanel only for one shared prompt feeding multiple generators in parallel.
  3. Use ImagePanel when user wants to provide a reference image, a starting frame for video, or an image input for WanAnimateVideo.
  4. Always end flows with an Output node.
  5. Never connect two generators directly. Route through an Output node if chaining.
  6. Flows go left to right: inputs → generators → Output.
  7. Use EXACT PascalCase node names from the catalog. Do NOT invent node names.
  8. WanAnimateVideo is the only node that requires a video input. Only suggest it when the user specifically wants to animate a character image using motion from a video.
  9. Add initialData only when user intent clearly implies parameters.
  10. Build the smallest flow that satisfies the request.

Flow Examples

Single image generator (most common):

FluxImage → Output

Image from reference photo:

ImagePanel → GPTImage → Output

One prompt feeding two image generators:

DocumentPanel → FluxImage → Output
DocumentPanel → GPTImage → Output

Text-to-video:

Veo3FalAI → Output

Image-to-video (animate a still image):

ImagePanel → Veo3FalAI → Output

Character animation from video motion (WanAnimateVideo needs both video + image):

ImagePanel → WanAnimateVideo → Output
[video source] → WanAnimateVideo

Text generation:

ChatGPT → Output

Gateway Behavior Constraints

  • Poll interval target: about 1-2 seconds.
  • Message claim timeout: about 2 minutes.
  • Always preserve messageId across all chunk posts for a turn.
  • Gateway auth uses gw_... token via query parameter token; never require Supabase JWT in this flow.

Runtime Operations

When running a persistent poller service/process:

  • Support either configuration style:
    • KNODS_BASE_URL already includes /updates?token=...
    • or KNODS_BASE_URL points to connection base and token is supplied separately (KNODS_GATEWAY_TOKEN)
  • Derive /respond from the same connection root as /updates.
  • Log handled messageId values and transport errors for debugging.

For headless API operations:

  • Prefer KNODS_API_BASE_URL + KNODS_API_KEY
  • KNODS_API_BASE_URL should look like https://\x3Cinstance>/api/v1
  • KNODS_API_KEY must have knods:read and knods:run
  • If the API base URL is omitted, the packaged client can derive it from the same host as KNODS_BASE_URL

Packaged Runtime (required)

This skill ships the runtime bridge and installer:

  • scripts/knods_iris_bridge.py
  • scripts/knods_headless.py
  • scripts/install_local.sh

Install/deploy from the skill folder:

bash /home/rolf/.openclaw/skills/knods/scripts/install_local.sh

The installer deploys:

  • ~/.openclaw/scripts/knods_iris_bridge.py
  • ~/.config/systemd/user/knods-iris-bridge.service

Then runs:

  • systemctl --user daemon-reload
  • systemctl --user enable --now knods-iris-bridge.service

Environment Variables

Set these in ~/.openclaw/.env:

  • Required for polling gateway mode:
    • KNODS_BASE_URL
  • Required when KNODS_BASE_URL does not already include ?token=...:
    • KNODS_GATEWAY_TOKEN
  • Required for headless API mode:
    • KNODS_API_KEY
  • Preferred for headless API mode:
    • KNODS_API_BASE_URL
  • Optional:
    • OPENCLAW_AGENT_ID (default: iris)
    • OPENCLAW_BIN (default: openclaw on PATH)

Service Operations

  • Status:
    • systemctl --user status knods-iris-bridge.service
  • Restart:
    • systemctl --user restart knods-iris-bridge.service
  • Logs:
    • journalctl --user -u knods-iris-bridge.service -f

Config Change Lifecycle (required)

After changing gateway URL/token env values, restart the running bridge process so it reloads config.

  • Generic service form:
    • systemctl --user restart \x3Cknods-bridge-service>
  • Generic process form:
    • stop old process
    • start poller again with updated env

Do not assume env changes are picked up live without restart.

Reference

  • Read references/protocol.md for canonical polling endpoints, payload schemas, and action examples.
  • Read references/headless-api.md for the direct run/list/poll/cancel flow execution API.
安全使用建议
This skill appears to implement the described Knods polling bridge and headless client, but before installing you should: 1) Inspect and confirm the environment variables you will store in ~/.openclaw/.env — the headless client requires KNODS_API_KEY and the bridge may need KNODS_GATEWAY_TOKEN (metadata only lists KNODS_BASE_URL). 2) Only run the installer if you intend to allow a persistent systemd --user service that will poll your Knods instance and call the local openclaw CLI; the service runs as your user and will read any tokens in the env file. 3) If you only need one-off headless commands, avoid running install_local.sh and use the scripts directly (python3 scripts/knods_headless.py ...). 4) Audit OPENCLAW agent(s) you will invoke (OPENCLAW_AGENT_ID) because the bridge invokes the openclaw CLI which can run arbitrary agent logic. 5) If you are concerned about missing metadata, request the publisher update registry requirements to include KNODS_API_KEY and KNODS_GATEWAY_TOKEN so you know what secrets are needed. If you want, test first with dry-run/--once modes and with non-production tokens to verify behavior.
功能分析
Type: OpenClaw Skill Name: knods Version: 1.0.2 The skill implements a persistent bridge between OpenClaw and the Knods AI platform, which involves high-risk operations including the automated installation of a systemd user service for persistence (scripts/install_local.sh) and the execution of local binaries via subprocesses triggered by remote polling data (scripts/knods_iris_bridge.py). While these capabilities are aligned with the stated purpose of maintaining a background polling service, the combination of automated persistence and remote-to-local execution triggers constitutes a significant attack surface. No evidence of intentional malice, such as data exfiltration or unauthorized credential theft, was identified.
能力评估
Purpose & Capability
The files (polling bridge + headless client + installer) align with the description: python scripts implement polling gateway and headless API functions and the README/SKILL.md document that behavior. However, metadata lists only KNODS_BASE_URL as a required env var and lists systemctl as a required binary — systemctl is only needed by the provided install_local.sh (installer), not for headless usage. Also the headless client actually requires KNODS_API_KEY (or CLI --api-key) to work, but that env var is not declared in the registry metadata, which is inconsistent.
Instruction Scope
SKILL.md and the scripts restrict actions to the Knods gateway and Knods headless API. The polling bridge reads a local env file (~/.openclaw/.env) and calls the OpenClaw agent CLI to generate responses; the headless client reads env and talks to the configured Knods API. No instructions attempt to read arbitrary system files or contact unrelated third-party endpoints.
Install Mechanism
There is no remote download/install spec in the registry (instruction-only plus bundled scripts), which reduces supply-chain risk. The included install_local.sh creates a systemd user service and installs the bridge into ~/.openclaw/scripts; that is local and transparent but does give the skill a persistent background presence if you run the installer.
Credentials
The registry metadata declares only KNODS_BASE_URL as required, but the headless client requires KNODS_API_KEY (or --api-key) and the bridge may require KNODS_GATEWAY_TOKEN (or a token in KNODS_BASE_URL). README lists multiple env vars (KNODS_API_BASE_URL, KNODS_API_KEY, KNODS_GATEWAY_TOKEN, OPENCLAW_AGENT_ID). Requiring secrets (API keys / gateway tokens) is reasonable for a connector, but the metadata is incomplete and could mislead users about what secrets will be needed and where they should be stored.
Persistence & Privilege
The installer writes a systemd user unit and enables it (systemctl --user enable --now), creating a persistent polling bridge process that will autonomously poll the Knods gateway and invoke the local OpenClaw agent CLI. This persistent autonomous behavior is expected for a gateway bridge, but it increases the attack surface (long-running process reading env file with tokens and invoking local agent). The skill does not request platform 'always: true' and does not modify other skills.
如何使用
  1. 确保已安装 OpenClaw(本地或 Docker 部署)
  2. 在对话框中输入安装命令:/install knods
  3. 安装完成后,直接呼叫该 Skill 的名称或使用 /knods 触发
  4. 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
版本历史
v1.0.2
Add headless Knods flow execution support, packaged API reference, CLI client, and GitHub README.
v1.0.1
Declare required bins/env in metadata and clean packaged artifacts.
v1.0.0
Initial packaged release with bridge runtime, installer, and env/service instructions.
元数据
Slug knods
版本 1.0.2
许可证 MIT-0
累计安装 0
当前安装数 0
历史版本数 3
常见问题

Knods 是什么?

Build and modify Knods visual AI workflows using either the OpenClaw Gateway polling protocol or the Knods headless flows API. Use for Knods polling payloads... 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 355 次。

如何安装 Knods?

在 OpenClaw 或 Claude Code 对话框中运行命令「/install knods」即可一键安装,无需额外配置。

Knods 是免费的吗?

是的,Knods 完全免费,采用 MIT-0 许可证,可自由下载、安装和使用。

Knods 支持哪些平台?

Knods 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(linux)。

谁开发了 Knods?

由 Rolf(@alesys)开发并维护,当前版本 v1.0.2。

💬 留言讨论