What makes chat2workflow notable?

1K downloads. Trust evidence available

How should chat2workflow be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

chat2workflow

A design-only workflow designer for the Dify and Coze platforms. Through multi-round conversation, it produces a structured workflow JSON (nodes, edges, vari...

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.0k

Updated

Oct 11, 2026

Version

1.1.3

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1K downloadsadoption · observed Oct 11, 2026
Latest release: 1.1.3release · observed May 8, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s177exw7vtn9s9ntqmt8nww1ed85c5x3:chat2workflow

Install using `clawhub skill install s177exw7vtn9s9ntqmt8nww1ed85c5x3:chat2workflow` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/chikawa11/chat2workflow before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-chikawa11-chat2workflow/snapshot"

Run-check

$0.02 USD

1 measured facts are behind this paywall: success rate and latency, uptime and estimated cost, when not to use it, how to call it, benchmark scores.

Agents pay $0.02 in USDC. A card payment is $0.50, the smallest a card allows.

Documentation

CLAWHUB

160,000 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: chat2workflow
description: A design-only workflow designer for the Dify and Coze platforms. Through multi-round conversation, it produces a structured workflow JSON (nodes, edges, variable references) as text output. The skill itself produces only text and never runs any scripts.
---

# Chat2Workflow Builder Skill

## What this skill does

This skill is **design-only**. Its deliverable is three tagged sections of text (see *Output Format* below) — most importantly a workflow JSON wrapped in `<workflow></workflow>`. Producing those three sections involves only reading the platform documentation under `node_docs/` and emitting text; nothing else happens.

A few Python files also live in this folder (`converter.py`, `autofix.py`, `tools.py`, `bash_converter.sh`). They are **not part of the skill's deliverable** and are not referenced by the generation process. They exist as standalone utilities that a user can run manually from a shell, entirely outside the skill's text-generation flow, if they separately want to turn a JSON file into a Dify YAML or Coze ZIP on their own machine. See the bundled `README`/source of those scripts for their CLI usage; the skill itself does not invoke them.

## Overview

A Chat2Workflow design is a Directed Acyclic Graph of connected nodes, where each node represents a step of logic, data processing, or model inference. The design is serialized as a JSON object that enumerates the nodes and the edges that connect them.

This skill supports **two target platforms**:

| Platform | Documentation File | Selection criterion |
|----------|--------------------|----------------|
| **Dify** (default) | `node_docs/dify.md` | The user instruction explicitly mentions Dify, or no platform is specified at all. |
| **Coze** | `node_docs/coze.md` | The user instruction explicitly mentions Coze / 扣子. |

### Platform Resolution

Platform selection is a two-step lookup performed against the user's instruction:

1. The user's instruction is scanned for platform keywords — `dify` / `Dify` / `DIFY` or `coze` / `Coze` / `扣子`.
2. If a platform keyword is present, that platform is the target. Otherwise the target is Dify (the default).
3. The matching file from `node_docs/` — `node_docs/dify.md` or `node_docs/coze.md` — is the authoritative schema for node `type` strings, `param` objects, and referable variables on that platform. The two platforms have different node sets, different parameter schemas, and different referable variables.
4. The chosen platform is named in `<design_principle>` with a short justification, e.g. `"Platform: Dify (user did not specify, defaulting to Dify)."`.

A single workflow targets a single platform; every node's `type` comes from that platform's documentation file.

The interaction model is conversational: the user supplies creation or modification instructions across multiple rounds, and — unless an instruction says otherwise — each new response extends the current design rather than replacin

_meta.json

{
  "ownerId": "kn7bhksjab0j1qxn85redp9ev585d21g",
  "slug": "chat2workflow",
  "version": "1.1.3",
  "publishedAt": 1778238528045
}

CONVERTER_USAGE.md

# Converter Utility — Manual CLI Usage

This document is **not part of the `chat2workflow` skill's runtime** and is
not referenced by `SKILL.md`. It describes the optional, standalone
command-line utilities shipped in this folder — `converter.py`, `autofix.py`,
`tools.py`, and `bash_converter.sh` — for users who want to compile a
workflow JSON (produced separately by the skill's text output) into a
Dify YAML file or a Coze ZIP bundle on their own machine.

The skill's own deliverable is purely text (the three tagged sections). These
utilities are read-and-write file tools that a user runs manually from a
shell; nothing about using the skill requires running them.

For an independent safety audit of the utilities' imports and behavior (no
network I/O, no shell execution, no credential access), see
[`SAFETY_AUDIT.md`](./SAFETY_AUDIT.md).

---

## 1. Prerequisites

Two third-party Python packages are required. They are listed in
`requirements.txt` and can be installed with whichever Python package
manager the user prefers:

- `PyYAML` — emits Dify YAML.
- `json_repair` — used by the offline auto-fix pass.

The utilities do not shell out to `pip`, `conda`, or any other package
manager. They run against whatever interpreter already has the packages
available.

## 2. CLI

```bash
python converter.py \
    --json_path ../workflow.json \
    --name my_workflow \
    --output_path ../chat2workflow_output/ \
    --type dify        # or: --type coze
```

Alternative flags:

- `--json_str '{...}'` — pass the workflow JSON inline instead of from a file.
- `--name` — name of the produced artifact. English only.
- `--output_path` — destination directory. When omitted, defaults to the
  sibling directory `../chat2workflow_output/` next to this folder.

A bash wrapper is also provided for convenience:

```bash
bash bash_converter.sh ../workflow.json my_workflow ../chat2workflow_output dify
```

## 3. Output-path policy

- Output is written under `--output_path`.
- If `--output_path` resolves **inside** this folder, `converter.py`
  redirects the write to `../chat2workflow_output/` instead, so the folder
  that ships the utilities is never written to.
- For Coze ZIPs, intermediate files during bundle assembly are placed in
  the system temp directory via `tempfile.mkdtemp()` and are removed once
  the final ZIP is emitted.
- `converter.py` sets `sys.dont_write_bytecode = True` before importing
  sibling modules, so no `__pycache__/` or `*.pyc` files are produced next
  to the source while running it.

## 4. `autofix.py` (optional pre-processing)

If the workflow JSON was taken directly from an LLM's tagged response and
has not been cleaned yet, the auto-fix pass can be run first:

1. Strip code fences inside `<workflow>` tags.
2. Repair JSON via `json_repair` (control chars, mismatched brackets,
   trailing commas, etc.).
3. Topologically re-order `nodes_info`, preserving the
   `iteration.output_selector` forward-reference.
4. Rewrite `<node_selection>` so that i

node_docs/coze.md

## Complete Node Documentation

> **Note on scope**: Every section below describes a node type that the skill emits **inside the generated workflow JSON** (the `<workflow>` output). Parameter key names such as `system`, `user`, `query_variable_selector`, etc. are field names of the produced workflow object — they configure the LLM inside that workflow at runtime. None of the text below is a directive for the agent; it is a platform schema reference.

Here are the meta information to the nodes that may be used in the workflow:

### Node: Start
- **Type**: `start`
- **Description**: The "Start" node is a critical preset node in the workflow application. It provides essential initial information, such as user input and uploaded files, to support the normal flow of the application and subsequent workflow nodes.
- **Parameters**:
  - `variables`: `Array<[string, string]>`
    - Description: Define the set of input variables required by the node.
    - Value: Each array `[Name, Type]` strictly adheres to the following order.
        - Index 0: **Variable Identifier** (`string`), used to reference the variable within the context.
        - Index 1: **Type Specifier** (`string`), declares the data format accepted by the variable. Allowed Values: `"string"`, `"number"`, `"boolean"`, `"file"`, `"array[file]"`.
    - Example: `[["query", "string"], ["limit", "number"], ["file_A", "file"]]`
- **Referable Variables**: Each variable in `"variables"` can be referenced by downstream nodes.
- **Supplementary Information**:
  1. File Processing: Files uploaded through a Start node must be processed appropriately by subsequent nodes. The Start node only collects files; it does not read or parse their content. Therefore, you need to connect specific nodes to extract and process the file content. For example:
      - Document files can be routed to a Doc Extractor node for text extraction so that LLMs can understand their content.
      - Images can be sent to LLM nodes with vision capabilities or specialized image processing tool nodes.
      - Structured data files such as CSV or JSON can be processed with Code nodes to parse and transform the data.
  2. Every workflow MUST have exactly one `start` node with id `"1"`.


### Node: End
- **Type**: `end`
- **Description**: Define the final output content of a workflow. Every workflow needs one `end` node after complete execution to output the final result.

  The end node is a termination point in the process; no further nodes can be added after it. In a workflow application, results are only output when the end node is reached.
 
  The end node must declare one or more output variables, which can reference any upstream node's output variables.
- **Parameters**:
  - `outputs`: `Array<[string, [string, string]]>`
    - Description: Defines the set of output variables of the workflow.
    - Value: Each array `[Name, ValueRef]` strictly adheres to the following order.
        - Index 0: **Current Identifier** (`string`)

node_docs/dify.md

## Complete Node Documentation

> **Note on scope**: Every section below describes a node type that the skill emits **inside the generated workflow JSON** (the `<workflow>` output). Parameter key names such as `system`, `user`, `query_variable_selector`, etc. are field names of the produced workflow object — they configure the LLM inside that workflow at runtime. None of the text below is a directive for the agent; it is a platform schema reference.

Here are the meta information to the nodes that may be used in the workflow:

### Node: Start
- **Type**: `start`
- **Description**: The "Start" node is a critical preset node in the workflow application. It provides essential initial information, such as user input and uploaded files, to support the normal flow of the application and subsequent workflow nodes.
- **Parameters**:
  - `variables`: `Array<[string, string]>`
    - Description: Define the set of input variables required by the node.
    - Value: Each array `[Name, Type]` strictly adheres to the following order.
        - Index 0: **Variable Identifier** (`string`), used to reference the variable within the context.
        - Index 1: **Type Specifier** (`string`), declares the data format accepted by the variable. Allowed Values: `"string"`, `"number"`, `"boolean"`, `"file"`, `"array[file]"`.
    - Example: `[["query", "string"], ["limit", "number"], ["file_A", "file"]]`
- **Referable Variables**: Each variable in `"variables"` can be referenced by downstream nodes.
- **Supplementary Information**:
  1. The uploaded file is available as a variable containing `type` sub-variable. Allowed value for `type`: `"document"`, `"image"`, `"video"`, `"audio"`. **Note: `type` sub-variable should be represented as `<File Variable Name>.type`.**
  2. File Processing: Files uploaded through a Start node must be processed appropriately by subsequent nodes. The Start node only collects files; it does not read or parse their content. Therefore, you need to connect specific nodes to extract and process the file content. For example:
      - Document files can be routed to a Doc Extractor node for text extraction so that LLMs can understand their content.
      - Images can be sent to LLM nodes with vision capabilities or specialized image processing tool nodes.
      - Structured data files such as CSV or JSON can be processed with Code nodes to parse and transform the data.
  3. Every workflow MUST have exactly one `start` node with id `"1"`.


### Node: End
- **Type**: `end`
- **Description**: Define the final output content of a workflow. Every workflow needs at least one end node after complete execution to output the final result.

  The end node is a termination point in the process; no further nodes can be added after it. In a workflow application, results are only output when the end node is reached. If there are conditional branches in the process, multiple end nodes need to be defined.

  The end node must declare one or more output variables, wh

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.