@comate/zulu 1.4.0-beta.3 → 1.4.0-beta.5

package/comate-engine/assets/skills/code-review/SKILL.md

@@ -2,6 +2,7 @@
 name: code-review
 description: >-
   使用此 skill 审查代码变更（git diff、暂存区改动、分支差异或指定 commit），检查 bug、安全风险、性能问题和代码质量。当用户想要审查、检视或检查代码改动时触发——包括"code review"、"review my changes"、"帮我审查代码"、"看看改动有没有问题"、"review HEAD~N"、"check my PR"、"CR"、"帮我过一遍"、"这段改动有没有问题"，或任何在合入/推送前评估代码变更是否正确安全的请求。此 skill 检查 diff 并输出按优先级排序的问题清单与修复建议。
+disable-model-invocation: true
 ---
 
 # Code Review
@@ -20,11 +21,11 @@ description: >-
 
 ## SubAgent 调用规范
 
-本 skill 通过 `delegate_subtask` 工具启动审查 SubAgent。每个 SubAgent 是独立的 Agent 实例，拥有只读工具集，能够自行获取 diff、搜索代码库、读取文件。
+本 skill 通过 `delegate_subagent` 工具启动审查 SubAgent。每个 SubAgent 是独立的 Agent 实例，拥有只读工具集，能够自行获取 diff、搜索代码库、读取文件。
 
 - **agent_type 固定为 `"Explore"`**
 - **query**：只传递路径和范围，**不注入文件原文**——让 SubAgent 自行读取指令文件
-- 深度审查模式下，所有 `delegate_subtask` 调用**必须在同一轮响应中并行发起**，不要串行等待
+- 深度审查模式下，所有 `delegate_subagent` 调用**必须在同一轮响应中并行发起**，不要串行等待
 
 > Query 构建模板和各模式的完整调用示例见 `{SKILL_DIR}/references/dispatch-template.md`。主 Agent 执行 Step 3/4/5 时须读取该文件获取模板。
 
@@ -100,7 +101,7 @@ description: >-
 
 #### 自定义规则探测
 
-检查 `{SKILL_DIR}/references/custom-rules/` 目录：
+检查仓库根目录下 `.comate/custom-rules/` 目录：
 - 如果存在**非模板**的 `.md` 文件（`RULE_TEMPLATE.md` 不算）→ 标记 `HAS_CUSTOM_RULES = true`
 - 如果目录不存在、为空或只有 `RULE_TEMPLATE.md` → 标记 `HAS_CUSTOM_RULES = false`
 
@@ -116,7 +117,7 @@ description: >-
 
 设 `SKILL_DIR` 为本 skill 目录的绝对路径（即 SKILL.md 所在目录）。
 
-按 `{SKILL_DIR}/references/dispatch-template.md` 中对应模式（常规/深度）的模板发起 `delegate_subtask` 调用。若 `HAS_CUSTOM_RULES = true`，在同一轮响应中追加 custom-reviewer 调用。
+按 `{SKILL_DIR}/references/dispatch-template.md` 中对应模式（常规/深度）的模板发起 `delegate_subagent` 调用。若 `HAS_CUSTOM_RULES = true`，在同一轮响应中追加 custom-reviewer 调用。
 
 每个 SubAgent 会自行读取对应的 reviewer 指令和输出格式，自行决定重点关注 diff 的哪些部分。
 
@@ -190,7 +191,7 @@ SubAgent 通过 `SKILL_DIR` 路径自行读取以下文件：
 - `references/dispatch-template.md`：SubAgent 调度模板（主 Agent 读取）
 - `references/report-format.md`：报告输出格式（主 Agent 读取）
 - `references/telemetry.md`：埋点上报逻辑（主 Agent 读取）
-- `references/custom-rules/*.md`：用户自定义审查规则文件（`RULE_TEMPLATE.md` 为模板，不参与扫描）
+- `.comate/custom-rules/*.md`：用户自定义审查规则文件（位于仓库根目录，`RULE_TEMPLATE.md` 为模板，不参与扫描）
 
 ## 备注
 

package/comate-engine/assets/skills/code-review/agents/custom-reviewer.md

@@ -10,11 +10,11 @@
 
 ## 第一步：加载自定义规则文件
 
-读取 `../references/custom-rules/` 目录下的所有 `.md` 文件。
+读取仓库根目录下 `.comate/custom-rules/` 目录中的所有 `.md` 文件。
 
 - 如果该目录不存在或没有任何 `.md` 文件（仅有模板文件 `RULE_TEMPLATE.md` 不算），直接返回：
   ```json
-  {"reviewer": "custom", "summary": "未找到自定义规则文件，跳过扫描。请在 references/custom-rules/ 目录下添加规则文件。", "findings": []}
+  {"reviewer": "custom", "summary": "未找到自定义规则文件，跳过扫描。请在 .comate/custom-rules/ 目录下添加规则文件。", "findings": []}
   ```
 - 如果规则文件中声明了适用语言或适用范围（`applies_to` 字段），只加载与变更文件语言/路径匹配的规则文件，忽略不相关的规则文件
 - 加载所有满足条件的规则文件后，合并全部规则，准备扫描

package/comate-engine/assets/skills/code-review/agents/meta-reviewer.md

@@ -15,7 +15,7 @@
 
 对每个 finding，默认立场是"这条可能是噪音"，要求它自证价值：
 - **问题是否真实存在**？读取对应文件和行号，确认 finding 描述的问题确实存在于代码中。如果无法通过读取代码确认，直接移除
-- **问题是否有实际影响**？即使问题存在，它是否会在真实场景中被触发？纯理论风险、极端边界条件、概率极低的竞态应降级到 P3 或移除
+- **问题是否有实际影响**？即使问题存在，它是否会在真实场景中被触发？纯理论风险、极端边界条件、概率极低的竞态应降级到 P3 或移除。**例外：来源为 `style-reviewer` 的 finding 不适用本项检查——格式问题本身没有运行时后果，问题存在即成立，不以"影响"为移除依据**
 - **严重等级是否合理**？一个 P1 的问题是否真的会在合入后造成显著影响？一个 P3 的问题是否可能比标注的更严重？
 - **建议是否可执行**？"应该优化"这种建议不够具体，需要给出怎么优化
 - **证据是否充分**？复用审查中提到的"已有函数"是否真的存在并且签名兼容？
@@ -80,5 +80,5 @@
 
 - **积极过滤**：对每条 finding 的默认态度是怀疑而非信任。常见的移除理由包括但不限于：代码行在 diff 中不存在或被误读、问题已被上下文代码处理、基于对语言/框架的错误理解、纯理论风险在真实场景中不会触发。如果无法确定是否应该移除，优先用 adjust_severity 降级而非保留原样
 - **不要凭空添加**：missed_findings 必须基于你对 diff 的实际分析，不要为了"找到遗漏"而强行添加
-- **宁缺毋滥**：给用户 3 条高价值 finding 远比 10 条掺杂噪音的 finding 有用。对于无法明确说出"这个问题在什么场景下会造成什么后果"的 finding，果断移除或降级
+- **宁缺毋滥**：给用户 3 条高价值 finding 远比 10 条掺杂噪音的 finding 有用。对于无法明确说出"这个问题在什么场景下会造成什么后果"的 finding，果断移除或降级。**例外：`style-reviewer` 的 finding 不适用"说出后果"的要求——格式类问题天然没有运行时后果，只要格式违规存在于代码中即为有效 finding，不得以此为由移除或降级**
 - **结果自检**：审核完成后回顾整体结果——如果几乎没有移除或调整，考虑是否审核力度不足；如果大面积移除，考虑是否对变更类型的理解有偏差

package/comate-engine/assets/skills/code-review/agents/style-reviewer.md

@@ -2,7 +2,10 @@
 
 ## 核心原则
 
-- **有规则文件时严格按规则扫描**：匹配到支持语言时，只报告规则文件中明确列出的问题
+- **有规则文件时逐条扫描，不得遗漏**：对规则文件中的每一条规则都必须逐一检查，即使某条规则出现频率低也不得跳过
+- **"不确定"只限于具体 case 的判定，不允许用于跳过整条规则**：对于某个代码片段是否触发规则存疑时可不报；但每条规则本身必须被检查到
+- **行长度规则无豁免**：超过规定长度的行（Python/Java/JS ≤120字符，Go ≤160字符）**无论什么情况都必须报告**，包括字符串字面量、URL、注释、import 语句等所有场景，不得以任何理由跳过
+- **输出前必须确认每条规则都被检查**：在输出结果前，强制逐条对照规则清单确认，特别关注容易被忽略的类型（行长度、命名、编程实践等）
 - **无规则文件时基于通用知识审查**：未匹配到支持语言时，基于你对该语言的编码规范知识进行审查，只报有明确代码证据的问题，不报纯风格偏好
 - **来自 [Critical] 标记规则的 finding，必须设置 `locked: true`**，Meta-Review 不得修改其 severity
 - 来自非 [Critical] 规则的 finding 不设 locked（或 `locked: false`）
@@ -24,16 +27,77 @@
 
 ---
 
-## 第二步：审查
+## 第二步：按语言确认扫描范围
 
-### 分支 A：有规则文件（匹配到支持语言）
+加载规则文件后，按下表确认本次需覆盖的规则总数与大类，扫描时必须全部过一遍：
+
+### Java（`.java` 文件）— 共 14 条规则
+
+| 大类 | 规则数 | 规则 ID 与检查项 | 扫描要点 |
+|------|--------|----------------|---------|
+| Import | 2 | JAVA010 未使用 import；JAVA008 禁通配符 import | 检查所有 import 语句，识别通配符 `*` 和未使用的引用 |
+| 命名 | 3 | JAVA028 方法名小驼峰；JAVA029 常量全大写下划线；JAVA032 包名纯小写 | 检查方法名、常量名、package 声明 |
+| 格式 | 5 | JAVA018 单行≤120字符；JAVA003 禁 Tab 缩进；JAVA014 左花括号 K&R；JAVA068 控制语句必须花括号；JAVA020 关键字/运算符周围空格 | JAVA018: 逐行计算；JAVA014: 检查花括号位置；JAVA020: 关注 `if/for/while` 等关键字和运算符 |
+| 结构 | 1 | JAVA013 重载方法必须相邻 | 检查同名方法的定义位置 |
+| 注释 | 1 | JAVA070 类/public字段/public方法注释必须用 Javadoc | 检查类、public 字段、public 方法是否有 `/** */` 格式的注释 |
+| 编程实践 | 2 | JAVA044 equals 防 NPE（字面量放左）；JAVA041 覆写方法必须加 @Override | 检查 `equals` 调用；检查所有覆写方法是否带 `@Override` 注解 |
+
+### Python（`.py` 文件）— 共 8 条规则
+
+| 大类 | 规则数 | 规则 ID 与检查项 | 扫描要点 |
+|------|--------|----------------|---------|
+| 格式 | 4 | PY023 单行≤120字符；PY030 逗号/分号/冒号空格；PY031 二元运算符前后空格；PY032 关键字参数等号不加空格 | PY023: 逐行计算字符数；PY030-PY032: 关注符号和运算符周围的空格 |
+| 文档 | 2 | PY033 module/function/class/method 必须有 docstring（三双引号）；PY034 docstring 须含功能简介、Args、Returns | 检查所有函数、类、方法是否缺少 docstring 或使用单引号 |
+| 编程实践 | 1 | PY018 禁止用 `==`/`!=` 判断 None，应使用 `is`/`is not` | 搜索所有 `== None` 和 `!= None` 的模式 |
+| 命名 | 1 | PY039 类名（含异常类）必须大驼峰 PascalCase | 检查所有 `class` 关键字后的类名 |
+
+### Go（`.go` 文件）— 共 17 条规则
+
+| 大类 | 规则数 | 规则 ID 与检查项 | 扫描要点 |
+|------|--------|----------------|---------|
+| 命名 | 4 | GoRule001 驼峰命名+缩写词全大写；GoRule002 包级 error 变量加 Err/err 前缀；GoRule004 receiver 名称简短且一致；GoRule006 包内类型不以包名为前缀 | 检查变量名、常量名、receiver 名称；检查 package 级别 error 变量命名 |
+| 格式 | 3 | GoRule102 源文件 UTF-8 编码；GoRule103 单行≤160字符；GoRule301 使用 tab 缩进 | GoRule103: 逐行计算字符数；GoRule301: 检查缩进是否为 tab |
+| Import | 3 | GoRule307 import 按标准库→第三方→项目内分三组；GoRule308 禁止点号 import；GoRule309 `_` import 必须加注释说明原因 | 检查 import 语句分组；检查 `.` import 和 `_` import |
+| 错误处理 | 5 | GoRule201 通过 go vet 检查（copy lock/loop closure/lost cancel/struct tag/printf）；GoRule202 if/for 中禁止对 bool 做等值比较；GoRule204 error 必须作最后一个返回值；GoRule205 函数返回的 error 必须处理；GoRule206 包装 error 用 `%w` | 检查所有返回 error 的函数调用是否被处理；检查 bool 类型的等值比较；检查 error 包装格式 |
+| Error String | 1 | GoRule310 error string 首字母不大写，结尾不带标点 | 检查所有 `fmt.Errorf` 和 `errors.New` 的字符串参数 |
+| 编程实践 | 1 | GoRule203 if 块以 return 结尾时删除 else（early return 风格） | 检查 if-else 结构，当 if 块以 return 结尾时应删除 else |
+
+### JavaScript / TypeScript（`.js` `.ts` `.jsx` `.tsx` `.vue` `.css` 等）— 共 35 条规则
 
-对每个变更文件，按照对应语言的规则文件逐条扫描：
+| 子类 | 规则数 | 主要检查项 | 扫描要点 |
+|------|--------|-----------|---------|
+| JS 通用 | 24 | 行尾空白、引号风格（单引号）、分号、行长度≤120、控制语句花括号、尾逗号、禁多余空格、逗号空格、运算符空格、函数括号前空格、注释空格、对象冒号空格、关键字空格、对象花括号不加空格、点号访问、代码块前空格、箭头函数参数括号、每行单语句、严格相等（===）、运算符换行位置、禁混用空格Tab、箭头符号空格、禁混淆箭头函数、parseInt 必须指定基数 | 检查所有字符串引号是否为单引号；逐行计算字符数；检查 `if/for/while` 是否有花括号；检查所有 `==` 应改为 `===`；检查 parseInt 是否有第二个参数 |
+| Vue 专项 | 8 | 每行最多2个属性；HTML闭合括号换行；组件属性 kebab-case；禁未使用 ref；插值花括号内加空格；禁未使用 v-for 变量；禁多模板根元素；button 必须有 type | 检查模板属性数量；检查 ref 变量是否被使用；检查 v-for 变量是否被使用；检查 button 是否有 type 属性 |
+| React 专项 | 1 | JSX 缩进4空格 | 检查 JSX 元素的缩进层级 |
+| San 专项 | 1 | HTML 缩进4空格 | 检查 HTML 标签的缩进层级 |
+| CSS 专项 | 1 | CSS 规则块之间必须有空行 | 检查 CSS 选择器块之间是否有空行 |
 
-1. 精确定位问题行号
-2. 确认问题在源文件中真实存在（源文件复核）
-3. 记录触发的规则名称（包含其标记：[Critical] 或 [high]/[middle]/[low]）
-4. 宁缺毋滥：不确定的不报
+> **注意**：JS 文件只检查 JS 通用规则；`.vue` 文件额外检查 Vue 专项；`.jsx`/`.tsx` 文件额外检查 React 专项；CSS/SCSS 文件检查 CSS 专项。
+
+---
+
+## 第三步：审查
+
+### 分支 A：有规则文件（匹配到支持语言）
+
+**按以下流程逐条过规则，确保不遗漏：**
+
+1. **建立规则清单**：从规则文件中提取所有规则编号（如 Python 的 PY023, PY030-PY034, PY018, PY039），作为本次扫描的 checklist
+2. **显式遍历检查**：对清单中的**每一条规则**，依次执行以下步骤：
+   - 阅读该规则的完整描述（包括豁免场景）
+   - 在变更文件中专门查找该规则对应的代码模式
+   - 对匹配到的每个位置判断是否违规（结合豁免场景）
+   - 如果是违规，精确定位行号并记录
+3. **发现问题时**：
+   - 精确定位问题行号
+   - 确认问题在源文件中真实存在（源文件复核）
+   - 记录触发的规则编号和名称（含标记：[Critical] / [high] / [middle] / [low]）
+4. **边界模糊时**：对某个具体 case 无法判定是否违规，可跳过该 case，但**该规则的其他明确 case 仍需检查**
+5. **输出前的强制自检**：在输出结果前，**必须确认**：
+   - 检查清单中的每条规则都被检查过了
+   - 特别关注容易被忽略的规则类型（如行长度、命名、编程实践等）
+   - 如果发现某条规则未被检查，立即补检
+6. **完成后**：每条规则都必须被检查到，形成完整覆盖
 
 ### 分支 B：无规则文件（未匹配到支持语言）
 
@@ -45,8 +109,6 @@
 
 ## 严重等级参考
 
-规范类问题的 severity 按以下原则分配：
-
 | 规则标记 | 建议 severity | locked |
 |---------|--------------|--------|
 | [Critical] | P0 | `true` |

package/comate-engine/assets/skills/code-review/references/dispatch-template.md

@@ -23,10 +23,10 @@
 
 ## 常规审查模式
 
-发起一个 `delegate_subtask` 调用：
+发起一个 `delegate_subagent` 调用：
 
 ```
-delegate_subtask(
+delegate_subagent(
   agent_type="Explore",
   description="Code review - 综合审查",
   query="""
@@ -50,7 +50,7 @@ delegate_subtask(
 **若 `HAS_CUSTOM_RULES = true`**，在同一轮响应中**并行**追加一个 custom-reviewer 调用：
 
 ```
-delegate_subtask(
+delegate_subagent(
   agent_type="Explore",
   description="Code review - 自定义规则扫描",
   query="你是自定义规则扫描专家。\n1. 读取审查指令：{SKILL_DIR}/agents/custom-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON"
@@ -61,28 +61,28 @@ delegate_subtask(
 
 ## 深度审查模式
 
-在**同一轮响应**中，并行发起 4 个 `delegate_subtask`。主 Agent **不需要预读**任何 agents/*.md 或 references/*.md 文件，直接按模板构建 query：
+在**同一轮响应**中，并行发起 4 个 `delegate_subagent`。主 Agent **不需要预读**任何 agents/*.md 或 references/*.md 文件，直接按模板构建 query：
 
 ```
-1. delegate_subtask(
+1. delegate_subagent(
      agent_type="Explore",
      description="Code review - 复用审查",
      query="你是代码审查专家，负责复用审查。\n1. 读取审查指令：{SKILL_DIR}/agents/reuse-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON\n{业务规则摘要}"
    )
 
-2. delegate_subtask(
+2. delegate_subagent(
      agent_type="Explore",
      description="Code review - 风格审查",
      query="你是代码审查专家，负责风格审查。\n1. 读取审查指令：{SKILL_DIR}/agents/style-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON\n{业务规则摘要}"
    )
 
-3. delegate_subtask(
+3. delegate_subagent(
      agent_type="Explore",
      description="Code review - 可靠性审查",
      query="你是代码审查专家，负责可靠性审查（资源管理、并发安全、接口鉴权）。\n1. 读取审查指令：{SKILL_DIR}/agents/reliability-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON\n{业务规则摘要}"
    )
 
-4. delegate_subtask(
+4. delegate_subagent(
      agent_type="Explore",
      description="Code review - 正确性审查",
      query="你是代码审查专家，负责正确性审查。\n1. 读取审查指令：{SKILL_DIR}/agents/correctness-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON\n{业务规则摘要}"
@@ -92,7 +92,7 @@ delegate_subtask(
 **若 `HAS_CUSTOM_RULES = true`**，在上述 4 个调用的**同一轮响应**中追加第 5 个：
 
 ```
-5. delegate_subtask(
+5. delegate_subagent(
      agent_type="Explore",
      description="Code review - 自定义规则扫描",
      query="你是自定义规则扫描专家。\n1. 读取审查指令：{SKILL_DIR}/agents/custom-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON"
@@ -108,7 +108,7 @@ delegate_subtask(
 当深度审查至少成功返回 2 个维度结果时，发起 Meta-Review：
 
 ```
-delegate_subtask(
+delegate_subagent(
   agent_type="Explore",
   description="Code review - Meta Review",
   query="""
@@ -136,7 +136,7 @@ delegate_subtask(
 
 ## 失败回退
 
-- 某个 `delegate_subtask` 失败或超时：继续合并剩余结果，报告中注明"部分维度降级"
+- 某个 `delegate_subagent` 失败或超时：继续合并剩余结果，报告中注明"部分维度降级"
 - 两个及以上失败：回退为单个综合审查（常规审查模式）
-- `delegate_subtask` 工具不可用：主 Agent 直接执行审查，报告中注明"降级为单 Agent 审查"
+- `delegate_subagent` 工具不可用：主 Agent 直接执行审查，报告中注明"降级为单 Agent 审查"
 - 上下文过大：缩小到高风险文件，必要时拆批执行

package/comate-engine/assets/skills/code-review/references/rules/Java/JAVA_STYLE_RULES.md

@@ -112,8 +112,6 @@ package org.apache.logging.log4j;
 
 **缺陷描述**：单行字符数不超过 120 个字符，超出需要换行。Tab 按 1 个字符计算。
 
-**豁免场景**：package 语句；import 语句；包含 URL 的行；单行字符串字面量。
-
 ---
 
 ### 7. JAVA003 FileTabCharacter - 禁止使用 Tab 字符 [Critical]
@@ -231,7 +229,8 @@ public class Example {
 
 ### 12. JAVA070 CommentsMustBeJavadocInSomeCase - 类/属性/方法注释必须用 Javadoc [Critical]
 
-**缺陷描述**：类、public/protected 字段、public/protected 方法的注释必须使用 `/** 内容 */` 格式，不得使用 `// xxx` 方式。
+**缺陷描述**：所有类声明（含 public 和包级类）、public/protected 字段、public/protected 方法的注释必须使用 `/** 内容 */` 格式，不得使用 `// xxx` 方式。
+
 
 **经典案例**：
 ```java
@@ -239,7 +238,9 @@ public class Example {
 // 用户服务类
 public class UserService {}
 
-// 错误写法
+// 辅助类：缺陷实现
+class DefectExample {}
+
 // 创建订单
 public Order createOrder(OrderDTO dto) {}
 
@@ -247,11 +248,16 @@ public Order createOrder(OrderDTO dto) {}
 /** 用户服务类 */
 public class UserService {}
 
+/** 辅助类：缺陷实现 */
+class DefectExample {}
+
 /** 创建订单 */
 public Order createOrder(OrderDTO dto) {}
 ```
 
-**不应报告的场景**：方法体内部的行间注释；private 成员注释；行尾注释；无注释的类/字段/方法（此规则只检查格式，不检查是否有注释）。
+**不应报告的场景**：分隔线注释（`// ===...===`）；行末尾的 `//` 注释（与代码同行，非独占一行描述用途的注释）。
+
+**核心原则：有 `//` 注释就算，不看内容。**
 
 ---
 

package/comate-engine/assets/skills/{create-automation-tasks-comate → create-automation}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: create-automation-tasks
+name: create-automation
 description: |
   帮助用户创建、配置和管理 Comate Automation 自动化任务。当用户表达以下意图时触发：
   - 创建/设置/新建自动化任务、定时任务、cron 任务
@@ -7,6 +7,7 @@ description: |
   - "每天/每周/每月自动帮我做..."
   - 配置 webhook 触发任务
   不适用于普通的一次性任务请求，仅适用于需要周期性或事件驱动执行的自动化配置。
+disable-model-invocation: true
 ---
 
 # create_automation_tasks Skill
@@ -54,8 +55,6 @@ execution:
 ---
 
 这里写任务指令（query）。必须自包含，包含所有必要上下文。
-
-完成后请将执行摘要写入 promise_done_summary.md。
 ````
 
 同一任务可配置多个 trigger（schedule 至多一个）：
@@ -122,7 +121,6 @@ AUTOMATION.md 的 body（query）会被一个独立的 Comate Agent Session 执
 **Agent 已知的上下文**：
 - 通过 Unattended Prompt 注入，Agent 知道自己是**无人值守自动化 Session**，不会等待用户确认
 - Agent 知道触发类型、时间、workspace、Git 状态等元信息
-- Agent 知道完成任务后必须写入 `promise_done_summary.md` 文件作为成功信号
 
 **Agent 不具备的能力**：
 - 没有本次对话的历史上下文（每次 run 是全新 Session）
@@ -177,7 +175,7 @@ Agent 已自动加载 `.comate/rules/` 下的所有规则，大多数情况下
 2. **按需读取相关模板**：只读取与用户任务相关的模板
 3. **提取策略融入 query 或直接引用**：
    - 如果模板中的策略需要针对用户项目做具体适配（如替换具体命令、路径），则从模板中提取要点写进 query
-   - 如果模板整体适用且无需适配，可以在 query 中引用模板的**绝对路径**让执行 Agent 自行读取，例如：`关于 Git 操作细节，参考 /Users/xxx/.comate/skills/create-automation-tasks/references/git_operations.md`（注意：必须使用绝对路径，不能用 `{skill_dir}` 变量，因为执行 Agent 无法解析该变量）
+   - 如果模板整体适用且无需适配，可以在 query 中引用模板的**绝对路径**让执行 Agent 自行读取，例如：`关于 Git 操作细节，参考 ~/.comate/skills/.system/create-automation/references/git_operations.md`（注意：必须使用绝对路径，不能用 `{skill_dir}` 变量，因为执行 Agent 无法解析该变量）
 
 ---
 
@@ -211,7 +209,7 @@ Agent 已自动加载 `.comate/rules/` 下的所有规则，大多数情况下
 
 在设计 query 之前，先判断任务复杂度，选择对应策略：
 
-- **一条命令能完成**（跑测试、lint、生成报告）→ 直接写命令 + 摘要要求，**不读取任何模板，不添加任何额外策略**。示例 query：`运行 npm test，将结果摘要写入 promise_done_summary.md。`
+- **一条命令能完成**（跑测试、lint、生成报告）→ 直接写命令，**不读取任何模板，不添加任何额外策略**。示例 query：`运行 npm test。`
 - **2-3 个步骤，逻辑清晰**（依赖更新 + 测试验证）→ 按需读取 1-2 个模板，提取适用要点
 - **多步骤端到端流程**（拉代码 → 修改 → 测试 → push）→ 读取多个模板组合设计，参考 `long_running_task.md` 设计分步方案
 
@@ -219,7 +217,6 @@ Agent 已自动加载 `.comate/rules/` 下的所有规则，大多数情况下
 - **环境配置写在 query 最前面**（如果需要的话）：Agent 在全新 Session 中启动，不会继承用户终端的环境。参考 `references/env_setup.md` 中的策略
 - **利用 Skills/Rules 引用减少 query 冗余**：不需要在 query 中重复写 Rules 中已有的规范，Agent 会自动加载。但可以提示 Agent 注意某个 Rule 或使用某个 Skill（见上方"引用 Skills 和 Rules"语法）
 - 所有必要信息写进 query（不能依赖对话历史或隐含假设）
-- 结尾加上：`完成后请将执行摘要写入 promise_done_summary.md。`
 
 **3. 展示 AUTOMATION.md 并确认**
 
@@ -237,7 +234,7 @@ python3 {skill_dir}/scripts/check_config.py ~/.comate/automations/{taskName}/AUT
 
 **5. 引导试跑**
 
-> "配置已就绪。建议先去 Automations Dashboard 找到该任务，点击**立即运行（Run Now）**跑一次，在 Session History 中查看结果是否符合预期。"
+> "配置已就绪。建议先去 Automations Dashboard 找到该任务，点击**立即运行（Run Now）**跑一次，在 Session History 中查看结果是否符合预期"
 
 ### 管理已有任务
 

package/comate-engine/assets/skills/{create-automation-tasks-comate → create-automation}/references/long_running_task.md

@@ -58,21 +58,6 @@ Automation 任务可能被重复执行（定时触发、补跑等），query 设
 
 关键原则：**区分"代码问题"和"环境问题"**。如果测试失败是因为环境配置（缺少依赖、端口占用、服务未启动），应尝试修复环境而非修改代码。至少尝试 3 种不同的修复方案后再判定为阻塞。
 
-### 执行摘要规范
-
-Automation Agent 的唯一交付物是 `promise_done_summary.md`。对于复杂任务，建议在 query 中明确摘要格式：
-
-```
-完成后将执行摘要写入 promise_done_summary.md，包含：
-- 执行了哪些步骤，每步的结果（成功/失败/跳过）
-- 如果有代码修改，列出修改的文件和改动性质
-- 关键的终端输出、测试结果数据（作为验证证据）
-- 遇到的问题和处理方式
-- 需要人工关注的事项（如：测试覆盖不足、某个修复需要人工确认等）
-```
-
-这份摘要是用户判断任务执行质量的唯一依据，应当清晰、诚实、包含充分证据。如果任务未完全成功，不要写这个文件——让 Session 以 stopped 状态结束，摘要中记录原因即可。
-
 ## query 片段示例
 
 **场景：全量安全扫描 + 自动修复**

package/comate-engine/assets/skills/{create-automation-tasks-comate → create-automation}/references/testing_strategy.md

@@ -11,7 +11,7 @@
 
 ## 核心原则
 
-**不能只靠代码静态推断来判断结果，必须依赖真实运行信息。** 日志、终端输出、测试结果都是重要证据。验证证据应写入 `promise_done_summary.md`。
+**不能只靠代码静态推断来判断结果，必须依赖真实运行信息。** 日志、终端输出、测试结果都是重要证据。
 
 ## 策略要点