Dify Workflow DSL Generator

The Problem

Dify workflow exports are YAML app definitions that include app metadata, dependencies, variables, workflow.graph.nodes, and edges. Hand-writing them is error-prone: unstable node IDs, mismatched sourceHandle / targetHandle values, missing plugin dependencies, value_selector written as plain strings, or applying advanced-chat conversation rules to workflow apps. This skill targets those failure modes and helps generate an import-ready Dify DSL draft.

How It Works And Where It Falls Short

It starts by clarifying import-blocking details: app mode, required inputs, model/provider, plugins, knowledge bases, secrets, and expected outputs. Then it sketches the node graph for version: "0.6.0", uses stable string node IDs, and checks that every edge references existing nodes with compatible data types.

• Nodes and edges: covers LLM, tool, code, branch, and iteration nodes, with attention to provider_id, tool_name, tool_parameters, value_selector, sourceHandle, and related fields.
• Dependencies: adds marketplace, package, or github dependencies for plugin-backed models, tools, and knowledge features.
• Safety and importability: avoids hardcoding API keys or database passwords; prefers parameterized SQL and limits LLM-generated SQL to SELECT unless the user explicitly accepts write risk.
• Validation output: reports the written YAML path and validation result, and marks unknown plugins as needing Dify import testing.

It is useful for generating or patching Dify DSL, but a tool name alone is not a complete schema. For Marketplace, .difypkg, GitHub plugin, or unknown tools, provide a minimal exported DSL, plugin package, or source when possible to reduce missing-field risk.