opendcai/dataflow-webui/generating-dataflow-pipeline

DataFlow Pipeline Code Generator

Goal

This skill is used when users provide:

• Target: What the pipeline should achieve
• Sample Data File: Path to a JSONL file containing 1-5 representative data samples

The skill must:

1. Read and analyze the JSONL file at the provided path
2. Infer data structure, field types, and content characteristics
3. Determine task type based on file content (document processing, text transformation, multi-field composition)
4. Select appropriate operators from preferred primitives
5. Validate field dependencies
6. Output intermediate operator decision summary
7. Generate standard DataFlow pipeline code with first_entry_file_name set to the user-provided file path

User Input Format

Users provide:

Target: [Clear task description]
Sample file: [Path to JSONL file, e.g., ./data/input.jsonl]
Expected outputs: [Optional field list]

Important: The sample file is a JSONL file (one JSON object per line), not a JSON array.

Preferred Operator Strategy

Six Core Primitives (high-coverage operators for most data science tasks):

1. PromptedGenerator - Single-field LLM generation
2. FormatStrPromptedGenerator - Multi-field template generation
3. Text2MultiHopQAGenerator - Multi-hop QA pair construction
4. PromptedFilter - LLM-based quality filtering
5. GeneralFilter - Rule-based filtering
6. KBC trio (always used together in order): FileOrURLToMarkdownConverterFlash → KBCChunkGenerator → KBCTextCleaner

These are preferred primitives, not fixed workflows. They can be used repeatedly and combined flexibly.

Operator Selection Priority Rule (MANDATORY)

When a specialized operator exists for the task, it MUST be used over generic operators. Do NOT use PromptedGenerator to replicate functionality that a dedicated operator already provides.

Decision table (check in order, use the first match):

Key principle: PromptedGenerator is the fallback for generic single-field generation. If the target mentions "QA", "question-answer", "问答" — always reach for Text2MultiHopQAGenerator first. <!-- @if mcp==yes --> In MCP mode, browse top-level category core_text; do not hallucinate query categories like core_text/generate. If both core_text and another top-level category seem plausible, call recommend_operator_categories with the task description plus dataset columns before spending more MCP context. Treat its result as a hard budget: inspect at most the top 1-2 suggested categories, then switch to get_operator_detail_by_name instead of further category scans. <!-- @endif -->

Field Dependency Rules (MANDATORY)

<!-- @if mcp==yes --> When this skill is used with MCP and a registered dataset, first call get_dataset_columns for the dataset id and treat those returned column names as the ground-truth initial field set. <!-- @endif -->

1. Inspect sample first: Identify all available fields in user's sample data
2. Field existence check: If step N needs field X, then X must exist in original sample OR be output by step M where M < N
3. Generate missing fields: Use PromptedGenerator or FormatStrPromptedGenerator to create missing semantic fields
4. Never reference before creation: Cannot consume a field before it exists
5. Avoid overwriting: Do not overwrite original user fields unless explicitly requested

<!-- @if mcp==yes -->

1. If committing through MCP: call validate_pipeline_config before create/update; field-flow errors should be fixed before commit
2. If validate_pipeline_config returns missing_input_field, treat its suggested_fields and repair_hint as the first repair path. Fix the binding and re-validate; do not broaden MCP browsing or switch categories just because a field name was wrong.

<!-- @endif -->

✗ WRONG: Filter by "quality_score" before generating it
✓ CORRECT: Generate "quality_score" first, then filter by it

Prompted Operator Usage Policy (MANDATORY)

• Don't mechanically create one prompted operator per tiny requirement. If one operator can handle multiple related transformations, prefer that over splitting.
• Multiple prompted operators are allowed when the task genuinely requires distinct semantic transformations. If using multiple, justify each step's role, input field, and output field.

KBC Usage Constraint (MANDATORY)

The KBC trio must always be used in this exact order:

1. FileOrURLToMarkdownConverterFlash — converts file path / URL → Markdown text (field: text_path)
2. KBCChunkGenerator — splits Markdown into chunks (field: raw_chunk)
3. KBCTextCleaner — LLM-cleans each chunk (field: cleaned_chunk)

Rules:

• All three steps are required; never skip one.
• Input to step 1 must be a file path or URL, never plain text content.
• Each step's output_key becomes the next step's input_key.
• Use the default field names (text_path, raw_chunk, cleaned_chunk) unless explicitly requested otherwise.

GeneralFilter Field Safety Rule (MANDATORY)

GeneralFilter lambda rules must ONLY reference fields that exist in sample data or are produced by upstream steps.

Multi-Field Filtering Pattern (MANDATORY)

PromptedFilter only accepts a single input_key. For multi-field evaluation (e.g., scoring QA pairs), use FormatStrPromptedGenerator to score + GeneralFilter to filter.

Important caveat for `Text2MultiHopQAGenerator` output: The QA_pairs column is a nested list of dicts, not separate question/answer columns. You cannot directly pass question or answer as kwargs to FormatStrPromptedGenerator after Text2MultiHopQAGenerator. To score or filter individual QA pairs, use post-processing (explode the list into rows, then optionally score/filter in a second pipeline or in Python code).

Output Contract (MANDATORY)

Two-stage output required:

Stage 1: Intermediate Operator Decision (JSON)

Output this first:

{
  "ops": ["OperatorA", "OperatorB", "OperatorC"],
  "field_flow": "field_a -> field_b -> field_c",
  "reason": "Why this ordered operator chain satisfies the target, how field dependencies are satisfied, and why prompted operators are or are not used."
}

Stage 2: Complete Response (5 sections)

1. Field Mapping: Map sample fields to semantic roles, identify fields to generate
2. Ordered Operator List: List operators in execution order with justification
3. Reasoning Summary: Explain operator selection, field flow, why this design
4. Complete Standard Pipeline Code: Full executable Python following repository style
5. Adjustable Parameters / Caveats: Tunable parameters, fallback strategies, debugging tips

LLM Serving Pre-check Rule (MANDATORY)

Before generating pipeline code, the agent MUST confirm the user's LLM serving configuration. If any LLM-dependent operator is used (e.g., PromptedGenerator, FormatStrPromptedGenerator, PromptedFilter, Text2MultiHopQAGenerator, KBCTextCleaner), the following information is required:

Required information (ask the user if not provided):

1. `api_url`: The LLM API endpoint (e.g., https://api.openai.com/v1/chat/completions or a self-hosted/proxy URL)
2. `model_name`: The model to use (e.g., gpt-4o, gpt-4o-mini, deepseek-chat)
3. API key variable name: Which environment variable holds the key — OPENAI_API_KEY, DF_API_KEY, etc. Ask for the name only. Never ask for, accept or repeat the key's value.

When to ask:

• If the user has NOT specified api_url or model_name in their request, ask before generating code
• If the pipeline uses LLM operators but the user only provided data + target, ask in one consolidated prompt:

``` Pipeline 中使用了 LLM 算子，请确认以下配置：

1. API 端点 (api_url)：例如 https://api.openai.com/v1/chat/completions
2. 模型名称 (model_name)：例如 gpt-4o
3. API Key 环境变量名（只要变量名，不要粘贴密钥本身）：例如 OPENAI_API_KEY（默认为 DF_API_KEY）

```

• Ask for the variable's name, never its value.
• To check it is set without revealing it, test for presence only — never print it:

``bash [ -n "${OPENAI_API_KEY:-}" ] && echo "OPENAI_API_KEY is set" || echo "OPENAI_API_KEY is NOT set" ``

Do not run echo $OPENAI_API_KEY: that writes the secret into the transcript and into any log capturing it.

When NOT to ask (skip the pre-check):

• User explicitly provided all three pieces of info
• Pipeline uses only non-LLM operators (e.g., GeneralFilter, KBCChunkGenerator, FileOrURLToMarkdownConverterFlash)

<!-- @if profile==webui --> WebUI deployment context:

When the pipeline is intended for WebUI execution (not local python pipeline.py), the serving must also be registered in the WebUI Serving Manager. After generating code, remind the user:

• Use the WebUI Serving Manager to create a serving with the correct api_url, model_name, and api_key
• In the WebUI pipeline editor, assign the serving to ALL LLM-dependent operators (not just the first one)
• Common failure: only the first operator gets a serving assigned; the rest remain empty, causing Failed to process parameter: llm_serving errors at execution time
• In WebUI/MCP mode, older prompts may still say list_servings; the backend now provides both list_serving and a backward-compatible alias, but prefer list_serving in new prompts/skills

<!-- @endif -->

<!-- @if mcp==yes -->

MCP create_pipeline config structure (MANDATORY — MCP mode)

When building a pipeline via the MCP create_pipeline / update_pipeline tools (NOT local codegen), the operator params JSON has two buckets — init and run — and where each value goes is determined by the operator's real signature, which you MUST fetch first with get_operator_detail_by_name. Getting this wrong makes the pipeline crash at execution time, not at create time.

Hard rules:

1. LLM serving goes in `init.llm_serving`, as the serving *id* (not the name).

Call list_serving, find the serving the user named, and use its id (e.g. "0510fc816d385c6f"). NEVER put serving in a run param such as serving_name — the operator's run() does not accept it and run(**run_params) will raise "unexpected keyword argument".