Dify Workflow Generator (dify_creator)

Guide users to clarify requirements through multi-round conversations, refer to existing cases in the
organized_dsl/
directory, and generate DSL YAML files that comply with the corresponding Dify version specifications, which can be directly imported into Dify for use.

⚠️ Important: You must switch to the skill directory before searching for files!
bash
cd "c:\Users\14429\.claude\skills\dify_creator"
Then search for
organized_dsl/INDEX.md
and
organized_dsl/**/*.yml

Core Capabilities

Intelligent Conversation Guidance: Help users sort out requirements through questions to avoid missing key information
Case Reference Location: Automatically match similar Dify cases based on the INDEX.md index
Workflow Structure Design: Provide a process structure after analyzing requirements and confirm with users
Complete DSL Generation: Generate complete YAML configurations that meet specifications by referring to the DSL Node Guide

Use Cases

Create intelligent customer service conversation flows
Build RAG knowledge base question answering systems
Design audio and video processing workflows
Develop code generation and document processing tools
Build complex workflows with multi-model collaboration

Workflow Overview

User Requirements → Case Location → Process Design → User Confirmation → DSL Generation → Delivery

Core Steps

Step	Name	Output
Step 1	Requirement Collection	Requirement Document
Step 2	Case Location	Reference Case List
Step 3	Process Design	Process Structure Diagram
Step 4	User Confirmation	Confirmation Feedback
Step 5	DSL Generation	Complete YAML File

Step 1: Collect User Requirements

First, ask users for basic information to clarify the goals and functions of the workflow.

1.1 Basic Information Collection

markdown

Please tell me the basic information about the Dify workflow you want to create:

1. **Workflow Name** (English, use hyphens, e.g., document-processor)
2. **One-sentence Description**: What does this workflow do?
3. **Application Type**:
   - workflow: Batch processing task, single-round execution
   - advanced-chat: Advanced chat mode, supports multi-round conversations
   - chatflow: Conversational application, simple multi-round interaction
4. **Target Users**: Who will use this workflow?

1.2 Functional Requirement Collection

Based on the application type selected by the user, ask in-depth functional requirements:

General Questions:

markdown

5. **Input Method**: How will users provide input?
   - Text input (short text/long text)
   - File upload (image/PDF/audio-video/document)
   - Mixed input

6. **Core Processing**: What processing steps does the workflow need to perform?
   - Data preprocessing → Core processing → Result output
   - Please describe each step as much as possible

7. **Output Format**: What results will be returned finally?
   - Text response
   - Structured data (JSON/Markdown table)
   - File (image/PDF/audio)
   - Mixed output

Supplementary Questions by Function Type:

Function Type	Supplementary Questions
RAG Q&A	Knowledge base source? Retrieval strategy (keyword/vector)? Number of recalls? Is re-ranking needed?
Audio-Video Processing	Audio extraction? Speech recognition (ASR)? Content summarization? Subtitle generation?
Document Processing	PDF parsing? Content extraction? Format conversion? OCR recognition?
Image Generation	Text-to-image? Image-to-image? Style transfer? Is multi-image combination needed?
Data Processing	Data source (API/database/file)? Analysis dimensions? Chart type?
Tool Calling	Which tools/plugins are used? Calling frequency? Is MCP needed?
Multi-Model Collaboration	Which models are called? What are their divisions of labor? How do models transfer information between each other?

1.3 Model and Tool Configuration

markdown

8. **Large Model Selection**:
   - Model Provider: OpenAI / Anthropic / Domestic Models (SiliconFlow/Qwen/ZeroOneAI, etc.)
   - Model Name: e.g., gpt-4o, deepseek-V3, qwen-max
   - Parameter Settings: temperature (creativity 0-1), max_tokens, etc.

9. **Tools/Plugins**:
   - Built-in Tools: Code execution, knowledge retrieval, HTTP request, TTS, etc.
   - Third-party Plugins: PDF processing, database connection, etc.
   - MCP Service: Is external MCP tool integration needed?

10. **Knowledge Base (Optional)**:
    - Is knowledge base access needed?
    - Knowledge Base ID and Name
    - Retrieval Strategy Configuration

1.4 Process Control Inquiry

markdown

11. **Process Branches**: Are there conditional branches? (Yes/No)
    - If yes, what are the branch conditions? (e.g., different processing paths based on user intent classification)
12. **Loop Processing**: Is iterative processing of batch data needed? (Yes/No)
    - e.g., Batch processing multiple files, processing each item in a list
13. **Session State**: Is session state preservation needed? (Yes/No)
    - e.g., Recording user preferences, cross-round variable transfer
14. **Error Handling**: How to handle failures?
    - Terminate the process and report an error
    - Continue executing other branches
    - Return default results

Step 2: Case Location (Based on INDEX.md)

Locate similar cases in

organized_dsl/INDEX.md

based on the collected requirements.

2.0 Search Path Configuration

markdown

⚠️ **Critical Step: You must switch to the skill directory before searching!**

**Step 1: Switch to the skill directory (Mandatory)**
```bash
cd "c:\Users\14429\.claude\skills\dify_creator"

Step 2: Search for DSL Files

Search for
```
organized_dsl/**/*.yml
```
(search in the skill directory)

Step 3: Search for Index Files

Search for
```
organized_dsl/INDEX.md
```

Search for

organized_dsl/Dify_DSL_Complete Node Reference Guide.md

Incorrect Practices:

❌ Directly search
```
**/*.yml
```
(current directory may be incorrect)
❌ Search
```
**/organized_dsl/**/*.yml
```
(duplicate path)
❌ Search
```
**/*.yaml
```
(files are .yml not .yaml)
❌ Search
```
organized_dsl/**/*.yml
```
in other directories (will not find files)

Correct Practices:

First execute

cd "c:\Users\14429\.claude\skills\dify_creator"

Then search
```
organized_dsl/**/*.yml
```
Then search
```
organized_dsl/INDEX.md
```


### 2.1 Read INDEX.md Index

First read the index file to understand case classifications:

```markdown
1. Search and read `organized_dsl/INDEX.md`
2. Locate relevant classification directories based on the functional type of user requirements
3. Search for DSL cases with similar functions in the corresponding directory (using `organized_dsl/**/*.yml`)

2.2 Classification Location

Find the corresponding directory based on functional type:

markdown

Based on your requirements, I have located the following relevant classifications:

| Classification | Directory Path |
|------|----------|
| Content Creation | `01_Content_Generation_Creation/` |
| Image Generation | `02_Image_Generation_Design/` |
| Video Generation | `03_Video_Generation/` |
| Data Analysis | `04_Data_Analysis_Visualization/` |
| Document Processing | `05_Document_Processing_OCR/` |
| Knowledge Base RAG | `06_Knowledge_Base_RAG/` |
| Agent Tools | `07_Agent_Tool_Calling/` |
| Education & Learning | `08_Education_Learning/` |
| Business & Office | `09_Business_Office/` |
| Multimedia Processing | `10_Multimedia_Processing/` |
| Code Development | `11_Code_Development/` |
| Creative Entertainment | `12_Creative_Entertainment/` |

2.3 Complexity Matching

Match complexity based on the number of nodes:

Complexity	Number of Nodes	Applicable Scenarios
Simple	3-5	Single function, linear process
Medium	6-15	Multi-step processing, with branches
Complex	16+	Multi-module collaboration, loop processing

2.4 Output Reference Case List

markdown

The following reference cases related to your requirements have been found:

### 📂 Case 1: [Case Name]
- **Location**: `directory-path/file-name.yml`
- **Complexity**: Simple/Medium/Complex
- **Number of Nodes**: X
- **Main Nodes**: start → llm → answer
- **Reference Value**: Node structure, Prompt template, process design

### 📂 Case 2: [Case Name]
...

Please confirm:
- Do you need to view more similar cases?
- Which cases have the structure that best meets your requirements?

2.5 Read and Analyze Reference Cases

After selecting reference cases, read the DSL files for analysis:

markdown

I have read the reference cases, and here is the key configuration extraction:

**Node Structure:**

[Start Node] ↓ [LLM Node] - Model: xxx, Prompt: xxx ↓ [Tool Node] - Tool: xxx ↓ [Output Node]


**Key Configuration References:**
- LLM prompt template: ...
- Variable transfer method: ...
- Conditional branch logic: ...

Step 3: Workflow Structure Design

Design the workflow structure based on requirement analysis and reference cases.

3.1 Design Principles

KISS Principle: Keep it simple, avoid over-engineering
Modularity: Split complex processes into reusable steps
Clear Variables: Use meaningful variable names for easy tracking

3.2 Output Process Structure Diagram

markdown

Based on your requirements, I have designed the following workflow structure:

## 📊 Process Structure Diagram

┌─────────────┐ │ Start Node │ Input: {{input_var}} └──────┬──────┘ ↓ ┌─────────────┐ │ Preprocessing Node │ Function: Data cleaning/format conversion └──────┬──────┘ ↓ ┌─────────────┐ │ Core Processing │ Function: LLM calling/tool execution │ (Branch Judgment) │ Condition: {{condition}} └──────┬──────┘ ┌────┴────┐ ↓ ↓ ┌──────┐ ┌──────┐ │Branch A │ │Branch B │ └────┬─┘ └────┬─┘ │ │ └────┬─────┘ ↓ ┌─────────────┐ │ Result Processing │ Function: Formatting/aggregation └──────┬──────┘ ↓ ┌─────────────┐ │ Output Node │ Output: {{output_var}} └─────────────┘


## 📋 Node List

| Serial Number | Node Name | Node Type | Function Description | Input Variables | Output Variables |
|------|---------|---------|---------|---------|---------|
| 1 | Start | start | Receive user input | - | user_input |
| 2 | Preprocessing | code | Data cleaning | user_input | clean_data |
| 3 | LLM Processing | llm | Content generation | clean_data | llm_result |
| 4 | Condition Judgment | if-else | Branch processing | llm_result | branch |
| 5 | Output | answer | Return results | final_result | - |

## 📝 Key Configurations

**LLM Configuration:**
- Model: xxx
- Prompt template: xxx

**Variable Transfer:**
- Upstream output → Downstream input

Step 4: User Confirmation (⚠️ Mandatory Step)

Warning: Do NOT generate DSL without explicit user confirmation!

Show the structure design to users, and you must obtain the following confirmations before proceeding:

4.1 Confirmation Content

markdown

## Workflow Structure Confirmation ⚠️

Before generating the DSL file, please confirm the following design:

### ✅ Process Structure
- Number of Nodes: X
- Process Branches: X
- Loop Processing: X

### ✅ Node Configuration
1. [Node 1]: Configuration confirmed ✓
2. [Node 2]: Need adjustment →
3. [Node 3]: Configuration confirmed ✓

### ✅ Items to Confirm
1. Is the model selection correct?
2. Does the Prompt template need adjustment?
3. Are the branch conditions reasonable?
4. Does the output format meet requirements?

**Please reply with "Confirm" or "Continue" to generate the DSL, or provide modification suggestions.**

4.2 Confirmation Checklist

markdown

The following items must be confirmed before generating the DSL:

- [ ] User explicitly replied "Confirm" or "Continue"
- [ ] All node configurations have been checked with the user
- [ ] Model and parameters have been approved by the user
- [ ] Output format meets user requirements

**If the above conditions are not met, do NOT proceed to Step 5!**

4.3 Adjustment and Iteration

If the user has modification suggestions, iterate and adjust until confirmed:

markdown

Based on your feedback, I have made the following adjustments:

1. Modified the LLM node Prompt template
2. Added new conditional branches
3. Adjusted variable transfer logic

Please confirm again.

Step 5: Generate Complete DSL (⚠️ Must Reference Cases)

The following steps must be completed before generating the DSL:

✅ Switched to the skill directory:

cd "c:\Users\14429\.claude\skills\dify_creator"

✅ Read and analyzed reference cases in Step 2
✅ Obtained explicit user confirmation in Step 4

✅ Read

organized_dsl/Dify_DSL_Complete Node Reference Guide.md

5.1 Pre-Check

markdown

Confirmation before generating DSL:

- [ ] Selected reference case file (Path: xxx/xxx.yml)
- [ ] Read the node configuration reference guide
- [ ] Obtained user's "Confirm" reply
- [ ] All node configurations have been determined

**If the above steps are not completed, do NOT generate the DSL!**

5.2 Generation Structure

yaml

app:
  description: '{{description}}'
  icon: '{{icon}}'
  icon_background: '{{icon_background}}'
  mode: '{{mode}}'
  name: '{{name}}'
  use_icon_as_answer_icon: false
kind: app
version: {{version-number-of-reference-case}}
workflow:
  conversation_variables: []
  environment_variables: []
  features:
    file_upload: {}
    # ... Other function configurations
  graph:
    edges: []
    nodes: []
  viewport: {}

5.3 Node ID Generation Rules

Use timestamp + random number as node ID
Format:
```
{timestamp}{6-digit-random-number}
```
Example:
```
1741011655068
```
,
```
1735195133945
```

5.4 Position Calculation

The position of nodes on the canvas is automatically calculated according to the process order:

X coordinate: Move approximately 300px to the right for each additional node
Y coordinate: Centered uniformly or adjusted according to branches

5.5 Complete Output Example

yaml

# ============================================
# Dify Workflow DSL File
# Name: xxx
# Generation Time: 2026-01-03
# Reference Case: xxx.yml
# ============================================

app:
  description: 'Workflow Description'
  icon: 🤖
  icon_background: '#FFEAD5'
  mode: workflow
  name: xxx
kind: app
version: {{version-number-of-reference-case}}
workflow:
  graph:
    edges:
    # ... Connection configurations
    nodes:
    # ... Node configurations

⚠️ 5.6 Node Writing Rules (Important!)

Each node must be written by strictly following the examples in the organized_dsl case library!

markdown

When generating workflows, please strictly follow the following rules:

1. **First Find Reference Cases**
   - Search `organized_dsl/**/*.yml` to find DSL files with similar functions
   - Search `organized_dsl/Dify_DSL_Complete Node Reference Guide.md` to view node configuration instructions

2. **Node Structure Must Be Complete**
   Each node must include:
   - `id`: Unique identifier
   - `data.type`: Node type
   - `data.title`: Node title
   - `position`: Canvas position {x, y}
   - `width`/`height`: Node size (optional)

3. **Do NOT Write from Scratch**
   - ❌ Do not write nodes based on memory or imagination
   - ✅ Must copy the structure of reference cases and replace key fields

4. **Special Notes**
   - **Iteration Nodes**: Must include iteration-start sub-node and all necessary markers
   - **LLM Nodes**: Must include model.provider, model.name, prompt_template
   - **HTTP Requests**: Must include correct authorization and body configurations
   - **Variable References**: Must use the format `{{#node-id.variable#}}`

⚠️ 5.7 Mandatory Post-Generation Check (❗Must Execute)

After generating the DSL, you must check each node step by step according to the following steps!

markdown

## Mandatory Post-Generation DSL Check ⚠️

**Warning: Do NOT deliver to users without completing the check!**

### Step 1: Confirm Version Number
```yaml
version: {{version-number-of-reference-case}}  # ✅ Consistent with reference case

Key Point: The version number should be consistent with the selected reference case, not a fixed value.

Step 2: Traverse Each Node and Check Against Reference Cases One by One

For each generated node, perform the following checks:

Find nodes of the same type in reference cases

bash

cd "c:\Users\14429\.claude\skills\dify_creator"
rg "type: node-type" organized_dsl/**/*.yml | head -20

Read the node structure in reference cases
- Open the corresponding DSL file
- Find the node configuration of the same type
Field-by-field Comparison

Field Reference Case Generated Result Correct?
data.positionAbsolute false ?
data.selected false ?
height 52 ?
width 242 ?
... ... ... ...
Mark Differences and Correct
- If any difference is found, correct it immediately
- For uncertain fields, use the original value from the reference case

Field	Reference Case	Generated Result	Correct?
data.positionAbsolute	false	?
data.selected	false	?
height	52	?
width	242	?
...	...	...	...

Step 3: Edge Connection Check

Traverse each edge and check the following fields:

```
data.sourceType
```
: Source node type
```
data.targetType
```
: Target node type
```
data.selected
```
: false
```
data.isInIteration
```
: false (outside iteration)
```
type
```
: custom/true/false/isInIteration

Step 4: Focused Check for Special Nodes

Node Type	Check Focus
`variable-aggregator`	`output_type` + `variables` array (not outputs/formatter_template)
`end`	`type: end` + `outputs` (not type: answer)
`iteration`	`start_node_id` points to iteration-start
`llm`	`model.provider` , `model.name` , `prompt_template`
`http-request`	`authorization` , `body` configurations are complete

Step 5: Inspection Report

markdown

## DSL Inspection Report

### Node Inspection Results
| Node ID | Node Type | Inspection Status | Issue |
|--------|---------|---------|------|
| xxx | start | ✅ Passed | None |
| xxx | llm | ❌ Failed | Missing model.provider |

### Edge Inspection Results
| Edge ID | Type | Inspection Status | Issue |
|------|-----|---------|------|
| xxx | custom | ✅ Passed | None |

### Final Conclusion
- [ ] All nodes passed inspection
- [ ] All edges passed inspection
- [ ] No corrections needed, ready for delivery

Handling of Failed Inspections:

Locate the problematic node
Read the reference case
Correct the node configuration
Re-check until passed


---

## Dify DSL Structure Specifications

### Complete Structure Template

```yaml
app:
  description: 'Application Description'
  icon: 🤖
  icon_background: '#FFEAD5'
  mode: workflow|advanced-chat|chatflow
  name: Application Name
  use_icon_as_answer_icon: false
kind: app
version: {{version-number-of-reference-case}}
workflow:
  conversation_variables: []   # Session variables
  environment_variables: []    # Environment variables
  features:
    file_upload:               # File upload configuration
      enabled: false
      # ... Detailed configuration
    opening_statement: ''      # Opening statement
    retriever_resource:        # Retrieval resource
      enabled: true
    text_to_speech:            # TTS configuration
      enabled: false
  graph:
    edges: []                  # Connection list
    nodes: []                  # Node list
  viewport:                    # View position
    x: 0
    y: 0
    zoom: 1
dependencies: []               # Plugin dependencies

Node Type Description

Node Type	Purpose	Key Configurations
`start`	Start node	variables (input variable definitions)
`llm`	Large language model	model, prompt_template, vision, context
`answer`	Chatflow direct reply	answer (output template), only for conversational applications
`knowledge-retrieval`	Knowledge base retrieval	dataset_ids, query_variable_selector
`tool`	Tool calling	provider_id, tool_name, tool_parameters
`code`	Code execution	code, code_language, outputs, variables
`http-request`	HTTP request	method, url, authorization, body
`if-else`	Conditional branch	cases (condition judgment)
`template-transform`	Template transformation	template, variables
`assigner`	Write to session variables	items, write_mode
`variable-aggregator`	Aggregate multi-branch outputs	variables, output_type (not simple integration!)
`iteration`	⚠️ Loop processing	iterator_selector, output_selector, start_node_id (required!)
`document-extractor`	Document extraction	variable_selector, is_array_file
`agent`	Agent	agent_parameters, agent_strategy_name
`end`	Workflow end node	outputs (output variables), only for workflows

Variable Reference Syntax

yaml

# Reference format: {{#node-id.output-field#}}

# Reference input from start node
{{#1742961448129.file#}}

# Reference text output from LLM node
{{#1742965550311.text#}}

# Reference custom output from Code node
{{#1747670104835.result#}}

# Reference session variable
{{#conversation.status#}}

# Reference environment variable
{{#env.API_KEY#}}

⚠️ Iteration Node Specifications (Critical!)

Iteration nodes are the most error-prone part of DSL. Missing any item will cause import failure!

Complete Iteration Node Structure

yaml

# 1. iteration node - Loop controller
- id: '1741011600006'
  data:
    iterator_selector: ['1741011655068', 'text']  # Array to iterate over
    output_selector: ['1741011662463', 'result']  # Output results
    output_type: array[object]                     # Required format
    start_node_id: 1741011600006start              # Must point to iteration-start
    title: Iteration Processing
    type: iteration
  position: {x: 200, y: 100}

# 2. iteration-start node - Iteration entry (Mandatory!)
- id: 1741011600006start
  data:
    title: Iteration Start
    type: custom-iteration-start
  parentId: '1741011600006'    # Must point to parent iteration node
  position: {x: 200, y: 200}

# 3. Internal iteration node - Process each element
- id: '1741011662463'
  data:
    isInIteration: true         # Must mark as in iteration
    iteration_id: '1741011600006'  # Must identify the iteration it belongs to
    parentId: '1741011600006'   # Must point to parent iteration
    title: Processing Node
    type: llm
  position: {x: 200, y: 300}

# 4. Internal iteration edge - Connect nodes within iteration
- source: 1741011600006start
  target: '1741011662463'
  type: isInIteration           # Must be isInIteration
  zIndex: 1002                  # Required rendering layer

Success vs Failure Comparison

Comparison Item	✅ Success Version	❌ Failure Version
Version	Same as reference case	Inconsistent version
iteration-start	✅ Exists	❌ Missing
parentId	✅ Exists	❌ Missing
iteration_id	✅ Exists	❌ Missing
isInIteration edge	✅ Exists	❌ Missing
zIndex: 1002	✅ Exists	❌ Missing
output_type format	`array[object]`	Incorrect format
start_node_id	✅ Points to iteration-start	❌ Missing

❌ Common Errors

Issue	Description
Missing iteration-start	Iteration must have a dedicated start sub-node, not "built-in"
Missing parentId	Internal iteration nodes cannot identify which iteration they belong to
Missing iteration_id	Iteration cannot manage internal nodes correctly
Missing zIndex: 1002	Incorrect rendering layer for internal iteration edges
Incorrect output_type format	Must be `array[object]`

Iteration Edge Connection Types

Type	Description	Used for Iteration?
`custom`	Normal connection	❌ Outside iteration
`true`	Condition is true	❌
`false`	Condition is false	❌
`isInIteration`	Connection within iteration	✅ Must use this

Edge Connection Types

Type	Description	Example
`custom`	Normal connection	source → target
`true`	Condition true branch	if-else → true
`false`	Condition false branch	if-else → false
`custom_case_id`	Custom branch	if-else → custom_case_id
`isInIteration`	Connection within loop	Connection between nodes in iteration

Usage Example

Example: Translation Workflow

User Requirements:

Name: zh-en-translator
Function: Chinese to English translation
Type: workflow
Input: Chinese text
Process: User input → LLM translation → Return results

Generated Configuration:

yaml

app:
  description: 'Chinese-English Translation Workflow'
  icon: 🌐
  icon_background: '#E3F2FD'
  mode: workflow
  name: zh-en-translator
kind: app
version: {{version-number-of-reference-case}}
workflow:
  graph:
    edges:
    - source: '1741011655068'
      target: '1741011662463'
      type: custom
    - source: '1741011662463'
      target: llm
      type: custom
    - source: llm
      target: answer
      type: custom
    nodes:
    - data:
        title: Start
        type: start
        variables:
        - variable: text
          type: paragraph
          label: Input Chinese Text
          required: true
      id: '1741011655068'
      position: {x: 0, y: 263}
    - data:
        context:
          enabled: false
        model:
          provider: siliconflow
          name: internlm2_5-7b-chat
          mode: chat
        prompt_template:
        - role: system
          text: 'Please translate the following Chinese text into English, only output the translation result: {{#1741011655068.text#}}'
        title: LLM Translation
        type: llm
      id: llm
      position: {x: 382, y: 263}
    - data:
        answer: '{{#llm.text#}}'
        title: Translation Result
        type: answer
      id: answer
      position: {x: 690, y: 263}

Best Practices

1. Case Reuse Strategy

First Locate: Find the most similar case through INDEX.md
Then Analyze: Read the DSL file to understand node configurations
Finally Adjust: Make personalized modifications based on the reference template

2. Process Design Principles

Start Simple: Implement core functions first, then add branches and loops
Modular Design: Split complex processes into reusable steps
Clear Naming: Use meaningful variable names

3. DSL Writing Checklist

Node IDs are unique and formatted correctly
Position coordinates are reasonable and non-overlapping
Edge connections are correct, no broken links
Variable reference format is correct
Model/Provider configurations are valid
Output variable names are consistent with references

4. Testing and Verification Suggestions

Import and test in Dify after generation
Check input and output of each node
Verify conditional branch logic
Test boundary cases and error handling

Error Handling

Error Type	Handling Method
Incomplete Requirements	Prompt users to supplement missing information
Process Logic Error	Point out possible circular references or broken links
Node Configuration Error	Provide correction suggestions
Invalid Variable Reference	List available variable options
Case Location Failure	Expand search scope or design manually

Reference Resources

📂 Case Directory Structure

organized_dsl/
├── 01_Content_Generation_Creation/
├── 02_Image_Generation_Design/
├── 03_Video_Generation/
├── 04_Data_Analysis_Visualization/
├── 05_Document_Processing_OCR/
├── 06_Knowledge_Base_RAG/
├── 07_Agent_Tool_Calling/
├── 08_Education_Learning/
├── 09_Business_Office/
├── 10_Multimedia_Processing/
├── 11_Code_Development/
├── 12_Creative_Entertainment/
├── 13_Information_Aggregation/
├── 14_Reference_Examples/
├── INDEX.md                    # Case index (search organized_dsl/INDEX.md)
└── Dify_DSL_Complete Node Reference Guide.md  # Node configuration reference (search organized_dsl/Dify_DSL_Complete Node Reference Guide.md)

📖 Document Links

INDEX.md: Case index classified by function
Dify_DSL_Complete Node Reference Guide.md: Detailed configuration instructions for each node

Node Automatic Validation and Generation Rules

Version Number Rules

yaml

# ✅ Correct - Must use when generating
version: {{version-number-of-reference-case}}

# ❌ Incorrect - Prohibited
version: {{version-number-of-reference-case}}

Node Basic Field Rules

Each node must include the following when generated:

yaml

- data:
    positionAbsolute: false      # ✅ Mandatory
    selected: false              # ✅ Mandatory
    title: "Node Name"
    type: "Node Type"
    # ... Other fields
  height: 52
  id: 'node-id'
  position:
    x: 0
    y: 0
  width: 242

Edges Field Rules

Each edge must include the following when generated:

yaml

- data:
    isInIteration: false         # ✅ Mandatory
    selected: false              # ✅ Mandatory
    sourceType: "Source Node Type"
    targetType: "Target Node Type"
  id: "edge-id"
  source: "source-node-id"
  sourceHandle: "source"
  target: "target-node-id"
  targetHandle: "target"
  type: "custom|true|false|isInIteration"

variable-aggregator Node Generation Rules

yaml

# ✅ Correct Usage - For aggregating multi-branch outputs
- data:
    output_type: string          # Output type of aggregated results
    type: variable-aggregator
    variables:                   # Variables for aggregating multi-branches (2D array)
    - - 'branch-node-id-1'             # Output of first branch
      - text
    - - 'branch-node-id-2'             # Output of second branch
      - text
  height: 211
  id: 'aggregator-node-id'

# ❌ Misunderstanding - Not simply "integrate multiple contents together"
# Real purpose of variable-aggregator:
# - Integrate outputs of IF/ELSE conditional branches
# - Integrate multiple outputs of parallel structures
# - Ensure that downstream can reference through unified variables regardless of which branch is executed

end Node Generation Rules

yaml

# ✅ Correct Usage - End node for Workflow applications
- data:
    outputs:
    - value_selector:
      - 'upstream-node-id'
      - text
      variable: output
    type: end                    # ✅ Use type: end (only for Workflow)
  height: 103
  id: end

answer Node Usage Scenarios

yaml

# ✅ Correct Usage - Only for Chatflow applications
- data:
    answer: '{{#llm.text#}}'     # Use answer field
    type: answer                 # ✅ Use type: answer (only for Chatflow)

Post-Generation DSL Checklist (Mandatory After Generation)

After generating the DSL, check item by item:

Application Type Check:

Workflow type uses
```
type: end
```
, Chatflow type uses
```
type: answer
```
Workflow can only have one unique End node
Chatflow supports multiple Answer nodes

Node Check:

Version number is consistent with reference case
Each node has
```
data.positionAbsolute: false
```
Each node has
```
data.selected: false
```
Each node has
```
height
```
and
```
width
```

Edge Check:

Each edge has
```
data.sourceType
```
Each edge has
```
data.targetType
```
Each edge has
```
data.selected: false
```
Each edge has
```
data.isInIteration
```
(false outside iteration)

variable-aggregator Check:

Uses
```
output_type
```
(not
```
outputs
```
)
Uses
```
variables
```
array format (not
```
formatter_template
```
)
Understand the purpose: Aggregate multi-branch outputs, not simple content integration

assigner vs variable-aggregator Check:

Need to write to session variables → Use
```
assigner
```
Need to aggregate multi-branch outputs → Use
```
variable-aggregator
```

Last Updated: 2026-01-03 Number of Reference Cases: 125+

dify_creator

NPX Install

Tags

SKILL.md Content (Chinese)

Dify Workflow Generator (dify_creator)

Core Capabilities

Use Cases

Workflow Overview

Core Steps

Step 1: Collect User Requirements

1.1 Basic Information Collection

1.2 Functional Requirement Collection

1.3 Model and Tool Configuration

1.4 Process Control Inquiry

Step 2: Case Location (Based on INDEX.md)

2.0 Search Path Configuration

2.2 Classification Location

2.3 Complexity Matching

2.4 Output Reference Case List

2.5 Read and Analyze Reference Cases

Step 3: Workflow Structure Design

3.1 Design Principles

3.2 Output Process Structure Diagram

Step 4: User Confirmation (⚠️ Mandatory Step)

4.1 Confirmation Content

4.2 Confirmation Checklist

4.3 Adjustment and Iteration

Step 5: Generate Complete DSL (⚠️ Must Reference Cases)

5.1 Pre-Check

5.2 Generation Structure

5.3 Node ID Generation Rules

5.4 Position Calculation

5.5 Complete Output Example

⚠️ 5.6 Node Writing Rules (Important!)

⚠️ 5.7 Mandatory Post-Generation Check (❗Must Execute)

Step 2: Traverse Each Node and Check Against Reference Cases One by One

Step 3: Edge Connection Check

Step 4: Focused Check for Special Nodes

Step 5: Inspection Report

Node Type Description

Variable Reference Syntax

⚠️ Iteration Node Specifications (Critical!)

Complete Iteration Node Structure

Success vs Failure Comparison

❌ Common Errors

Iteration Edge Connection Types

Edge Connection Types

Usage Example

Example: Translation Workflow

Best Practices

1. Case Reuse Strategy

2. Process Design Principles

3. DSL Writing Checklist

4. Testing and Verification Suggestions

Error Handling

Reference Resources

📂 Case Directory Structure

📖 Document Links

Node Automatic Validation and Generation Rules

Version Number Rules

Node Basic Field Rules

Edges Field Rules

variable-aggregator Node Generation Rules

end Node Generation Rules

answer Node Usage Scenarios

Post-Generation DSL Checklist (Mandatory After Generation)