@comate/zulu 1.5.0 → 1.5.1

package/comate-engine/assets/skills/create-automation/SKILL.md

@@ -2,10 +2,10 @@
 name: create-automation
 description: |
   帮助用户创建、配置和管理 Comate Automation 自动化任务。当用户表达以下意图时触发：
-  - 创建/设置/新建自动化任务、定时任务、cron 任务
-  - 修改/删除/查看已有的 Automation 配置
-  - "每天/每周/每月自动帮我做..."
-  - 配置 webhook 触发任务
+  - 创建、设置、新建自动化任务、定时任务或 cron 任务
+  - 修改、删除、查看已有的 Automation 配置
+  - “每天/每周/每月自动帮我做……”
+  - 配置 webhook 或事件触发任务
   不适用于普通的一次性任务请求，仅适用于需要周期性或事件驱动执行的自动化配置。
 metadata:
     enableWhen:
@@ -14,330 +14,293 @@ disable-model-invocation: true
 ---
 
 # create-automation Skill
-你正在帮助用户创建或管理 Comate Automation 自动化任务。本 Skill 的核心目标是**根据用户的具体需求，量身定制 AUTOMATION.md 的 query**，而不是套用固定流程模板。
 
-## ⛔ MVP 版本限制（必读，优先级最高）
-**当前版本仅支持 cron 定时触发。不支持 webhook、GitHub Events、Slack、POST 请求或任何外部事件触发。**
+你正在帮助用户创建或管理 Comate Automation 自动化任务。核心目标是根据用户的具体需求，量身定制 `AUTOMATION.md` 的 query，而不是套用固定流程模板。
 
-当用户描述的触发方式不是定时/周期性的（例如"CI 部署成功后触发""收到 POST 请求时""PR 合入后自动执行"），你必须：
+当前 MVP 版本只有一个硬性限制：**仅支持 cron 定时触发**。不支持 webhook、GitHub Events、Slack、POST 请求或任何外部事件触发。用户提出非定时触发方式时，先说明当前版本暂不支持，再建议用 cron 定时轮询替代，例如“每 5 分钟检查一次部署状态”。不要创建 webhook 或 event 类型配置，即使格式上能写，系统也不会执行。
 
-1. **立即告知**：明确说明当前 MVP 版本不支持该触发方式
-2. **引导替代方案**：建议用 cron 定时轮询作为替代（例如"每 5 分钟检查一次部署状态"）
-3. **不要直接创建 webhook/event 类型的配置**——即使你知道 AUTOMATION.md 格式上可以写 `type: webhook`，当前系统也不会执行它
-
-> 这是硬性限制，不是建议。违反此规则创建的任务不会被系统执行，会浪费用户的时间。
 ---
 
 ## Available Models
 
-自动化任务的执行 Agent 可通过 `execution.model` 字段指定使用的模型。该字段为**可选**，合法取值如下：
+自动化任务的执行 Agent 可通过 `execution.model` 字段指定模型。该字段可选，合法取值如下：
 
-- 省略 `model` 字段 — 使用系统默认模型（通常为系统临时路由的模型）
-- 列表中的**精确模型名**（包括带 `-Thinking` 后缀的变体）
+- 省略 `model` 字段：使用系统默认模型，通常为系统临时路由模型。
+- 使用下方列表中的精确模型名，包括带 `-Thinking` 后缀的变体。
 
 ${COMATE_AVAILABLE_MODELS}
 
-带 `-Thinking` 后缀的模型支持扩展思考/推理模式。无法识别的模型名会回退到系统默认。
+带 `-Thinking` 后缀的模型支持扩展思考/推理模式。无法识别的模型名会回退到系统默认。写入 `execution.model` 时，必须逐字符匹配上方列表中的名称，包括大小写、空格和连字符；不要凭印象写“Claude 4”或“GPT-5”。
 
-> ⚠️ 写入 `execution.model` 时，必须使用上方列表中**逐字符匹配**的名称（区分大小写、空格、连字符）。不要凭印象写"Claude 4"或"GPT-5"——以列表为准。
+---
 
 ## AUTOMATION.md 格式
-每个任务存放在 `~/.comate/automations/{taskName}/AUTOMATION.md`。
 
-采用 **YAML frontmatter + Markdown body** 格式：frontmatter 为调度/执行配置，body 为发给 Agent 的 query 指令。
+每个任务存放在 `~/.comate/automations/{taskName}/AUTOMATION.md`，采用 **YAML frontmatter + Markdown body** 格式：
 
-### 基本格式（定时触发）
-```md
+- frontmatter：调度与执行配置。
+- body：发给执行 Agent 的 query 指令，必须自包含。
 
+### 基本格式
+
+```md
 ---
-name: "task-name"                          # kebab-case，与目录名一致
-description: "任务描述"                     # 可选，非空字符串
+name: "task-name"                    # kebab-case，与目录名一致
+description: "任务描述"               # 可选，非空字符串
 enabled: true
 
 triggers:
   - type: schedule
     schedule:
-      cron: "0 9 * * 1-5"                    # 5字段：分 时 日 月 周
-      timezone: "Asia/Shanghai"              # 可选，IANA 时区，默认系统时区
+      cron: "3 9 * * 1-5"             # 5 字段：分 时 日 月 周
+      timezone: "Asia/Shanghai"       # 可选，IANA 时区，默认系统时区
 
 execution:
-  workspace: "/absolute/path/to/project"  # 绝对路径，默认使用当前项目路径
-  model: "Claude Sonnet 4.5"             # 示例；同系列优先选最新版本+思考模式，任务简单或用户指定时除外
-  timeoutSeconds: 3600                    # 可选，正整数，默认 3600，上限 7200
-
+  workspace: "/absolute/path/to/project"  # 必填，绝对路径。默认且应当为当前提问项目的 workspace
+  model: "Claude Sonnet 4.5-Thinking"     # 可选；复杂任务优先选最新 + Thinking
+  timeoutSeconds: 3600                     # 可选，默认 3600，上限 7200
 ---
 
 这里写任务指令（query）。必须自包含，包含所有必要上下文。
-
 ```
-> **MVP 版本说明**：当前仅支持 cron 定时触发。每个任务配置一个 schedule trigger。Webhook、GitHub、Slack 等外部事件触发将在后续版本中支持。
+
+> MVP 版本仅支持一个 `schedule` trigger。Webhook、GitHub、Slack 等外部事件触发将在后续版本支持。
+
 ---
 
 ## 执行 Agent 的能力与约束
-AUTOMATION.md 的 body（query）会被一个独立的 Comate Agent Session 执行。设计 query 时需了解该 Agent 的运行环境：
 
-**Agent 具备的能力**：
+`AUTOMATION.md` 的 body 会被一个独立的 Comate Agent Session 执行。设计 query 时，按无人值守任务处理。
 
-* 与当前用户的 Comate 环境**完全一致**：拥有相同的 **Skills**、**Rules**、**Tools**
-* 这意味着：用户在当前项目中配置的所有 Rules（如 `.comate/rules/` 下的规则）和 Skills 在 Automation Session 中同样生效
-* 可以读写文件、执行终端命令、搜索代码、调用网络等
-* 运行在 **YOLO 模式**（权限全开）：所有工具调用和命令执行均自动批准，不弹确认
+### Agent 具备的能力
 
-### 无人值守安全原则
-YOLO 模式 + 无人值守 = 高风险组合。交互式 Session 中，用户看到危险操作可以拒绝；Automation Session 中没有这道关卡。因此 **query 本身就是唯一的安全边界**——query 中没有限制的事情，Agent 都可能去做。
+- 与当前用户的 Comate 环境一致：拥有相同的 Skills、Rules、Tools。
+- 可以读写文件、执行终端命令、搜索代码、调用网络等。
+- 运行在 YOLO 模式：所有工具调用和命令执行自动批准，不弹确认。
+- 通过 Unattended Prompt 知道自己是无人值守自动化 Session，也知道触发类型、时间、workspace、Git 状态等元信息。
 
-设计 query 时需遵循**最小权限原则**：只授权任务明确需要的操作，对其他操作设置显式禁止。具体来说：
+### Agent 不具备的能力
 
-**Git 操作安全**：
+- 没有本次对话历史；每次 run 都是全新 Session。
+- 不会主动提问或等待用户输入；提问会导致 stall 直至超时。
+- 没有跨 run 记忆；每次执行互相独立。
 
-* 除非用户明确要求 push，query 中应写明"不要 push 任何代码"或"仅 push 到指定分支"
-* 涉及 push 的任务，query 中应限定目标分支（如"只 push 到 automation/{task-name} 分支，禁止 push 到 main/master"）
-* 涉及 force push、reset --hard、rebase 等不可逆 Git 操作时，必须在展示配置阶段向用户明确提醒风险
+因此，query 必须是**自包含的完整指令**：路径、分支、环境、步骤、边界条件、成功标准都要写清楚，不能依赖“Agent 应该知道”的隐含假设。
 
-**文件/系统操作安全**：
+### 无人值守安全原则
 
-* query 中应限定 Agent 的操作范围在 workspace 目录内，除非任务明确需要操作其他路径
-* 除非任务目标就是删除文件，否则 query 中应写明"不要删除项目中已有的文件"
-* 禁止在 query 中让 Agent 执行 `rm -rf`、`drop database`、修改系统配置等破坏性命令，除非这正是用户要求的操作
+YOLO 模式 + 无人值守意味着 query 是唯一安全边界。设计 query 时遵循最小权限原则：只开放任务明确需要的操作，对其他操作设置显式禁止。
 
-**网络/外部服务安全**：
+- **Git 操作**：除非用户明确要求 push，否则写明“不要 push 任何代码”。涉及 push 时，必须限定目标分支；涉及 force push、`reset --hard`、rebase 等不可逆操作时，创建前明确提醒风险。
+- **文件/系统操作**：默认限定操作范围在 workspace 内。除非任务目标就是删除文件，否则写明“不要删除项目中已有的文件”。不要让 Agent 执行 `rm -rf`、`drop database`、修改系统配置等破坏性命令，除非这正是用户明确要求的操作。
+- **网络/外部服务**：除非任务涉及部署、发布或 API 调用，否则写明“不要向外部服务发送数据、不要执行部署操作”。涉及 API 调用时，限定可调用的 endpoint 范围。
 
-* 除非任务目标涉及部署或发布，query 中应写明"不要向外部服务发送数据"或"不要执行部署操作"
-* 涉及 API 调用的任务，query 中应限定可调用的 endpoint 范围
+安全护栏不要“禁止一切”，而是根据任务精确开放必要权限。例如“每天跑 `npm test`”不需要 push 权限；“自动修复并 push”需要 push，但必须限定分支。
 
-**安全护栏的设计思路**：不是用"禁止一切"来实现安全，而是根据任务的具体需要，精确地开放必要权限、关闭不必要权限。一个"每天跑 npm test"的任务不需要 push 权限；一个"自动修复并 push"的任务需要 push 但应限定分支。Creator Agent 在设计 query 时应根据用户意图判断哪些权限是必要的，主动为不需要的操作设置护栏。
+### 引用 Skills 和 Rules
 
-**Agent 已知的上下文**：
+执行 Agent 加载的 Skills/Rules 与目标 workspace 一致。
 
-* 通过 Unattended Prompt 注入，Agent 知道自己是**无人值守自动化 Session**，不会等待用户确认
-* Agent 知道触发类型、时间、workspace、Git 状态等元信息
+- workspace 不变时，可直接在 query 中写 Skill 名称或 Rule 文件名，例如：
+  - `使用 code-security skill 扫描项目安全漏洞`
+  - `遵循 code-style.mdr 中的代码规范`
+- workspace 指向不同项目时，执行 Agent 加载目标项目的配置。如需引用当前项目中的 Skill/Rule，应使用绝对路径。
+- `.comate/rules/` 下的规则会自动加载，大多数情况下无需显式引用；需要强调时提及文件名即可。
 
-**Agent 不具备的能力**：
+---
 
-* 没有本次对话的历史上下文（每次 run 是全新 Session）
-* 不会主动提问或等待用户输入（提问会导致 stall 直至超时）
-* 没有跨 run 的记忆（每次执行互相独立）
+## 策略模板库
 
-因此，query 必须是**自包含的完整指令**：所有必要信息（路径、分支、环境、步骤、边界条件）都要写在 query 里，不能依赖"Agent 应该知道"的隐含假设。但可以通过引用 Skill 和 Rule 来复用已有配置（见下方引用语法），无需在 query 中重复这些内容。
+本 Skill 附带一组策略模板，存放在 `references/` 目录下。模板不是固定流程，只在任务需要时读取，用于为中等和复杂任务定制更高质量的 query。
 
-### 在 query 中引用 Skills 和 Rules
-执行 Agent 加载的 Skills/Rules 与当前用户环境一致。**如果 workspace 路径不变**，query 中直接写 Skill 名称或 Rule 文件名即可，Agent 会自动识别：
+### 模板选择
 
-* `使用 code-security skill 扫描项目安全漏洞`
-* `遵循 code-style.mdr 中的代码规范`
+横切策略可按需叠加：
 
-**如果 workspace 指向了不同项目**，需要用绝对路径引用，因为执行 Agent 加载的是目标项目的配置：
+| 模板文件 | 覆盖内容 | 何时读取 |
+|---|---|---|
+| `references/env_setup.md` | 运行时激活、环境变量、依赖安装、非交互式约束 | 任务依赖特定运行时或环境变量时 |
+| `references/git_operations.md` | 拉代码、分支管理、提交、push | 任务涉及 Git 操作时 |
+| `references/long_running_task.md` | 超时管理、分步执行、幂等性、错误处理、自主排障 | 任务步骤多或预期耗时长时 |
 
-* Skill 路径在项目的 `.comate/skills/` 或 `~/.comate/skills/` 下查找
-* Rule 路径在项目的 `.comate/rules/` 下查找
+领域参考通常只选一个：
 
-Agent 已自动加载 `.comate/rules/` 下的所有规则，大多数情况下无需显式引用。但如果需要强调某条规则，提及文件名即可。
+| 模板文件 | 覆盖内容 | 何时读取 |
+|---|---|---|
+| `references/testing_strategy.md` | 成功标准、测试类型选择、失败处理、证据收集 | 任务核心目标是验证代码正确性时 |
+| `references/frontend_dev.md` | 前端构建验证、lint/类型检查、无 GUI 限制 | 任务涉及前端代码修改或质量检查时 |
+| `references/backend_dev.md` | 服务依赖、数据库迁移、API 测试、进程管理 | 任务涉及后端代码修改或后端运维时 |
 
----
+使用规则：
 
-## 策略模板库
-本 Skill 附带一组**策略模板**，存放在 `{skill_dir}/references/` 目录下。这些模板不是固定流程——而是按需引用的设计参考，用于为中等和复杂任务定制更高质量的 query。
+- 简单任务（单条命令即可完成）不读模板。
+- 2-3 个步骤、逻辑清晰的任务，按需读取 1-2 个模板并提取要点。
+- 多步骤端到端流程，组合读取相关模板，优先参考 `long_running_task.md`。
+- 如果模板整体适用且无需适配，可在 query 中引用模板绝对路径；不要使用 `{skill_dir}` 变量，因为执行 Agent 无法解析。
 
-### 模板分类与使用规则
-**第一类：横切策略（按需叠加，任何类型任务都可能用到）**
+---
 
-|模板文件|覆盖内容|何时读取|
-|-|-|-|
-|`references/env_setup.md`|运行时激活、环境变量、依赖安装、非交互式约束|任务依赖特定运行时或环境变量时|
-|`references/git_operations.md`|拉代码、分支管理、提交、push|任务涉及 Git 操作时|
-|`references/long_running_task.md`|超时管理、分步执行、幂等性、错误处理、自主排障|任务步骤多或预期耗时长时|
+## 工作流程
 
-**第二类：领域参考（通常只需读一个，选与项目类型匹配的）**
+> **默认新建原则**：用户要求创建 automation 时，默认直接新建一个独立任务，不要去读取、参考或对比 `~/.comate/automations/` 下已有的其他任务，也不要修改任何已有任务。只有当用户**明确**表达“修改/更新某个已有任务”时，才走下文“管理已有任务 → 修改”流程。新建时仅需检查是否存在同名任务以避免覆盖。
 
-|模板文件|覆盖内容|何时读取|
-|-|-|-|
-|`references/testing_strategy.md`|成功标准定义、测试类型选择、失败处理、证据收集|任务核心目标是验证代码正确性时（不是"跑 npm test"这种单命令，而是"修改代码后需要验证"）|
-|`references/frontend_dev.md`|前端构建验证、lint/类型检查、无 GUI 限制|任务涉及前端代码修改或前端质量检查时|
-|`references/backend_dev.md`|服务依赖、数据库迁移、API 测试、进程管理|任务涉及后端代码修改或后端运维时|
+### 1. 判断触发类型
 
-**使用规则**：
+先确认用户要的是周期性/定时自动化，还是普通一次性任务。
 
-* 第一类模板可叠加（一个任务可同时参考 env_setup + git_operations）
-* 第二类模板通常只需读一个（项目是前端就读 frontend_dev，是后端就读 backend_dev）
-* **简单任务（单条命令即可完成）：不读任何模板**
+- 如果是一次性任务，不创建 Automation，直接按普通任务处理或说明不适用。
+- 如果是 webhook、CI 成功、PR 合入、收到 POST 请求等事件触发，说明当前 MVP 不支持，并建议 cron 轮询替代。
+- 如果是每天、每周、每月、每 N 分钟/小时等定时需求，继续收集配置。
 
-### 使用方式
-1. **分析用户 query**：理解任务本质——是简单的脚本执行？代码修改？还是多步骤的端到端流程？
-2. **按需读取相关模板**：只读取与用户任务相关的模板
-3. **提取策略融入 query 或直接引用**：
+### 2. 收集必要信息
 
-    * 如果模板中的策略需要针对用户项目做具体适配（如替换具体命令、路径），则从模板中提取要点写进 query
-    * 如果模板整体适用且无需适配，可以在 query 中引用模板的**绝对路径**让执行 Agent 自行读取，例如：`关于 Git 操作细节，参考 /Users/xxx/.comate/skills/create-automation/references/git_operations.md`（注意：必须使用绝对路径，不能用 `{skill_dir}` 变量，因为执行 Agent 无法解析该变量）
+必填信息缺失时主动询问；已明确的信息不要重复问。
 
----
+- **做什么**：任务目标，即 `AUTOMATION.md` body 的核心内容。
+- **项目路径（workspace）**：`execution.workspace` 是必填字段，每次生成的 `AUTOMATION.md` 都必须写入。默认且通常应为当前提问项目的 workspace 绝对路径，无需向用户确认即可直接使用。仅当用户在本次请求中**明确指定**了其他路径时，才使用指定路径，此时提醒执行 Agent 会加载目标项目的 Comate 配置，并按下文要求在总结中告知该 automation 不绑定到当前项目、在本项目 automation 列表中不可见。
+- **触发时间**：调度完全由 cron 表达式决定。用户明确说明频率和时间点时按用户说的精确时间翻译，不要擅自偏移分钟；完全未提及时询问“多久跑一次、大概什么时间段”；只说“每天一次”这类模糊频率时，可用合理默认值如 `09:00`，并在摘要中说明假设。
+- **push 目标分支**：仅当任务涉及 git push 时必问。Automation 在 YOLO 模式下运行，一旦满足条件会直接 push，不会再次确认。不能推断 `main` / `master` / 默认分支，必须让用户明确给出分支名。
 
-## 你的职责
-### 创建任务
-**1. 收集必填信息**
+按需询问：
 
-必问（用户未提及时主动询问）：
+- Git：是否需要先拉最新代码、使用哪个 remote。
+- 测试：是否需要运行测试、具体命令是什么。
+- 执行环境：Python venv/conda、Node nvm、Java/Go 版本、需要 source 的文件、环境变量、配置文件路径等。
+- 模型选择：简单任务可省略 `model`；复杂任务从 Available Models 中选择同系列最新版本 + `-Thinking` 变体；用户指定模型时，先在列表中确认精确名称。
+- 超时时长：默认 `3600`，上限 `7200`。
 
-* **做什么**：任务目标 → AUTOMATION.md body 核心内容
-* **项目路径**：默认使用当前 IDE 打开的项目路径。如果用户指定了不同的项目路径，主动提醒用户：执行 Agent 会加载**目标项目**的 Comate 配置（Skills/Rules），而非当前项目的。如果用户的 query 需要引用当前项目中的 Skill 或 Rule，应在项目的 `.comate/skills/` 或 `~/.comate/skills/` 下查找其绝对路径，并在 query 中使用绝对路径引用
-* **触发时间（= cron 表达式）**：Automation 没有独立的"执行时间"配置项，调度完全由 cron 表达式决定，设置后立即按 cron 周期执行。若用户已明确说明频率和时间点（如"每天早上9点"），直接翻译为 cron；若用户完全未提及频率，询问"多久跑一次、大概什么时间段"；若用户给了模糊描述（如"每天跑一次"但没说几点），可用合理默认值（如 09:03）并在摘要中说明，让用户有低成本纠正机会。
-* **push 目标分支**（仅当任务涉及 git push 时）：⚠️ **YOLO 模式下 push 无人拦截，必须在创建前确认目标分支**。不可推断（即使 `main` 是最常见的默认值），因为 push 错分支可能直接触发 CI/CD 部署到生产。向用户明确提示："Automation 在 YOLO 模式下运行，一旦满足条件 Agent 会直接 push，不会再次确认，请确认目标分支。"
+判断规则：
 
-> ⛔ **含 push 操作时，无论用户是否提及分支，必须在创建前主动追问"push 到哪个分支"。直接假设 main/master 是禁止行为。** 即使用户说了"提交并推送"，也不能默认推送到 main——必须让用户亲口说出分支名。如果用户反问"你觉得呢"或"默认就行"，回复："Automation 无人值守，push 一旦执行无法拦截，需要你明确指定分支名，我不能替你做这个决定。"
-按需询问（根据任务复杂度决定要不要问，简单任务少问，复杂任务细问）：
+- 非关键、口语化参数可以合理推断，但必须在输出中说明假设。
+- 用户明确表示不确定的关键参数（环境、分支、路径等）必须追问，不要用自动检测替代追问。定时任务无人值守，自动检测选错会造成静默失败。
 
-* Git 操作（非 push 部分）：是否需要先拉最新代码？用哪个 remote？
-* 测试：改完是否跑测试？用什么命令？
-* **执行环境**（关键，环境不对则任务必然失败）：
-    * 项目依赖什么运行时？Python venv / conda 环境名？Node nvm 版本？Java/Go 版本？
-    * 需要 source 哪个文件？（如 `source ~/.bashrc`、`conda activate myenv`、`nvm use 18`）
-    * 是否依赖环境变量？（如 API Key、数据库连接串）→ 引导用户给出 `.env` 文件路径或具体值
-    * 是否依赖配置文件？（如 `.npmrc`、`settings.xml`、`kubeconfig`）→ 引导用户给出绝对路径
-    * ⚠️ **当用户表达环境不确定时（如"不确定用哪个版本""不知道装在哪"），必须追问，不要用自动检测逻辑替代追问**。理由：定时任务是无人值守执行，自动检测选错的后果是静默失败 + 延迟发现；而创建前多问一句的成本几乎为零。建议先手动在终端跑一次任务核心命令，确认环境可用后再配置自动化
+### 3. 设计 query
 
+将用户意图转成无人值守 Agent 可端到端执行的自包含指令。
 
-> **"可推断"vs"必须追问"判断规则**：
-> * 用户用模糊口语描述非关键参数（如"大概两三个小时""白天就行"）→ **可以合理推断**，但必须在输出中明确说明你做了哪些假设，让用户有低成本的纠正机会
-> * 用户明确表达不确定的关键参数（如"不确定用哪个 JDK""不知道 Python 环境"）→ **必须追问，不可推断**。环境、分支、路径等影响任务能否成功运行的参数，推断不能替代追问
->
-* **模型选择**：根据任务复杂度推荐合适模型——简单任务可省略 `model` 字段使用系统默认；复杂任务从上方 **Available Models** 章节列出的模型中挑选，**优先选择同系列最新版本 + `-Thinking` 变体**。如果用户指定了具体模型，必须从 Available Models 列表中**确认精确名称**后再写入，不要凭印象拼写
-* 超时时长、错过策略（默认 catchup_once）
+- 环境配置放在最前面，例如激活 venv、切换 Node 版本、加载环境变量。
+- 写明执行步骤、成功标准和失败时应如何处理。
+- 使用 Skill/Rule 引用减少冗余，但不要依赖对话历史。
+- 根据任务加入安全护栏：不需要的 Git、删除、部署、外部网络操作要明确禁止。
+- 简单任务保持最小充分，不额外扩展策略。例如只需写：`运行 npm test。注意：不要修改任何源代码文件，不要 commit 或 push。`
 
-**2. 设计 query（AUTOMATION.md body）**
+### 4. 写入并校验
 
-将用户意图转化为可被无人值守 Agent 端到端执行的自包含指令（参见上方"执行 Agent 的能力与约束"）。
+创建或修改 `AUTOMATION.md` 后，必须立即运行校验脚本。编辑和校验是一个原子操作；缺少校验就不算完成。
 
-**query 设计的第一原则：最小充分**
+```bash
+mkdir -p ~/.comate/automations/{taskName}
+python3 {skill_dir}/scripts/check_config.py ~/.comate/automations/{taskName}/AUTOMATION.md
+```
 
-在设计 query 之前，先判断任务复杂度，选择对应策略：
+校验脚本会检查 frontmatter YAML、必填字段、cron 语法等。若报错，根据提示修正后再次校验，直到通过。
 
-* **一条命令能完成**（跑测试、lint、生成报告）→ 直接写命令，**不读取任何模板，不添加任何额外策略**。示例 query：`运行 npm test。`
-* **2-3 个步骤，逻辑清晰**（依赖更新 + 测试验证）→ 按需读取 1-2 个模板，提取适用要点
-* **多步骤端到端流程**（拉代码 → 修改 → 测试 → push）→ 读取多个模板组合设计，参考 `long_running_task.md` 设计分步方案
+### 5. 总结给用户
 
-设计要点：
+校验通过后，给出简洁摘要。
 
-* **环境配置写在 query 最前面**（如果需要的话）：Agent 在全新 Session 中启动，不会继承用户终端的环境。参考 `references/env_setup.md` 中的策略
-* **利用 Skills/Rules 引用减少 query 冗余**：不需要在 query 中重复写 Rules 中已有的规范，Agent 会自动加载。但可以提示 Agent 注意某个 Rule 或使用某个 Skill（见上方"引用 Skills 和 Rules"语法）
-* **显式写入安全护栏**：根据上方"无人值守安全原则"，为任务不需要的危险操作设置禁止条款。例如一个只做测试的任务，query 末尾应加上"注意：不要修改任何源代码文件，不要 commit 或 push。"一个需要 push 的任务，应限定分支范围
-* 所有必要信息写进 query（不能依赖对话历史或隐含假设）
+必含项（每次都要写）：
 
-**3. 写入文件并校验（写入后必须立即校验）**
+- 配置文件路径：`~/.comate/automations/{taskName}/AUTOMATION.md`
+- 绑定项目：任务绑定的 `workspace` 路径，让用户清楚任务挂在哪个项目下
+- 使用模型：`execution.model` 的值；省略该字段时说明使用系统默认模型
+- cron：表达式 + 人类可读描述，例如 `0 9 * * 1-5` → 周一至周五 09:00（Asia/Shanghai）
+- 核心执行逻辑：一句话说明任务会做什么
+- 引导操作：建议在 Automations 配置列表中找到该任务，点击“立即运行”先跑一次，调整效果到满意程度，执行过的任务可在 Automations 执行记录列表中查看
 
-```bash
-mkdir -p ~/.comate/automations/{taskName}
-# 写入 AUTOMATION.md
-python3 {skill_dir}/scripts/check_config.py ~/.comate/automations/{taskName}/AUTOMATION.md
-```
-校验脚本验证 frontmatter 的 YAML 格式、必填字段、cron 语法等。校验通过后告知用户。若报错，根据提示修正后重新校验。
+按需提示（命中条件才写）：
 
-**4. 总结并引导用户检查**
+- query 中约定了临时文件夹/临时文件时：提醒其路径、用途，以及任务结束后是否会清理
+- `workspace` 不是当前提问项目（用户指定了其他路径）时：显著提示该 automation 绑定的是 `{workspace}`，不属于当前项目，在当前项目的 automation 列表中不可见
+- 任务与当前项目完全无关（目标与操作对象都不涉及当前项目）时：友好提示用户确认 workspace 绑定是否符合预期
 
-校验通过后，向用户输出一份简洁的完成摘要，必须包含：
+---
 
-* **配置文件路径**：`~/.comate/automations/{taskName}/AUTOMATION.md`（用户可自行打开检查内容是否符合预期）
-* **cron 的人类可读描述**（如"每天 09:03，Asia/Shanghai 时区"）
-* **核心执行逻辑**：一句话说明任务会做什么
+## 管理已有任务
 
-> "配置已写入 `~/.comate/automations/{taskName}/AUTOMATION.md`，你可以打开该文件检查内容是否符合预期。如需修改直接告诉我。建议先去 Automations Dashboard 找到该任务，点击**立即运行（Run Now）**跑一次，在 Session History 中查看结果。"
-### 管理已有任务
-#### 查看
-读取 AUTOMATION.md 展示任务配置和 query 内容。
+### 查看
 
-#### 修改（编辑 + 校验是一个原子操作，缺校验 = 未完成）
-修改任务的流程与创建任务的 Step 3 完全一致：**编辑文件和运行校验是不可分割的一个操作**，不存在"只编辑不校验"的合法状态。
+读取任务的 `AUTOMATION.md`，展示 frontmatter 配置和 query 内容。展示 cron 时必须附带人类可读描述。
 
-**执行步骤**：
+### 修改
 
-1. 编辑 AUTOMATION.md 中需要修改的字段
-2. **编辑完成后，立即运行校验**（这一步不是可选的后续动作，而是编辑操作的收尾部分——就像 `git commit` 之后必须检查是否成功一样）：
+修改流程与创建任务一致：编辑后立即运行校验脚本，校验通过后才算完成。
 
-```bash
-python3 {skill_dir}/scripts/check_config.py {taskDir}/AUTOMATION.md
-```
-3. 校验结果必须在回复中明确告知用户（"校验通过" 或 "发现错误 + 已修复"）。如果校验报错，修正后**再次运行校验**直到通过。
-4. 如果修改了 cron 表达式，检查分钟字段是否避开 0、15、30、45（参见"Cron 分钟字段避开整点"规则）。用户说"下午 2 点"→ `3 14`，不是 `0 14`。
-5. 如果修改了 cron 时间、workspace 或任务逻辑，同步更新 description，保持与实际配置一致。
-6. 告知用户：校验通过后提醒 Scheduler 会自动 reload，并给出配置文件路径供用户检查。
+修改时注意：
 
-> ⛔ **判定规则**：如果你编辑了 AUTOMATION.md 但没有运行 `check_config.py`，这次修改就是未完成的——无论编辑本身是否正确。这和创建任务时 Step 3"写入文件并校验"是同一个原则。
-#### 删除（⚠️ 必须二次确认，此步骤绝对不可跳过）
-删除操作**不可撤销**（会删除 `~/.comate/automations/{taskName}/` 整个目录，包括历史 session 记录）。
+- 如果修改 cron，按用户说的精确时间设置，用户说“下午 2 点”就写 `0 14 * * *`。
+- 如果修改 cron、workspace 或任务逻辑，同步更新 `description`，保持描述与实际配置一致。
+- 回复中明确说明校验结果，并告知 Scheduler 会自动 reload。
 
-**删除的正确执行顺序——不可跳过任何一步，即使用户已经明确说了"删掉"：**
+### 删除
 
-**第一步：展示任务详情**，向用户输出以下信息：
+删除操作不可撤销，会删除 `~/.comate/automations/{taskName}/` 整个目录，包括历史 session 记录。即使用户已经说“删掉”，也必须二次确认。
 
-```
+删除前先展示：
+
+```text
 即将删除：
   任务名称：{精确匹配到的任务名}
   执行时间：{cron 的人类可读描述}
   项目路径：{workspace}
   配置文件：{AUTOMATION.md 完整路径}
 
-⚠️ 此操作不可撤销，将删除整个目录（包括历史 session 记录）。
+此操作不可撤销，将删除整个目录（包括历史 session 记录）。
 ```
-**第二步：明确询问用户是否确认**，例如："请确认是否继续删除？（回复"确认"或"取消"）"
-
-**第三步：收到用户明确回复后才执行删除**。收到"确认"才删，收到"取消"或任何模糊回复则中止。
 
-> 为什么用户明确说"删掉"仍然要确认？
-> * 用户说的任务名可能是模糊匹配，找到的任务可能不是他想删的那个（如"payment-security-scan"实际匹配到"payment-service-security-scan"）
-> * 展示详情让用户肉眼核对是最后一道安全关卡，成本极低，收益很高
->
-#### 查看历史
-告知用户在 IDE Automations Dashboard → Session History 中查看。
+然后询问用户是否确认。只有收到明确“确认”才执行删除；收到“取消”或任何模糊回复都中止。
 
----
+### 查看历史
 
-## 注意事项
-* Automation 仅在 Comate 运行时触发，关闭 IDE 则不执行任何 cron
-* `triggerAt` 建议设为创建后的下一个预期执行时间点，避免立即触发补跑
-* 创建前检查是否已有同名任务（查看 ~/.comate/automations/ 下的目录）
-* timeoutSeconds 默认 3600，上限 7200
+告知用户在 IDE Automations Dashboard → Session History 中查看。排查执行问题时，引导使用 `automation-question-analyze` skill。
 
 ---
 
 ## Cron 表达式速查
-### 理解语法
-cron 的每个字段描述"这个时间维度上哪些值会触发"，五个字段同时满足才触发：
 
-```
+### 基本语法
+
+cron 为 5 字段，五个字段同时满足才触发：
+
+```text
 分(0-59)  时(0-23)  日(1-31)  月(1-12)  周(0-7, 0和7均为周日)
 ```
-|语法|含义|集合视角|
-|-|-|-|
-|`*`|该字段所有值|全集|
-|`1-5`|1 到 5|区间子集|
-|`*/5`|每隔 5 取一个（0,5,10,...）|步长子集（x mod 5 = 0）|
-|`2-10/3`|区间内步长，{2,5,8}|区间内步长子集|
-|`1,3,5`|仅 1、3、5|显式枚举集合|
-
-### 常用表达式对照
-|用户说法|cron 表达式|向用户展示时说|
-|-|-|-|
-|每天早上9点|`3 9 * * *`|每天 09:03|
-|工作日早上9点|`3 9 * * 1-5`|周一至周五 09:03|
-|每周一早上10点|`3 10 * * 1`|每周一 10:03|
-|每4小时|`7 */4 * * *`|每4小时（00:07/04:07/08:07...）|
-|每30分钟|`*/30 * * * *`|每30分钟|
-|每天午夜|`3 0 * * *`|每天 00:03|
-|每月1号9点|`3 9 1 * *`|每月1日 09:03|
-|每周一、三、五下午5点|`3 17 * * 1,3,5`|周一、三、五 17:03|
-
-### 向用户展示配置时
-展示 cron 表达式时，**始终附带人类可读描述**，例如：
-
-> `cron: "0 9 * * 1-5"` → 执行时间：**周一至周五 09:00**
-### Cron 分钟字段避开整点（强制规则，创建和修改均适用）
-生成或修改 cron 表达式时，分钟字段**禁止使用 0 和 30**。大量用户倾向于设置整点和半点，导致这些时刻并发触发量激增，影响系统稳定性和用户体验。
-
-**此规则同时适用于创建新任务和修改已有任务的 cron 表达式**。修改任务时间时，不要简单地把用户说的"下午 2 点"翻译为 `0 14`，同样需要偏移分钟字段。
-
-具体规则：
-
-* 用户说"大概早上9点" → 用 `3 9 * * *`（09:03），不用 `0 9 * * *`
-* 用户说"每小时" → 用 `7 * * * *`（每小时的第7分钟），不用 `0 * * * *`
-* 用户说"下午5点半" → 用 `27 17 * * *`（17:27），不用 `30 17 * * *`
-* 用户明确指定了精确时间（如"必须 9:00 整"）→ 尊重用户要求，但提醒可能存在并发问题
-
-选择分钟数时，优先使用 1-9 或 31-39 范围内的数字，避开 0、15、30、45 等常见值。
+
+| 语法 | 含义 | 集合视角 |
+|---|---|---|
+| `*` | 该字段所有值 | 全集 |
+| `1-5` | 1 到 5 | 区间子集 |
+| `*/5` | 每隔 5 取一个（0,5,10,...） | 步长子集 |
+| `2-10/3` | 区间内步长，{2,5,8} | 区间内步长子集 |
+| `1,3,5` | 仅 1、3、5 | 显式枚举集合 |
+
+### 常用表达式
+
+| 用户说法 | cron 表达式 | 向用户展示时说 |
+|---|---|---|
+| 每天早上 9 点 | `0 9 * * *` | 每天 09:00 |
+| 工作日早上 9 点 | `0 9 * * 1-5` | 周一至周五 09:00 |
+| 每周一早上 10 点 | `0 10 * * 1` | 每周一 10:00 |
+| 每 4 小时 | `0 */4 * * *` | 每 4 小时（00:00/04:00/08:00...） |
+| 每 30 分钟 | `*/30 * * * *` | 每 30 分钟 |
+| 每天午夜 | `0 0 * * *` | 每天 00:00 |
+| 每月 1 号 9 点 | `0 9 1 * *` | 每月 1 日 09:00 |
+| 每周一、三、五下午 5 点 | `0 17 * * 1,3,5` | 周一、三、五 17:00 |
+
+### 按用户指定的时间设置
+
+cron 的时间点完全尊重用户的说法，用户说几点就设几点，不要为了错开并发而擅自偏移分钟。
+
+- 用户说“早上 9 点” → `0 9 * * *`，不要改成 `3 9 * * *`。
+- 用户说“每小时” → `0 * * * *`。
+- 用户说“下午 5 点半” → `30 17 * * *`。
+- 用户只给模糊频率（如“每天一次”）且未指定时间点时，才可用合理默认值（如 `09:00`），并在摘要中说明假设。
+
+---
+
+## 其他注意事项
+
+- Automation 仅在 Comate 运行时触发；关闭 IDE 后不会执行 cron。
+- 创建前检查 `~/.comate/automations/` 下是否已有同名任务。
+- `timeoutSeconds` 默认 `3600`，上限 `7200`。
+- 配置写入并校验通过后，Scheduler 会自动 reload。

package/comate-engine/assets/skills/figma2code/SKILL.md

@@ -8,6 +8,7 @@ disable-model-invocation: true
 【设计稿图片】： 上下文中的图片
 【设计稿名称】：选中的设计稿信息中的name字段。
 【图片目录】：选中的设计稿信息中的assetsPath字段
+【预览用html路径】：选中的设计稿信息中的previewPath字段，仅供在浏览器打开，请勿读取文件内容
 【设计稿图片可访问url】：选中的设计稿图片的可访问链接，非特殊要求请勿使用。
 【designTokenPath】：选中的设计稿信息中的designToken.md的路径,非特殊要求请勿使用。
 【image2designMode】：用户配置项，表明是否使用image2design模式。
@@ -19,23 +20,26 @@ disable-model-invocation: true
 
 # 步骤
 请务必严格遵循该步骤。
-1. 项目分析
+1. 预览html
+在任务开始前请提示用户预览页面。可以通过命令行工具打开【预览用html路径】，为用户提供预览，如果用户跳过，则继续后续流程。
+
+2. 项目分析
    - 项目使用的技术栈（仅在未检测到使用其他css框架或用户要求的情况下才使用原生CSS。）
    - **组件注册方式**（如何导入/导出组件，组件如何被使用）
    - **页面路由配置**（路由系统如何工作，新组件如何集成到路由中）
    - 项目的构建和编译系统（webpack/vite/其他）
 
-2. 设计稿分析
+3. 设计稿分析
   - 请基于【设计稿图片】分析页面结构和语义。如果用户开启了【image2designMode】则基于references/image2md.md 的流程进行分析。
   - 组件识别与引入，请基于references/codeConnect.md 遵循Code Connect指南分析设计稿组件。
 
 
-2. 图片资源管理
+4. 图片资源管理
    - 请使用终端命令一次性将需要的图像复制到项目中的合适目录中 (请避免一个一个复制图片，使用一个命令复制整个图片目录)，并记住复制后的【图片目录】。注意无需执行终端命令检查目录中是否有图片。
    - 请确保在项目中使用正确的方法引用【图片目录】中的图片资源。【图片目录】中的图片名称和html代码中的图片名称是一致的。
 **请注意tailwind框架中不要使用bg-[url]来引入本地图片资源，比如bg-[url('/images.png')]，而是使用style中的background-image属性。**
 
-3. 代码生成
+5. 代码生成
    - 根据读取的userRule和上述分析，生成对应代码。
 
 # 其他

package/comate-engine/assets/skills/icode/references/feature/submit-cr.md

@@ -326,7 +326,7 @@ UI 返回 JSON：
 ```bash
 __silent: cd <workspace> && git add -A
 cd <workspace> && git commit -m "<commitMessage>"
-__silent: cd <workspace> && $ICODE_CLI git push_cr
+__silent: cd <workspace> && $ICODE_CLI git push_cr --branch <branch>
 ```
 
 ---

package/comate-engine/assets/skills/icode/scripts/build_git_commit_payload.py

@@ -43,6 +43,22 @@ def _get_current_branch(workspace):
     return ""
 
 
+def _get_upstream_branch(workspace):
+    """获取当前分支的上游远端分支名（strip remote 前缀）"""
+    try:
+        result = subprocess.run(
+            ["git", "rev-parse", "--abbrev-ref", "--symbolic-full-name", "@{upstream}"],
+            capture_output=True, text=True, encoding="utf-8", errors="replace",
+            timeout=10, cwd=workspace
+        )
+        if result.returncode == 0 and result.stdout.strip():
+            upstream = result.stdout.strip()
+            return upstream.split("/", 1)[-1] if "/" in upstream else upstream
+    except (subprocess.TimeoutExpired, FileNotFoundError, OSError):
+        pass
+    return ""
+
+
 def _get_remote_branches(workspace, current_branch):
     try:
         result = subprocess.run(
@@ -74,7 +90,9 @@ def _build_workspace_entry(workspace_path, diff_info):
     repo_name = os.path.basename(workspace_path)
 
     if has_changes:
-        current_branch = _get_current_branch(workspace_path)
+        local_branch = _get_current_branch(workspace_path)
+        upstream_branch = _get_upstream_branch(workspace_path)
+        current_branch = upstream_branch or local_branch
         remote_branches = _get_remote_branches(workspace_path, current_branch)
         diff_summary = {
             "changed_files": diff_info.get("changed_files", []),