feat: skills i18n 改造（schemaVersion 1.1，零向后兼容） (#1)

* feat: skills i18n 改造 — schemaVersion 1.1，零向后兼容

把 21 个 skills + 1 个 agent + manifest/categories 全量迁移到 schemaVersion 1.1
的 i18n 结构，配套 CI AI 翻译流水线（GitHub Models）与本地工具链。

## 关键变更

### 数据结构（破坏性，schemaVersion 1.0 → 1.1）
- SKILL.md: 顶层 name 改为 ASCII slug（== 目录名，符合 agentskills.io 规范）；
  中文显示名/short_desc/description 全部迁入 metadata.i18n.<locale>
- agents/<id>/agent.json: shortDesc/fullDesc/tags/persona.{role,traits} 迁入
  i18n.<locale>；changelog[].changes 改为 { <locale>: string[] } 对象
- categories.json: 每个分类的 label/description 迁入 i18n.<locale>，顶层只剩
  color/icon
- manifest.json: 加 supportedLocales / defaultLocale；顶层 description 迁入
  i18n.<locale>

### Body 文件结构
- 根 SKILL.md = frontmatter + default_locale (en-US) body
- SKILL.<locale>.md = 各 locale 的 markdown body（首行 <!-- locale: xx --> 自校验）

### 工具链（scripts/i18n/）
- glossary.json: zh→en 术语表 + do_not_translate 白名单
- schema/skill-frontmatter.schema.json: i18n frontmatter JSON Schema
- validate-i18n.py: 8 条校验规则（name 合规 / locale 完整性 / hash 一致性等）
- translate.py: GitHub Models / Anthropic 双 backend，sha256 增量翻译
- migrate.py: 一次性迁移脚本（旧格式 → i18n 结构）

### CI（.github/workflows/）
- i18n-validate.yml: PR 触发跑 validate + translate --check
- i18n-translate.yml: PR 触发用 GitHub Models（默认 openai/gpt-5-mini）翻译缺失
  locale，自动追加 commit；可切到 ANTHROPIC_API_KEY 走 Claude

### 文档
- docs/I18N.md: 作者贡献指南（schema 说明 / 提交流程 / 常见问题）
- README.md: 加多语言段落

## 验证

- uv run scripts/i18n/validate-i18n.py: OK，49 文件 0 错误
- uv run scripts/i18n/translate.py --check: 0 stale locale
- 21 skills 标题数 zh-CN == en-US 严格对齐（最大 66=66）
- skills-ref 规范校验：全部通过（顶层 name ASCII slug + description 单字段）

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(i18n): 修复 PR #1 review 反馈的 6 项问题

- schema: translated_by 正则放宽为 ^(human|ai:[A-Za-z0-9._:/-]+)$，接受
  'ai:github:openai/gpt-5-mini' 这类 backend:model 形式（CI 翻译输出格式）
- README + docs/I18N.md: 修正"CI 用 Claude API"误导描述，正确说明默认是
  GitHub Models（openai/gpt-5-mini）+ GITHUB_TOKEN，可选切到 Anthropic
- skills/minimax-tts/SKILL.md & SKILL.zh-CN.md: 删除多余的 ``` 闭合，避免
  Markdown 后续渲染错乱
- skills/docx/SKILL.md: 翻译时丢失的 • Unicode escape 示例已恢复，
  与 zh-CN 版本对齐

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

skills/workflow/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: 工作流编排
+name: workflow
 description: >-
   引导 Agent 设计、编辑、测试和执行 Workflow 工作流。Use when
   用户要求创建工作流、编排多步骤自动化流程、设计审批流水线、
@@ -17,6 +17,29 @@ tags:
 metadata:
   author: desirecore
   updated_at: '2026-05-04'
+  i18n:
+    default_locale: en-US
+    source_locale: zh-CN
+    locales:
+      - zh-CN
+      - en-US
+    zh-CN:
+      name: 工作流编排
+      short_desc: 引导设计、编辑、测试和执行多节点自动化工作流
+      description: >-
+        引导 Agent 设计、编辑、测试和执行 Workflow 工作流。Use when 用户要求创建工作流、编排多步骤自动化流程、设计审批流水线、 或将重复性多节点任务编排成可复用的 DSL。
+      body: ./SKILL.zh-CN.md
+      source_hash: sha256:aa197c62ae8a33d7
+      translated_by: human
+    en-US:
+      name: Workflow Orchestration
+      short_desc: Guide the design, editing, testing, and execution of multi-node automated workflows
+      description: >-
+        Guides the Agent to design, edit, test, and execute Workflow workflows. Use when the user asks to create a workflow, orchestrate multi-step automation, design an approval pipeline, or turn repetitive multi-node tasks into a reusable DSL.
+      body: ./SKILL.md
+      source_hash: sha256:aa197c62ae8a33d7
+      translated_by: ai:claude-opus-4-7
+      translated_at: '2026-05-04'
 market:
   icon: >-
     <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0
@@ -35,7 +58,6 @@ market:
     stroke-width="1.5" stroke-linecap="round"/><line x1="12" y1="14.5"
     x2="12" y2="17.5" stroke="url(#wf-a)" stroke-width="1.5"
     stroke-linecap="round"/></svg>
-  short_desc: 引导设计、编辑、测试和执行多节点自动化工作流
   category: productivity
   maintainer:
     name: DesireCore Official
@@ -51,99 +73,101 @@ requires:
     - Bash
 ---
 
-# workflow 技能
+# workflow Skill
 
-## L0：一句话摘要
+## L0: One-line Summary
 
-引导 Agent 通过 DSL 设计、编辑、校验、测试和执行多节点自动化工作流。
+Guides the Agent to design, edit, validate, test, and execute multi-node automated workflows via a DSL.
 
-## L1：概述与使用场景
+## L1: Overview and Use Cases
 
-### 能力描述
+### Capability Description
 
-workflow 是一个**流程型技能（Procedural Skill）**，赋予 Agent 编排多步骤自动化工作流的能力。工作流以 YAML DSL 文件描述，由引擎按拓扑顺序自动执行。
+workflow is a **Procedural Skill** that empowers the Agent to orchestrate multi-step automated workflows. Workflows are described by a YAML DSL file and are automatically executed by the engine in topological order.
 
-**五种基座节点**：
+**Five base node types**:
 
-| 基座 | 用途 | 典型场景 |
-|------|------|---------|
-| `trigger` | 工作流入口，声明输入参数 | 手动触发、webhook 触发 |
-| `code` | 执行代码（JS/Python） | 数据获取、API 调用 |
-| `llm` | 单次 LLM 调用（无状态） | 文本生成、数据分析、摘要 |
-| `agent` | 调用完整 Agent（有状态） | 需要 Agent 记忆、工具、技能的复杂任务 |
-| `human_gate` | 等待用户确认 | 敏感操作审批 |
+| Base | Purpose | Typical Scenario |
+|------|---------|------------------|
+| `trigger` | Workflow entry point, declares input parameters | Manual trigger, webhook trigger |
+| `code` | Executes code (JS/Python) | Data fetching, API calls |
+| `llm` | Single LLM call (stateless) | Text generation, data analysis, summarization |
+| `agent` | Invokes a full Agent (stateful) | Complex tasks requiring Agent memory, tools, and skills |
+| `human_gate` | Waits for user confirmation | Approval of sensitive operations |
 
-### 使用场景
+### Use Cases
 
-- 用户想把重复性多步骤工作编排成自动化流程
-- 用户需要多个 Agent 协作完成一个复杂任务
-- 用户需要在自动化流程中插入人工审批环节
-- 用户想复用和分享已验证的工作流程
+- The user wants to orchestrate repetitive multi-step work into an automated process
+- The user needs multiple Agents to collaborate on a complex task
+- The user needs to insert manual approval steps into an automated process
+- The user wants to reuse and share validated workflows
 
-### 核心价值
+### Core Value
 
-- **可视化编排**：DSL 描述清晰直观，支持画布可视化
-- **渐进式构建**：先写骨架再逐步丰富，降低出错概率
-- **安全门控**：通过 human_gate 节点在关键环节保留人工决策权
-- **可复用**：DSL 文件可存档、版本管理、跨 Agent 共享
+- **Visual orchestration**: The DSL description is clear and intuitive, with canvas visualization support
+- **Progressive construction**: Write the skeleton first and gradually enrich it, reducing the chance of errors
+- **Safety gating**: Use human_gate nodes to retain human decision-making authority at critical steps
+- **Reusability**: DSL files can be archived, version-controlled, and shared across Agents
 
-## L2：详细规范
+## L2: Detailed Specification
 
-### 工作流程 SOP
+### Workflow SOP
 
 ```
 ┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
-│  1. 理解意图   │ ──→ │ 2a. 设计拓扑   │ ──→ │ 2b. 逐节点配置 │ ──→ │  3. 校验 DSL  │
-└──────────────┘     │  （节点骨架）   │     │ （config/code）│     └──────────────┘
+│ 1. Understand│ ──→ │ 2a. Design    │ ──→ │ 2b. Configure │ ──→ │ 3. Validate  │
+│    intent    │     │    topology   │     │    each node  │     │    DSL       │
+└──────────────┘     │  (skeleton)   │     │ (config/code) │     └──────────────┘
                      └──────────────┘     └──────────────┘           │
                                                                      ↓
                                            ┌──────────────┐     ┌──────────────┐
-                                           │  5. 正式执行   │ ←── │  4. 干跑测试  │
-                                           └──────────────┘     └──────────────┘
+                                           │ 5. Real run  │ ←── │ 4. Dry-run   │
+                                           └──────────────┘     │    testing   │
+                                                                └──────────────┘
 ```
 
-### 阶段 1：理解意图
+### Phase 1: Understand Intent
 
-**触发条件**（任一满足）：
-- 用户明确说"创建一个工作流"或"帮我编排一个流程"
-- 用户描述一个需要多步骤、多角色协作的任务
-- 用户想把手动重复的操作自动化
+**Trigger conditions** (any one is sufficient):
+- The user explicitly says "create a workflow" or "help me orchestrate a process"
+- The user describes a task that requires multi-step, multi-role collaboration
+- The user wants to automate manual repetitive operations
 
-**收集信息**：
+**Information to collect**:
 
-| 信息 | 说明 | 引导问题 |
-|------|------|---------|
-| 目标 | 工作流要完成什么 | "这个流程最终要产出什么？" |
-| 步骤 | 大致有哪些环节 | "你通常是怎么做的？分几步？" |
-| 审批 | 哪些环节需要人工确认 | "有哪些步骤需要你亲自过目确认？" |
-| Agent | 是否需要调用特定 Agent | "有没有已有的 Agent 可以参与？" |
+| Information | Description | Guiding Question |
+|-------------|-------------|------------------|
+| Goal | What the workflow should accomplish | "What is the final output of this process?" |
+| Steps | Roughly which stages are involved | "How do you usually do it? How many steps?" |
+| Approval | Which steps require manual confirmation | "Which steps require you to personally review and confirm?" |
+| Agent | Whether a specific Agent needs to be invoked | "Are there existing Agents that can participate?" |
 
-### 阶段 2：渐进式构建 DSL
+### Phase 2: Progressive DSL Construction
 
-**DSL 文件位置**：
+**DSL file location**:
 
 ```
 ~/.desirecore/workflows/<wf_id>/workflow.dsl.yaml
 ```
 
-其中 `wf_id` 使用 `wf_` 前缀 + snake_case，如 `wf_legal_review`、`wf_daily_report`。
+Where `wf_id` uses a `wf_` prefix + snake_case, e.g. `wf_legal_review`, `wf_daily_report`.
 
-**构建策略**：严格分两步——先设计节点拓扑，再逐节点填充配置。**禁止在骨架阶段编写节点的 config 和 code 细节。**
+**Construction strategy**: Strictly two steps — first design the node topology, then fill in the configuration node by node. **Do not write node config or code details during the skeleton phase.**
 
-#### 步骤 2a：设计节点拓扑（骨架）
+#### Step 2a: Design Node Topology (Skeleton)
 
-先与用户对齐整体流程设计，确认后使用 Write 工具一次性创建骨架 DSL 文件。骨架用于对齐拓扑，不要求立即通过 `WorkflowValidate`；最终完整 DSL 写入时优先使用 `WorkflowCreate`。
+First align with the user on the overall process design. After confirmation, use the Write tool to create the skeleton DSL file in one shot. The skeleton is for aligning topology and is not required to immediately pass `WorkflowValidate`; when writing the final complete DSL, prefer using `WorkflowCreate`.
 
-**骨架只包含**：
-- 根字段（version、id、name、description、creator）
-- 每个节点的 `id`、`base`、`display.name`
-- 每个节点的 `outputs`（声明变量名和描述）
-- `flow`（start、edges、end）
+**The skeleton contains only**:
+- Root fields (version, id, name, description, creator)
+- Each node's `id`, `base`, `display.name`
+- Each node's `outputs` (declaring variable names and descriptions)
+- `flow` (start, edges, end)
 
-**骨架不包含**：config 内容（code / system_prompt / task / prompt 等）、inputs 引用。
+**The skeleton does not contain**: config content (code / system_prompt / task / prompt, etc.), inputs references.
 
 ```yaml
-# 骨架示例——只有结构，没有实现细节
+# Skeleton example — only structure, no implementation details
 version: "1.0"
 id: wf_daily_report
 name: 每日报告生成
@@ -167,7 +191,7 @@ nodes:
     base: code
     display:
       name: 获取数据
-    config: {}                    # 待步骤 2b 填充
+    config: {}                    # To be filled in step 2b
     outputs:
       raw_data: "原始数据"
 
@@ -175,7 +199,7 @@ nodes:
     base: llm
     display:
       name: AI 分析
-    config: {}                    # 待步骤 2b 填充
+    config: {}                    # To be filled in step 2b
     outputs:
       report: "分析报告"
 
@@ -183,7 +207,7 @@ nodes:
     base: human_gate
     display:
       name: 人工审阅
-    config: {}                    # 待步骤 2b 填充
+    config: {}                    # To be filled in step 2b
     outputs:
       decision: "审批决定"
       comment: "审批备注"
@@ -192,7 +216,7 @@ nodes:
     base: code
     display:
       name: 发送报告
-    config: {}                    # 待步骤 2b 填充
+    config: {}                    # To be filled in step 2b
     outputs:
       status: "发送状态"
 
@@ -206,57 +230,57 @@ flow:
   end: [send]
 ```
 
-骨架创建后，向用户确认节点设计和流程是否正确，再进入步骤 2b。
+After creating the skeleton, confirm with the user that the node design and process are correct, then proceed to step 2b.
 
-#### 步骤 2b：逐节点填充配置
+#### Step 2b: Fill Node Configurations One by One
 
-按拓扑顺序（从 trigger 开始，沿 edges 方向）逐个节点填充 config 和 inputs。每完成一个节点使用 Edit 工具写入，**不要一次性填充所有节点**。
+In topological order (starting from trigger and following the edges direction), fill in `config` and `inputs` for each node one at a time. Use the Edit tool to write each completed node — **do not fill in all nodes at once**.
 
-**每个节点填充内容**：
-1. `inputs` — 引用上游节点的输出（`{{nodeId.outputKey}}`）
-2. `config` — 该基座类型的具体配置：
-   - **code 节点**：编写 `runtime` 和 `code`（完整的可执行代码）
-   - **llm 节点**：编写 `system_prompt`、选择 `model` / `provider`、设置 `temperature` 等参数
-   - **agent 节点**：指定 `agent_id` 和编写 `task` 描述
-   - **human_gate 节点**：编写审批 `prompt`（含 `{{}}` 插值）
+**Content to fill in for each node**:
+1. `inputs` — references to upstream node outputs (`{{nodeId.outputKey}}`)
+2. `config` — the specific configuration for that base type:
+   - **code node**: write `runtime` and `code` (complete executable code)
+   - **llm node**: write `system_prompt`, choose `model` / `provider`, set parameters such as `temperature`
+   - **agent node**: specify `agent_id` and write the `task` description
+   - **human_gate node**: write the approval `prompt` (with `{{}}` interpolation)
 
-**逐节点填充顺序示例**（以上方骨架为例）：
+**Example fill order, node by node** (using the skeleton above):
 
 ```
-1. fetch_data  — 编写获取数据的 JS/Python 代码
-2. analyze     — 编写 system_prompt，选择模型，配置 inputs 引用 fetch_data 输出
-3. review      — 编写审批提示词，配置 inputs 引用 analyze 输出
-4. send        — 编写发送逻辑的代码，配置 inputs 引用 review 输出
+1. fetch_data  — write JS/Python code to fetch data
+2. analyze     — write system_prompt, choose model, configure inputs to reference fetch_data outputs
+3. review      — write the approval prompt, configure inputs to reference analyze outputs
+4. send        — write the sending logic code, configure inputs to reference review outputs
 ```
 
-填充完所有节点后进入阶段 3 校验。
+After all nodes are filled in, proceed to phase 3 validation.
 
-### DSL 编写规范
+### DSL Authoring Specification
 
-#### 根结构
+#### Root Structure
 
 ```yaml
-version: "1.0"                    # 固定值
-id: wf_<snake_case_name>          # 必须以 wf_ 前缀开头
-name: 工作流显示名称               # 人类可读名称
-description: 工作流用途描述         # 可选，说明适用场景
-creator: <agent_id>               # 创建此工作流的 Agent ID
+version: "1.0"                    # Fixed value
+id: wf_<snake_case_name>          # Must start with the wf_ prefix
+name: 工作流显示名称               # Human-readable name
+description: 工作流用途描述         # Optional, describing the applicable scenario
+creator: <agent_id>               # ID of the Agent that created this workflow
 
-nodes:                            # 节点列表（至少 1 个）
+nodes:                            # Node list (at least 1)
   - id: ...
     base: ...
     ...
 
-flow:                             # 流程控制
-  start: <起始节点 id>
+flow:                             # Flow control
+  start: <starting node id>
   edges:
-    - { from: <节点 id>, to: <节点 id> }
-  end: [<终止节点 id>]
+    - { from: <node id>, to: <node id> }
+  end: [<ending node id>]
 ```
 
-#### code 节点配置
+#### code Node Configuration
 
-code 节点执行**内联代码**（JS 或 Python），通过 `inputs` 对象访问上游数据，通过 `return` 返回结果。
+A code node executes **inline code** (JS or Python), accesses upstream data via the `inputs` object, and returns results via `return`.
 
 ```yaml
 - id: format_data
@@ -264,10 +288,10 @@ code 节点执行**内联代码**（JS 或 Python），通过 `inputs` 对象访
   display:
     name: 格式化数据
   config:
-    runtime: nodejs                  # nodejs 或 python
-    timeout_ms: 30000                # 超时毫秒数（可选，默认 30000）
+    runtime: nodejs                  # nodejs or python
+    timeout_ms: 30000                # Timeout in milliseconds (optional, default 30000)
     code: |
-      // inputs 对象包含所有上游传入的数据
+      // The inputs object contains all data passed in from upstream
       const data = JSON.parse(inputs.raw_data)
       const formatted = data.map(item => ({
         title: item.title.trim(),
@@ -275,32 +299,32 @@ code 节点执行**内联代码**（JS 或 Python），通过 `inputs` 对象访
       }))
       return { formatted: JSON.stringify(formatted) }
   inputs:
-    raw_data: "{{fetch_node.result}}"   # 引用上游节点 fetch_node 的 result 输出
+    raw_data: "{{fetch_node.result}}"   # Reference the result output of the upstream fetch_node
   outputs:
     formatted: "格式化后的数据"
 ```
 
-**config 字段说明**：
+**config field descriptions**:
 
-| 字段 | 必填 | 说明 |
-|------|------|------|
-| `runtime` | 是 | `nodejs` 或 `python` |
-| `code` | 是 | 内联代码。JS 通过 `inputs` 对象访问输入，`return` 返回输出对象。Python 同理。 |
-| `timeout_ms` | 否 | 执行超时（默认 30000ms） |
+| Field | Required | Description |
+|-------|----------|-------------|
+| `runtime` | Yes | `nodejs` or `python` |
+| `code` | Yes | Inline code. JS accesses inputs via the `inputs` object and returns the output object via `return`. Python is the same. |
+| `timeout_ms` | No | Execution timeout (default 30000ms) |
 
-**JS 代码注意事项**：
-- 代码在 `new Function('inputs', ...)` 中执行，支持 `async/await` 和 `fetch`
-- **不支持 `require()`**，不能导入 Node.js 模块
-- 通过 `inputs.xxx` 访问输入数据
-- 必须 `return` 一个对象，其 key 对应 `outputs` 中声明的变量名
+**Notes for JS code**:
+- The code is executed inside `new Function('inputs', ...)`, supporting `async/await` and `fetch`
+- **`require()` is not supported**; you cannot import Node.js modules
+- Access input data via `inputs.xxx`
+- Must `return` an object whose keys match the variable names declared in `outputs`
 
-**Python 代码注意事项**：
-- 通过 `inputs['xxx']` 访问输入数据
-- 必须 `return` 一个字典
+**Notes for Python code**:
+- Access input data via `inputs['xxx']`
+- Must `return` a dictionary
 
-#### llm 节点配置
+#### llm Node Configuration
 
-llm 节点执行**单次无状态 LLM 调用**，适用于文本生成、数据分析、摘要等场景。与 agent 节点的区别是不涉及 Agent 的记忆、工具和技能。
+An llm node performs a **single stateless LLM call**, suitable for text generation, data analysis, summarization, and similar scenarios. The difference from an agent node is that it does not involve the Agent's memory, tools, or skills.
 
 ```yaml
 - id: summarize
@@ -308,33 +332,33 @@ llm 节点执行**单次无状态 LLM 调用**，适用于文本生成、数据
   display:
     name: AI 摘要
   config:
-    provider: anthropic              # 供应商名称（可选，精确匹配）
-    model: claude-sonnet-4-6         # 模型（可选，不填使用默认）
-    system_prompt: "你是摘要助手"     # 系统提示词
-    max_tokens: 2048                 # 最大 token
-    temperature: 0.3                 # 温度（可选）
-    reasoning: medium                # 思维链级别（可选）
+    provider: anthropic              # Provider name (optional, exact match)
+    model: claude-sonnet-4-6         # Model (optional, default is used if not set)
+    system_prompt: "你是摘要助手"     # System prompt
+    max_tokens: 2048                 # Max tokens
+    temperature: 0.3                 # Temperature (optional)
+    reasoning: medium                # Reasoning level (optional)
   inputs:
     data: "{{fetch_data.result}}"
   outputs:
     summary: "摘要文本"
 ```
 
-**config 字段说明**：
+**config field descriptions**:
 
-| 字段 | 必填 | 说明 |
-|------|------|------|
-| `system_prompt` | 是 | 系统提示词，定义 LLM 的角色和行为 |
-| `provider` | 否 | 供应商名称（如 `anthropic`、`openai`），精确匹配已配置的供应商。不填则由系统自动匹配 |
-| `model` | 否 | 指定模型，不填使用默认模型 |
-| `max_tokens` | 否 | 最大输出 token 数 |
-| `temperature` | 否 | 温度参数（0-2），控制输出随机性 |
-| `reasoning` | 否 | 思维链级别：`low` / `medium` / `high`。开启后模型先推理再回答，适合复杂分析任务 |
-| `output_schema` | 否 | JSON Schema 对象。设置后 LLM 将尝试返回符合 Schema 的结构化 JSON |
+| Field | Required | Description |
+|-------|----------|-------------|
+| `system_prompt` | Yes | System prompt that defines the LLM's role and behavior |
+| `provider` | No | Provider name (e.g. `anthropic`, `openai`), exact match against configured providers. If not set, the system matches automatically |
+| `model` | No | Specifies the model; defaults to the system default if not set |
+| `max_tokens` | No | Max number of output tokens |
+| `temperature` | No | Temperature parameter (0-2), controls output randomness |
+| `reasoning` | No | Reasoning level: `low` / `medium` / `high`. When enabled, the model reasons before answering, suitable for complex analytical tasks |
+| `output_schema` | No | A JSON Schema object. When set, the LLM tries to return structured JSON conforming to the schema |
 
-#### agent 节点配置
+#### agent Node Configuration
 
-agent 节点调用**完整的 Agent**（有状态），适用于需要 Agent 的专业知识、记忆、工具或技能的复杂任务。
+An agent node invokes a **full Agent** (stateful), suitable for complex tasks that require the Agent's domain knowledge, memory, tools, or skills.
 
 ```yaml
 - id: legal_review
@@ -342,22 +366,22 @@ agent 节点调用**完整的 Agent**（有状态），适用于需要 Agent 的
   display:
     name: 法律审核
   config:
-    agent_id: legal-advisor          # 必填：目标 Agent ID
-    task: "审核以下内容：{{summarize.summary}}"  # 任务描述
+    agent_id: legal-advisor          # Required: target Agent ID
+    task: "审核以下内容：{{summarize.summary}}"  # Task description
   inputs:
     content: "{{summarize.summary}}"
   outputs:
     review: "审核意见"
 ```
 
-**config 字段说明**：
+**config field descriptions**:
 
-| 字段 | 必填 | 说明 |
-|------|------|------|
-| `agent_id` | 是 | 目标 Agent 的 ID |
-| `task` | 是 | 交给 Agent 的任务描述，支持 `{{nodeId.outputKey}}`、`{{trigger.key}}`、`{{secrets.keyName}}` 插值 |
+| Field | Required | Description |
+|-------|----------|-------------|
+| `agent_id` | Yes | ID of the target Agent |
+| `task` | Yes | Task description handed to the Agent. Supports `{{nodeId.outputKey}}`, `{{trigger.key}}`, and `{{secrets.keyName}}` interpolation |
 
-#### human_gate 节点配置
+#### human_gate Node Configuration
 
 ```yaml
 - id: approval
@@ -381,26 +405,26 @@ agent 节点调用**完整的 Agent**（有状态），适用于需要 Agent 的
     comment: "审批备注"
 ```
 
-#### llm vs agent 选择指南
+#### llm vs agent Selection Guide
 
-| 场景 | 推荐基座 | 理由 |
-|------|---------|------|
-| 文本摘要、翻译、格式转换 | `llm` | 单次调用，不需要 Agent 上下文 |
-| 数据分析、信息提取 | `llm` | 无状态处理即可完成 |
-| 需要专业知识的审核 | `agent` | 需要 Agent 的领域知识和记忆 |
-| 需要调用外部工具 | `agent` | 需要 Agent 的工具能力 |
-| 多轮推理、复杂决策 | `agent` | 需要 Agent 的完整推理链 |
+| Scenario | Recommended Base | Reason |
+|----------|------------------|--------|
+| Text summarization, translation, format conversion | `llm` | Single call, no Agent context required |
+| Data analysis, information extraction | `llm` | Stateless processing is sufficient |
+| Review requiring domain expertise | `agent` | Requires the Agent's domain knowledge and memory |
+| Calling external tools | `agent` | Requires the Agent's tool capability |
+| Multi-turn reasoning, complex decisions | `agent` | Requires the Agent's full reasoning chain |
 
-**简单判断**：如果任务可以用一段 system prompt + 一次输入完成，用 `llm`；如果任务需要 Agent 的记忆、工具或技能，用 `agent`。
+**Quick rule**: If the task can be completed with a single system prompt + one input, use `llm`; if the task requires the Agent's memory, tools, or skills, use `agent`.
 
-#### trigger 节点
+#### trigger Node
 
-每个工作流**必须有且仅有一个** trigger 节点，作为工作流入口。`flow.start` 必须指向 trigger 节点。
+Each workflow **must have exactly one** trigger node, serving as the workflow entry point. `flow.start` must point to the trigger node.
 
-**规则**：
-- trigger 节点**无 inputs**
-- trigger 节点的 outputs 使用结构化格式（`type` / `description` / `required` / `default`），声明工作流接受的输入参数
-- `config.type` 指定触发方式：`manual`（手动触发）或 `webhook`（外部触发）
+**Rules**:
+- A trigger node **has no inputs**
+- A trigger node's outputs use the structured format (`type` / `description` / `required` / `default`) to declare the input parameters the workflow accepts
+- `config.type` specifies the trigger method: `manual` (manual trigger) or `webhook` (external trigger)
 
 ```yaml
 - id: trigger
@@ -412,13 +436,13 @@ agent 节点调用**完整的 Agent**（有状态），适用于需要 Agent 的
     type: manual                        # manual | webhook
   outputs:
     param_name:
-      type: string                      # 参数类型：string / number / boolean / object / array
+      type: string                      # Parameter type: string / number / boolean / object / array
       description: "参数描述"
-      required: true                    # 是否必填
-      default: "默认值"                  # 可选，未传入时的默认值
+      required: true                    # Whether required
+      default: "默认值"                  # Optional, default value when not provided
 ```
 
-**示例**——带多个参数的 trigger：
+**Example** — a trigger with multiple parameters:
 
 ```yaml
 - id: trigger
@@ -440,44 +464,44 @@ agent 节点调用**完整的 Agent**（有状态），适用于需要 Agent 的
       default: "zh-CN"
 ```
 
-下游节点通过 `{{trigger.paramName}}` 引用 trigger 输出的参数值。
+Downstream nodes reference the parameter values output by the trigger via `{{trigger.paramName}}`.
 
-#### inputs 格式规范
+#### inputs Format Specification
 
-inputs 使用**对象映射格式**——key 为本节点的变量名，value 为数据来源引用：
+inputs uses an **object map format** — keys are the variable names within this node, and values are references to data sources:
 
 ```yaml
-# 引用其他节点的输出
+# Reference outputs of other nodes
 inputs:
   varName: "{{nodeId.outputKey}}"
 
-# 引用触发参数
+# Reference trigger parameters
 inputs:
   query: "{{trigger.userQuery}}"
 
-# 引用用户级 secret
+# Reference user-level secrets
 inputs:
   api_key: "{{secrets.email_api_key}}"
 
-# 多个输入
+# Multiple inputs
 inputs:
   title: "{{extract.title}}"
   body: "{{extract.body}}"
   metadata: "{{trigger.metadata}}"
 ```
 
-**禁止使用数组格式**：
+**Array format is forbidden**:
 
 ```yaml
-# 错误！不要用数组
+# Wrong! Do not use arrays
 inputs:
   - name: varName
     source: nodeId.outputKey
 ```
 
-#### outputs 格式规范
+#### outputs Format Specification
 
-outputs 使用**对象映射格式**——key 为输出变量名，value 为描述文本：
+outputs uses an **object map format** — keys are output variable names, and values are description text:
 
 ```yaml
 outputs:
@@ -485,151 +509,151 @@ outputs:
   summary: "结果摘要"
 ```
 
-#### flow 定义
+#### flow Definition
 
 ```yaml
 flow:
-  start: first_node              # 起始节点 ID
-  edges:                         # 边列表（定义执行顺序）
+  start: first_node              # Starting node ID
+  edges:                         # Edge list (defines execution order)
     - { from: first_node, to: second_node }
     - { from: second_node, to: third_node }
-    - from: third_node           # 条件分支（可选）
+    - from: third_node           # Conditional branch (optional)
       to: branch_a
       condition: "risk_level == 'high'"
-  end: [final_node]              # 终止节点列表
+  end: [final_node]              # List of terminal nodes
 ```
 
-#### 变量引用体系
+#### Variable Reference System
 
-DSL 中所有动态值统一使用 `{{}}` 模板语法引用：
+All dynamic values in the DSL are uniformly referenced using the `{{}}` template syntax:
 
-| 语法 | 来源 | 示例 |
-|------|------|------|
-| `{{nodeId.outputKey}}` | 前置节点输出 | `{{summarize.summary}}` |
-| `{{trigger.key}}` | 触发时传入的参数 | `{{trigger.filePath}}` |
-| `{{secrets.keyName}}` | 用户级 secret | `{{secrets.dingtalk_token}}` |
+| Syntax | Source | Example |
+|--------|--------|---------|
+| `{{nodeId.outputKey}}` | Output of a preceding node | `{{summarize.summary}}` |
+| `{{trigger.key}}` | Parameters passed in at trigger time | `{{trigger.filePath}}` |
+| `{{secrets.keyName}}` | User-level secret | `{{secrets.dingtalk_token}}` |
 
-**适用位置**：`inputs` 的值、`config.prompt` 中的插值均使用此语法。
+**Applicable locations**: This syntax is used both in `inputs` values and in interpolations within `config.prompt`.
 
-#### Secrets 引用
+#### Secrets References
 
-工作流可通过 `{{secrets.keyName}}` 引用用户预配置的密钥，用于 API 调用等场景。
+A workflow can reference user-preconfigured secrets via `{{secrets.keyName}}` for scenarios such as API calls.
 
-- Secrets 由用户在 `~/.desirecore/config/secrets.json` 中预配置
-- 引擎在运行时自动解析 `{{secrets.*}}`，将其替换为实际值
-- Secrets 仅在执行阶段解析，校验和干跑阶段不会暴露实际值
+- Secrets are preconfigured by the user in `~/.desirecore/config/secrets.json`
+- The engine automatically resolves `{{secrets.*}}` at runtime, replacing them with the actual values
+- Secrets are resolved only during the execution phase; their actual values are not exposed during validation or dry-run
 
 ```yaml
-# 在 inputs 中引用 secret
+# Reference a secret in inputs
 inputs:
   api_key: "{{secrets.email_api_key}}"
   webhook_url: "{{secrets.dingtalk_webhook}}"
 
-# 在 config.prompt 中引用 secret（不推荐，仅特殊场景）
+# Reference a secret in config.prompt (not recommended, only for special cases)
 config:
   prompt: "使用 token {{secrets.github_token}} 访问仓库"
 ```
 
-### 阶段 3：校验 DSL
+### Phase 3: Validate the DSL
 
-使用 `WorkflowValidate` 工具校验 DSL 文件的结构和引用完整性。
+Use the `WorkflowValidate` tool to validate the structure and reference integrity of the DSL file.
 
-**调用方式**：
+**How to call**:
 
 ```
-工具：WorkflowValidate
-参数：
+Tool: WorkflowValidate
+Parameters:
   path: ~/.desirecore/workflows/<wf_id>/workflow.dsl.yaml
 ```
 
-**校验内容**：
-- YAML 语法正确性
-- JSON Schema 合规性（必填字段、类型、格式）
-- 节点 ID 唯一性
-- 边的引用有效性（from/to 均指向已存在的节点）
-- 起始节点和终止节点存在
-- 无环检测（DAG 校验）
-- inputs 引用的上游节点和输出字段存在
+**What is validated**:
+- YAML syntax correctness
+- JSON Schema compliance (required fields, types, formats)
+- Uniqueness of node IDs
+- Validity of edge references (from/to both point to existing nodes)
+- The starting and terminal nodes exist
+- Cycle detection (DAG validation)
+- The upstream nodes and output fields referenced by inputs exist
 
-**校验通过** → 进入阶段 4
-**校验失败** → 根据错误信息用 Edit 工具修复，重新校验
+**Validation passes** → Proceed to phase 4
+**Validation fails** → Fix using the Edit tool based on the error information, then re-validate
 
-### 阶段 4：干跑测试
+### Phase 4: Dry-run Testing
 
-使用 `WorkflowTest` 工具进行模拟执行（dry-run），不实际调用 Agent 或执行代码。
+Use the `WorkflowTest` tool to perform a simulated execution (dry-run) without actually invoking Agents or executing code.
 
-**调用方式**：
+**How to call**:
 
 ```
-工具：WorkflowTest
-参数：
+Tool: WorkflowTest
+Parameters:
   path: ~/.desirecore/workflows/<wf_id>/workflow.dsl.yaml
-  params:                      # 可选，用于模拟 trigger 参数
+  params:                      # Optional, used to simulate trigger parameters
     filePath: /path/to/input.md
 ```
 
-**测试内容**：
-- 验证拓扑排序是否成功
-- 模拟数据在节点间的流转路径
-- 检查所有 inputs 引用在运行时是否可解析
-- 输出执行计划预览（节点执行顺序）
+**What is tested**:
+- Verifies whether topological sorting succeeds
+- Simulates the data flow path between nodes
+- Checks whether all inputs references can be resolved at runtime
+- Outputs an execution plan preview (node execution order)
 
-**测试通过** → 向用户确认是否正式执行
-**测试失败** → 根据错误信息修复，重新测试
+**Test passes** → Confirm with the user whether to perform a real run
+**Test fails** → Fix based on the error information, then retest
 
-### 阶段 5：正式执行
+### Phase 5: Real Execution
 
-使用 `WorkflowRun` 工具启动工作流。
+Use the `WorkflowRun` tool to start the workflow.
 
-**调用方式**：
+**How to call**:
 
 ```
-工具：WorkflowRun
-参数：
+Tool: WorkflowRun
+Parameters:
   path: ~/.desirecore/workflows/<wf_id>/workflow.dsl.yaml
-  params:                      # 可选，作为 {{trigger.key}} 上下文传入
+  params:                      # Optional, passed in as the {{trigger.key}} context
     filePath: /path/to/input.md
 ```
 
-**执行过程**：
-- 引擎按拓扑顺序逐节点执行
-- 实时通过 SSE 推送节点状态变更事件
-- 遇到 human_gate 节点时暂停，等待用户审批
-- 所有终止节点完成后，返回最终结果
+**Execution process**:
+- The engine executes nodes one by one in topological order
+- Node status change events are pushed in real time via SSE
+- When a human_gate node is encountered, execution pauses and waits for user approval
+- After all terminal nodes complete, the final result is returned
 
-**执行完成后**：
-- 向用户展示执行结果摘要
-- 如有失败节点，说明失败原因和建议修复方式
+**After execution completes**:
+- Show the user a summary of the execution result
+- If there are failed nodes, explain the cause of failure and recommended fixes
 
-### 注意事项
+### Notes
 
-1. **workflow_id 命名**：必须以 `wf_` 前缀开头，使用 snake_case，如 `wf_contract_review`
-2. **严格分步构建**：步骤 2a 只写节点拓扑骨架（不含 config/code），确认后步骤 2b 按拓扑顺序逐节点填充配置，禁止一次性写完所有细节
-3. **输入输出格式**：inputs 和 outputs 必须使用对象映射格式（`{ key: value }`），不要用数组
-4. **变量插值**：inputs、llm/agent/human_gate 的 prompt / system_prompt / task 支持 `{{nodeId.outputKey}}`、`{{trigger.key}}`、`{{secrets.keyName}}`
-5. **校验先行**：正式执行前务必先校验再干跑测试，减少运行时错误
-6. **人工门控**：涉及重要决策（如发布、付款、删除）的步骤，建议使用 human_gate 节点
+1. **workflow_id naming**: Must start with the `wf_` prefix and use snake_case, e.g. `wf_contract_review`
+2. **Strict step-by-step construction**: Step 2a writes only the node topology skeleton (without config/code); after confirmation, step 2b fills in configurations node by node in topological order. Do not write all details in one go
+3. **Input/output format**: inputs and outputs must use the object map format (`{ key: value }`); do not use arrays
+4. **Variable interpolation**: inputs and the prompt / system_prompt / task fields of llm/agent/human_gate support `{{nodeId.outputKey}}`, `{{trigger.key}}`, and `{{secrets.keyName}}`
+5. **Validate first**: Always validate before performing a real run, then dry-run, to reduce runtime errors
+6. **Human gating**: For steps involving important decisions (such as release, payment, or deletion), it is recommended to use a human_gate node
 
-### 错误处理
+### Error Handling
 
-| 错误场景 | 处理方式 |
-|---------|---------|
-| YAML 语法错误 | 检查缩进和格式，用 Edit 工具修正 |
-| 校验失败 | 根据 WorkflowValidate 的错误详情逐项修复 |
-| 节点引用不存在 | 检查 inputs 中引用的 nodeId.outputKey 是否拼写正确 |
-| 干跑测试失败 | 检查拓扑排序和数据流转路径 |
-| 执行超时 | 检查是否有 agent 节点 prompt 过于复杂 |
-| human_gate 被拒绝 | 工作流中止，向用户说明中止原因和已完成的步骤 |
+| Error Scenario | Handling |
+|----------------|----------|
+| YAML syntax error | Check indentation and format, fix using the Edit tool |
+| Validation failure | Fix item by item based on WorkflowValidate's error details |
+| Referenced node does not exist | Check whether nodeId.outputKey referenced in inputs is spelled correctly |
+| Dry-run failure | Check topological sorting and the data flow path |
+| Execution timeout | Check whether any agent node prompt is overly complex |
+| human_gate rejected | The workflow aborts; explain to the user the reason for the abort and the steps already completed |
 
-### 背景知识
+### Background Knowledge
 
-> AgentFS 仓库结构、排查要点与受保护路径详见 `_agentfs-background.md` 和 `_protected-paths.yaml`。
+> For the AgentFS repository structure, troubleshooting points, and protected paths, see `_agentfs-background.md` and `_protected-paths.yaml`.
 
-### 依赖
+### Dependencies
 
-- `WorkflowValidate` 内置工具 — 校验 DSL 结构
-- `WorkflowTest` 内置工具 — 干跑测试
-- `WorkflowCreate` 内置工具 — 校验并写入全局工作流目录
-- `WorkflowRun` 内置工具 — 正式执行工作流
-- Write / Edit / Read 工具 — 创建和编辑 DSL 文件
-- Agent Service Workflow 引擎（`lib/workflow-service/`）
+- `WorkflowValidate` built-in tool — validates DSL structure
+- `WorkflowTest` built-in tool — dry-run testing
+- `WorkflowCreate` built-in tool — validates and writes to the global workflow directory
+- `WorkflowRun` built-in tool — performs real workflow execution
+- Write / Edit / Read tools — create and edit DSL files
+- Agent Service Workflow engine (`lib/workflow-service/`)