feat: export core Hermes skills
This commit is contained in:
@@ -0,0 +1,92 @@
|
||||
# Workflow交付件逐份审查检查清单 (2026-07-13 Doro要求)
|
||||
|
||||
## 触发条件
|
||||
Doro说"逐一审查已交付合同的修订有哪些问题"或类似指令。
|
||||
|
||||
## 操作流程
|
||||
1. 全文阅读通用review-rules.md + 对应顾问单位特殊规则
|
||||
2. 列出今天交付的全部文件（`sudo find ... -newermt`）
|
||||
3. 一份一份审查，报告问题，等Doro说pass再做下一份
|
||||
|
||||
## 每份检查项
|
||||
|
||||
### A0. 文件完整性（先于内容）
|
||||
- `zipfile`读`word/comments.xml`看有无批注
|
||||
- 统计`w:ins`/`w:del`数量确认有修订痕迹
|
||||
- 如果有多版本（v1/v2），每个都要独立检查性质
|
||||
|
||||
### A. 格式验证
|
||||
- `wb-ins-font-verify.py` — 必须PASS
|
||||
- 原文同段run属性 vs INS run属性逐一比对
|
||||
- 新增段落pPr（ind/spacing/numPr）vs原文邻近段落
|
||||
|
||||
### B. 审查清单覆盖（10条逐条）
|
||||
1. 主体条款
|
||||
2. 违约责任（含赔偿上限删除、维权费用）
|
||||
3. 争议解决/管辖（甲方所在地法院）
|
||||
4. 保密/数据（归属+存续+泄露赔偿 三要素）
|
||||
5. 知识产权/系统
|
||||
6. 第三方侵权（全责+赔偿甲方损失）
|
||||
7. 转包/分包（限制+连带）
|
||||
8. 价款条款
|
||||
9. 服务成果持续使用权（仅持续性服务适用）
|
||||
10. 条款逻辑
|
||||
|
||||
### C. 同模板一致性
|
||||
- 同批同模板合同的修订是否完全统一
|
||||
- 特别检查：编号顺延方式、章节结构、措辞、天数
|
||||
|
||||
### D. 特殊交付物
|
||||
- 读该顾问单位review-rules.md确认是否要求审查意见文档
|
||||
- 缺失则标记
|
||||
|
||||
### E. 批注审查
|
||||
- 每条WB批注逐一比对规则
|
||||
- 立场是否正确（站甲方）
|
||||
- 是否违反"能改就不批注"
|
||||
- 是否属于提醒性批注（禁止）
|
||||
|
||||
## 报告格式
|
||||
```
|
||||
## 【修】合同名称
|
||||
|
||||
**字体验证：** PASS/FAIL
|
||||
**修订内容：** 逐条列出WB INS/DEL
|
||||
**问题：**
|
||||
1. [严重/一般] 具体问题描述
|
||||
2. ...
|
||||
**结论：** pass建议/需修复
|
||||
```
|
||||
|
||||
### F. 编号顺延完整性（2026-07-13 璞石合同教训）
|
||||
- 章节标题编号顺延后（如七→八），**子编号也必须顺延**（7.1→8.1, 7.2→8.2...）
|
||||
- Workflow常见遗漏：只改了章节标题的汉字编号（第七条→第八条），但内部子条款的阿拉伯数字编号（7.1/7.2/7.3/7.4）原封不动
|
||||
- **检查方法**：accepted text中搜索所有"X.Y"格式编号，确认X与所属章节标题的序号一致
|
||||
- 修复方法：子编号通常拆为两个run（如"7" + ".1 "），只需DEL第一个run("7")+INS新数字("8")
|
||||
|
||||
### G. 内容去重（2026-07-13 璞石合同教训）
|
||||
- 新增的保密存续条款是否与原文已有的类似表述重复
|
||||
- 典型：原文已有"乙方的保密义务不因合同解除或终止而免除"，WB又插入"本条保密义务不因本合同的终止或解除而终止"——语义完全重复
|
||||
|
||||
### H. 赔偿上限全面检查（2026-07-13 璞石合同教训）
|
||||
- 规则"赔偿上限能删就删"不仅适用于乙方赔偿甲方的上限
|
||||
- **双向条款中的上限也要删**：如"任何一方违约，违约金额为合同总金额的20%"——此上限同时限制了甲方可获赔偿
|
||||
- P43甲方自身违约金上限保留是正确的（保护甲方），但P49双向上限应删除
|
||||
- **判断方法**：上限是否限制了对方向甲方赔偿？是→删；上限是否限制了甲方向对方赔偿？是→保留
|
||||
|
||||
### I. 新增标题段落样式（2026-07-13 璞石合同教训）
|
||||
- WB新增的章节标题段（如"第七条 转包与分包"）的pStyle必须与原文标题段一致
|
||||
- 原文标题用Heading4→新增也用Heading4，不能用Style15（正文首行缩进）
|
||||
- 标题文字中"第X条"与名称之间是否有空格？原文无空格（"第六条违约责任"）则新增也不加空格
|
||||
|
||||
### J. 原文已有修订保持不动
|
||||
- 对照原文确认：WB-1/86187/杨丽/富强等原文修订人的INS/DEL/批注是否全部原样保留
|
||||
- WB的修改不能意外覆盖或嵌套进原文修订
|
||||
- P29金额"27900"的sz=22是原文86187的修订→不是workflow问题
|
||||
|
||||
## 铁律
|
||||
- 先tool call读文件再下结论（验证指令铁律）
|
||||
- 不凭上一份的印象判断下一份
|
||||
- comments.xml必须检查（2026-07-13教训）
|
||||
- **原文自带【修】前缀的文件**：按命名规则应为【修】【修】...，workflow通常不做双重前缀——记录为已知缺陷
|
||||
- **Doro说"看清楚前后文再回复"**：意思是你漏了问题或误判了严重性，必须重新逐属性检查
|
||||
Reference in New Issue
Block a user