Case facts

案件事实梳理（case-facts）

从案件材料中客观中立地提取事实信息，产出一份主文档 + 两张配图：

• 主文档：案件事实梳理（Markdown）——这是交付的核心文档，按大事记构建逻辑，依次包含三个部分：
  1. 法律关系分析图——嵌入 HTML 图的链接 + 一段配套文字说明（主体构成、核心法律关系、争议关系）
  2. 法律事实时间轴图——嵌入 HTML 图的链接
  3. 大事记——结构化时间线表，含来源标注、重要性评级、缺口提示与版本号
• 配图一：法律关系分析图（单文件 HTML）——按「两要素三步法」呈现主体与法律关系，由主文档第一部分链接引用
• 配图二：法律事实时间轴图（单文件 HTML）——按「轴线要素 + 事件要素」呈现关键事实的时间脉络，由主文档第二部分链接引用

交付结构：两张图各自是独立 HTML 文件（可在浏览器打开、便于分享），主文档 md 通过 file:// 链接把它们串进来，再附大事记表格。用户打开主文档即可总览全局，点击链接查看大图。

可视化定位：可视化图表通过图文结合把复杂法律关系、交易结构、时间逻辑直观化，便于法官快速理解案情、锁定核心证据。一份事实清晰、注明依据的关系图与时间图，能显著节省阅卷时间，并为当事人争取更有利的审理印象。绘图遵循「让人看懂、简化清晰、客观呈现」三项基本要求。

大事记定位：事实按顺序发生，大事记是每个叙事依赖的骨架——代理词的事实部分、法律意见、庭前准备都建立其上。AI 擅长结构化提取，但输入垃圾则输出垃圾：大事记只与来源一样好，不发明来源中没有的事件。

---

适用场景

• 用户提供案件材料，要求梳理案件事实
• 需要从材料中提取法律关系和时间线/大事记
• 案件初始阶段的案情分析
• 跨 skill 联动中需要事实基础支撑

---

核心原则

1. 客观中立

• 不预设任何一方立场
• 不对事实做倾向性评价
• 区分「已证事实」与「待证事实」
• 对争议事实标注各方主张

2. 法律关系观察准确

• 准确识别主体身份和角色
• 权利义务关系定性准确（合同/侵权/物权/人格权等）
• 关注法律关系的产生、变更、消灭
• 区分基础法律关系和派生法律关系

3. 时间线不是流水账

• 只纳入对法律后果有影响的事件
• 关注法律时效的起算和中断
• 标注关键时间节点的法律意义
• 过滤无关的日常事务性信息

4. 来源可追溯

• 每个大事记条目必须标注信息来源
• 无法追溯到提取文件的条目须内联标注：[联网检索——需复核]、[模型知识——需验证]、[用户提供]
• 不得删除或压缩来源标签

5. 材料存疑标注

• 对矛盾之处明确标注（不替当事人解决矛盾——见「本技能不做什么」）
• 对缺失环节提示补充（写入「缺口」区）
• 对模糊表述保留原文

---

工作流程

第零步：保密门禁（每次先运行）

大事记与图表均从文件中提取，文件可能包含保密或受保护信息。提取前先确认：

这些来源是否已经过保密筛选？

• A. 所有来源已清理——已筛选过，提取时不加保密标记。
• B. 混合或尚未筛选——提取并为敏感条目加标记。
• C. 中止——先筛选——暂停技能，待用户筛选来源后重新运行。

第零点五步：主体信息自动补充（文书生成前必经）

所有诉讼文书在生成最终稿之前，必须完成主体信息的核实与补充：

1. 企业主体（公司、合伙企业、非法人组织等）：

   • 调用工商信息能力槽（BIZ.company_info 或同等接口，如企查查MCP get_company_registration_info）查询最新工商登记信息
   • 补充字段：企业全称、统一社会信用代码、住所地、法定代表人/负责人
   • 禁止在诉讼文书主体信息中写入：企业类型、成立日期、注册资本、经营范围等工商登记冗余信息
   • 若能力槽不可用，但用户提供的案件材料中包含相关信息，直接从材料提取并补充
   • 若材料中亦无相关信息，主动向用户询问："请提供[企业名称]的统一社会信用代码、住所地、法定代表人信息"
   • 用户明确拒绝提供时，保留"[待用户补充]"占位符，严禁自行编造或填写虚假信息

2. 自然人主体：

   • 无MCP可用，仅依赖用户提供的材料或用户补充
   • 从案件材料中提取：姓名、性别、出生日期、身份证号码、住所地/经常居住地
   • 材料中缺失的，主动向用户询问
   • 用户拒绝提供时，保留"[待用户补充]"占位符，严禁编造

3. 适用文书类型：

   • 起诉状、答辩状、代理词中的当事人信息部分
   • 证据目录中的主体证据组
   • 程序性文书中的申请人/被申请人信息
   • 案件事实梳理中的主体识别部分

第一步：接收材料与识别来源

根据用户提供的材料和说明，判断案件场景：

场景	特征	关注重点
主诉场景	用户为原告/申请人	请求权基础、证据完整性
被诉场景	用户为被告/被申请人	抗辩事由、对方证据瑕疵
中立分析	未明确立场	双方权利义务全貌

来源识别顺序：

1. 用户提供的路径——本次会话中提供的任何文件
2. 默认案件文件夹——用户指定的案件工作目录
3. 声明的来源——配置或对话中声明的来源
4. 询问——来源看起来不足时，主动提示用户补充

材料接收清单： 起诉状/答辩状/仲裁申请书、合同及附件、往来函件/通知、转账凭证/发票、会议纪要/聊天记录、鉴定报告/审计报告、判决书/裁定书（如有前序程序）、其他相关材料。

对于无法访问的已声明来源，在输出的「缺口」区中明确命名，不得静默跳过。

第二步：客观中立抽取事实

2.1 主体识别

主体信息模板：
- 名称：（全称 + 简称）
- 类型：自然人 / 法人 / 非法人组织 / 国家机关
- 角色：原告 / 被告 / 第三人 / 其他
- 关键属性：（住所地、法定代表人、资质等与案件相关的属性）

2.2 法律关系识别

法律关系模板：
- 主体A → 主体B
- 关系类型：合同关系 / 侵权关系 / 物权关系 / 担保关系 / 劳动关系 / 其他
- 具体定性：（如：买卖合同 / 借款合同 / 产品责任 / 抵押权等）
- 权利内容：（主体A对主体B享有的权利）
- 义务内容：（主体A对主体B负有的义务）
- 关系状态：存续 / 已终止 / 争议中
- 依据：（合同条款 / 法律规定 / 事实行为）

2.3 事实层次分类

层次	定义	标注方式
确定事实	双方认可或有充分证据证明	直接陈述
争议事实	双方说法不一致	标注「原告主张：... / 被告主张：...」
待查事实	证据不足无法判断	标注「待补充：...」

第三步：事件提取、去重与重要性标记

3.1 事件提取

对每份材料，识别带日期的事件，参考句式：

• 邮件/函件： [日期] [发送人] 告知 [收件人] [主题/内容]
• 会议： [日期] [参加人] 就 [主题] 开会
• 决定： [日期] [决策人] 决定 [什么]
• 诉讼文件： [日期] [当事人] 提交 [起诉状/答辩状/上诉状]
• 外部事件： [日期] [事情发生]（合同签署、付款、产品交付、监管行动等）

纳入大事记的事件应满足以下至少一项：法律关系变动、时效影响（起算/中断/中止）、关键证据形成、程序节点、损害发生或扩大、重要意思表示的发出或到达。

3.2 去重

同一事件可能出现在多份文件中——这是一个有多个来源的事件。合并为一条，引用所有来源。

3.3 按案件理论标记重要性（侧重点框架）

同一事件因执业者是在证明主张还是反驳主张而具有不同重要性：

• 原告/主张方（进攻框架）——🔴 标记确立请求权要件的事件（责任、因果关系、损害、通知）、关闭对方将试图打开的缺口的事件，或启动诉讼时效的事件；🟡 标记支持主张但可被质疑的事件；⚪ 是背景。
• 被告/抗辩方（防御框架）——🔴 标记打破请求权要件的事件（因果关系断裂、通知缺失、依赖缺失）、开启诉讼时效或管辖权抗辩的事件，或支持积极抗辩（免责、弃权、过错相抵）的事件；🟡 标记削弱对方叙事的事件；⚪ 是背景。

纪律：300 条条目中有 300 条 🔴 等于没有标签。只为真正能移动事实认定者的事件保留 🔴。

3.4 排除标准

与案件无关的日常事务、重复性常规操作（除非某次有特殊意义）、纯粹内部讨论（除非构成意思表示）一律不纳入；无法确定时间的事件移入「缺口」区单独列出。

第四步：生成法律关系分析图（HTML）

确定法律关系是制定诉讼策略的第一步。法律关系分析图按「两要素 + 三步法」绘制，输出为单文件 HTML，可直接在浏览器打开、便于分享。

4.1 主体要素（第一步）

将所有法律主体（名称或代号）定点。主体范围不限于当事人；同一主体只出现一次；按角色归类以便配色。

4.2 关系要素（第二步）

梳理主体、主要事实与各方法律关系。关注并存的多层关系（如借贷中的借款/保证/抵押；建设工程的承包/转包/分包）；将有联系的主体用连线串联，并用简短文字解释连线含义；区分基础关系与派生关系。

4.3 连线与文字说明（第三步）

兼顾法律事实与时间顺序连接；减少交叉与曲折；图文结合（关系类型、时间、状态、金额、份额标注在连线/节点上）；复杂图可拆分。

4.4 生成 HTML

构建一个自包含单文件 HTML（法律关系分析图_{案件名}.html），结构如下：

• 顶部：案件名称标题 + 一行说明（构建日期、视角/场景）
• 主体配色图例：原告蓝 #dae8fc / 被告红 #f8cecc / 法院绿 #d5e8d4 / 第三方紫 #e1d5e7
• 关系图主体：用内嵌 Mermaid 渲染 graph LR（左右结构，与套件一致），节点用 subgraph 按角色分组、连线 label 写关系文字、争议/待证关系用虚线 -.->、已终止关系标灰
• 底部：争议关系与关键金额/份额的文字注解

HTML 模板骨架（占位符替换为实际内容）：

<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<title>{案件名称} 法律关系分析图</title>
<style>
  body{font-family:"Microsoft YaHei",sans-serif;margin:24px;color:#222;}
  h1{font-size:20px;border-bottom:2px solid #6c8ebf;padding-bottom:8px;}
  .meta{color:#666;font-size:13px;margin:8px 0 16px;}
  .legend span{display:inline-block;padding:2px 10px;margin-right:8px;border-radius:3px;font-size:13px;}
  .l-p{background:#dae8fc;} .l-d{background:#f8cecc;} .l-c{background:#d5e8d4;} .l-t{background:#e1d5e7;}
  .diagram{border:1px solid #ddd;border-radius:6px;padding:16px;margin-top:12px;}
  .notes{margin-top:16px;font-size:14px;line-height:1.7;}
</style>
</head>
<body>
  <h1>{案件名称} · 法律关系分析图</h1>
  <div class="meta">构建日期：{YYYY-MM-DD}　|　场景：{主诉/被诉/中立分析}</div>
  <div class="legend">
    <span class="l-p">原告方</span><span class="l-d">被告方</span>
    <span class="l-c">法院</span><span class="l-t">第三方</span>
    <span>实线=确定关系　虚线=争议/待证　灰色=已终止</span>
  </div>
  <div class="diagram">
    <pre class="mermaid">
graph LR
    subgraph 原告方
        P["甲（原告）"]
    end
    subgraph 被告方
        D1["乙（被告一）"]
    end
    P -->|"280万元债权"| D1
    D1 -.->|"代持（争议）"| T["××公司（第三人）"]
    classDef plaintiff fill:#dae8fc,stroke:#6c8ebf;
    classDef defendant fill:#f8cecc,stroke:#b85450;
    classDef third fill:#e1d5e7,stroke:#9673a6;
    class P plaintiff; class D1 defendant; class T third;
    </pre>
  </div>
  <div class="notes">
    <strong>关系注解：</strong>{争议关系说明、关键金额/份额、关系状态}
  </div>
<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
<script>mermaid.initialize({startOnLoad:true});</script>
</body>
</html>

离线降级：若交付环境无网络（Mermaid CDN 不可达），改用内嵌 SVG 手绘节点与连线，或调用「诉讼可视化」技能输出独立 .html 图表文件。

第五步：生成法律事实时间图（HTML）

时间要素是案件核心要素——事件时间点或先后顺序常与争议焦点直接相关（违约金起算、占用费时段、合同解除节点、诉讼时效判定）。法律事实时间图按「轴线要素 + 事件要素」绘制，输出为纯 HTML/CSS 单文件（无外部依赖，最稳健）。

5.1 轴线要素

一条竖轴代表案件时间轴，各时间点按先后排列；时间点精确到具体年月日，不省略。

5.2 事件要素

每个时间点对应一个事件卡片，简洁概述「该时间点发生了什么」；卡片格式统一；关键事实（🔴）用醒目强调色区分，使受众一眼锁定要害。

5.3 生成 HTML

构建自包含 HTML（法律事实时间图_{案件名}.html），用纯 CSS 竖向时间轴呈现，关键节点高亮。模板骨架：

<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<title>{案件名称} 法律事实时间图</title>
<style>
  body{font-family:"Microsoft YaHei",sans-serif;margin:24px;color:#222;}
  h1{font-size:20px;border-bottom:2px solid #6c8ebf;padding-bottom:8px;}
  .meta{color:#666;font-size:13px;margin:8px 0 20px;}
  .tl{position:relative;margin-left:120px;border-left:3px solid #6c8ebf;padding-left:24px;}
  .ev{position:relative;margin-bottom:22px;}
  .ev .date{position:absolute;left:-150px;width:110px;text-align:right;font-size:13px;color:#555;}
  .ev .dot{position:absolute;left:-33px;top:3px;width:13px;height:13px;border-radius:50%;background:#6c8ebf;border:2px solid #fff;}
  .ev.key .dot{background:#d6334a;width:16px;height:16px;left:-35px;}
  .ev .card{background:#f7f9fc;border:1px solid #dde;border-radius:6px;padding:10px 14px;font-size:14px;}
  .ev.key .card{background:#fdecef;border-color:#d6334a;font-weight:600;}
  .ev .who{color:#888;font-size:12px;margin-top:4px;}
</style>
</head>
<body>
  <h1>{案件名称} · 法律事实时间图</h1>
  <div class="meta">构建日期：{YYYY-MM-DD}　|　红色节点为关键事实（🔴）</div>
  <div class="tl">
    <!-- 普通事件 -->
    <div class="ev">
      <div class="date">2023-03-10</div><div class="dot"></div>
      <div class="card">李四交付第一批设备<div class="who">行为方：李四</div></div>
    </div>
    <!-- 关键事件 -->
    <div class="ev key">
      <div class="date">2023-05-15</div><div class="dot"></div>
      <div class="card">张三发送解除合同通知<div class="who">行为方：张三</div></div>
    </div>
  </div>
</body>
</html>

时间图与大事记数据同源：图侧重「直观脉络与关键节点高亮」，大事记侧重「来源标注、重要性评级与缺口提示」。

🔗 台账自动回写（强制）：在产出交付物之前，调用「案件管家」§0.7 自动同步接口：搜索台账 recordId → 追加案件进展"{日期}事实梳理完成（关键事实：{1句}）" → 更新下一步动作 → 写入。搜索无结果跳过回写并标注；回写失败不阻塞输出但标注"⚠️ 台账未自动更新"。

第六步：组装案件事实梳理主文档（Markdown）

将前两步生成的两张 HTML 图与筛选去重后的大事记，组装为一份主文档 case-facts_{案件名}.md。这是交付给用户的核心文件，依次包含三个部分：

1. 法律关系分析图——用 file:// 链接引用第四步生成的 法律关系分析图_{案件名}.html，并在链接下方写一段配套文字说明：本案主体构成、核心法律关系定性、争议关系与关键金额/份额。文字说明须客观，不作法律适用结论。
2. 法律事实时间轴图——用 file:// 链接引用第五步生成的 法律事实时间图_{案件名}.html。
3. 大事记——筛选去重后的时间线表（含来源标注）+ 关键事件（🔴）+ 缺口 + 时效争议提示 + 版本号。

链接写法：使用图 HTML 文件的绝对路径，如 [查看法律关系分析图](file:///绝对路径/法律关系分析图_{案件名}.html)。

若已有先行版本：版本号递增，向用户呈现 diff 摘要。

最终确定前确认：

这是我构建的内容。请浏览 🔴 条目——有无我判定错误的地方？

---

主文档格式（Markdown）

主文档把两张 HTML 图的链接与大事记串为一体，按大事记的工作结构：

# case-facts —— {案件名称}

**案件：** {案件标识/slug}
**构建日期：** {YYYY-MM-DD}
**视角：** {主诉/进攻框架 ｜ 被诉/防御框架 ｜ 中立}
**来源：** {N} 份材料
**条目：** {N}（{N} 🔴 / {N} 🟡 / {N} ⚪）
**关键事实：** {一句话概括}

---

## 一、法律关系分析图

📎 [查看法律关系分析图（HTML）](file:///绝对路径/法律关系分析图_{案件名}.html)

**图示说明：** 本案共涉 {N} 个主体——{原告X、被告Y、第三人Z…}。核心法律关系为 {如：X 与 Y 之间的设备买卖合同关系，标的额 200 万元}；派生关系为 {如：Z 为该债务提供连带保证}。争议关系为 {如：Y 主张代持关系，X 否认}。{关系状态简述：存续/已终止/争议中}。

---

## 二、法律事实时间轴图

📎 [查看法律事实时间轴图（HTML）](file:///绝对路径/法律事实时间图_{案件名}.html)

> 红色节点为关键事实（🔴），详见下方大事记。

---

## 三、大事记

### 时间线

| 日期 | 事件 | 行为方 | 标签 | 来源 |
|------|------|--------|------|------|
| 2023-01-15 | 双方签订《设备采购合同》，约定总价款200万元 | 张三/李四 | 🔴 | 合同原件 |
| 2023-02-01 | 张三支付首期款80万元 | 张三 | 🔴 | 转账凭证-1 |
| 2023-03-10 | 李四交付第一批设备 | 李四 | 🟡 | 签收单-1 |
| 2023-03-15 | 张三书面通知李四设备存在质量问题 | 张三 | 🔴 | 函件-1 |
| 2023-04-10 | 李四未履行15日内更换承诺 | 李四 | 🔴 | [模型知识——需验证] |
| 2023-05-15 | 张三发送解除合同通知 | 张三 | 🔴 | 函件-3; EMS签收单 |

### 关键事件（仅 🔴）

逐条提取 🔴 事件，每条附一行说明其为何对案件理论重要：

- **2023-03-15 质量问题书面通知** —— 触发违约救济权、构成解除合同的事实前提。
- **2023-05-15 解除合同通知** —— 合同解除生效节点，影响违约金/损失起算。

### 缺口

- **无事件的日期范围：** {如 2023-04-10 至 2023-05-15 无往来记录}
- **预期但缺失：** {预期看到但未记录的事件，如对方收货确认}
- **不可读/不可达来源：** {已声明但本次无法访问的来源}
- **时间待核实事项：** {无法确定时间的事件}

### 时效与争议提示（按需）

- **诉讼时效起算日：** {YYYY-MM-DD}（基于…事件）；是否存在中断/中止：…
- **争议时间点：** 关于 XX 事件发生时间——原告主张…，被告主张…

---

## 版本

- v{N} 构建于 {YYYY-MM-DD}，来源：{来源摘要}；较 v{N-1} 变更：{diff 摘要}

字段格式：日期 YYYY-MM-DD（精确到已知精度，不确定用「约」）；事件为一句话客观描述（≤50字，不加评价）；行为方用主体简称（多方用「/」）；来源用证据编号或材料名（多来源用「;」），非文件来源用标准标签。两张图的链接须为可点击的 file:// 绝对路径。

---

输出产物

本 skill 完成后产出一份主文档 + 两张配图，主文档通过链接把两张图串起来：

主文档：案件事实梳理（Markdown）

• 格式：Markdown 文档（大事记结构），交付的核心文件
• 结构：元数据头 +「一、法律关系分析图」（HTML 链接 + 文字说明）+「二、法律事实时间轴图」（HTML 链接）+「三、大事记」（时间线表 + 关键事件 🔴 + 缺口 + 时效争议提示 + 版本号）
• 输出：写入 .md 文件，以 file:// 链接交付；可版本递增
• 要点：两张图的链接为可点击的 file:// 绝对路径；关系图配套文字说明客观、不作法律结论

配图一：法律关系分析图（HTML）

• 格式：单文件 HTML（内嵌 Mermaid graph LR + 角色配色图例）
• 方法：两要素（主体 + 关系）三步法
• 输出：写入 .html 文件，由主文档第一部分链接引用；离线降级为内嵌 SVG 或调用「诉讼可视化」出独立 .html
• 内容：主体不重复、连线少交叉、图文结合、争议关系虚线

配图二：法律事实时间轴图（HTML）

• 格式：单文件 HTML（纯 HTML/CSS 竖向时间轴，无外部依赖）
• 方法：轴线要素（精确到年月日）+ 事件要素（关键节点高亮）
• 输出：写入 .html 文件，由主文档第二部分链接引用
• 内容：按时间串联的关键事实脉络，🔴 节点强调色高亮

---

执行流程图

用户提供案件材料
       │
       ▼
┌─────────────────────────┐
│ 第零步：保密门禁          │
│ 确认来源是否已脱敏        │
└───────────┬─────────────┘
            ▼
┌─────────────────────────┐
│ 第一步：接收材料+识别来源 │
│ 判断场景 → 来源识别顺序   │
└───────────┬─────────────┘
            ▼
┌─────────────────────────┐
│ 第二步：抽取事实          │
│ 主体 → 法律关系 → 层次分类│
└───────────┬─────────────┘
            ▼
┌─────────────────────────┐
│ 第三步：提取+去重+重要性  │
│ 事件提取→去重→侧重点框架  │
└───────────┬─────────────┘
            ├──────────────┬──────────────────┐
            ▼              ▼                  ▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐
│第四步:关系图(HTML)│ │第五步:时间图  │ │事件去重+重要性    │
│两要素三步法+Mermaid│ │(HTML)CSS时间轴│ │（已在第三步完成） │
└─────────┬────────┘ └──────┬───────┘ └────────┬─────────┘
          └────────┬────────┴────────┬──────────┘
                   ▼                  ▼
┌─────────────────────────────────────────────────────┐
│ 第六步：组装主文档（md）                              │
│ 一、关系图链接+文字说明 / 二、时间图链接 / 三、大事记 │
└───────────────────────┬─────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────┐
│ 输出：case-facts.md（主文档，链接两张图）           │
│      + 法律关系分析图.html + 法律事实时间图.html      │
│ 最终确认：请用户复核 🔴 条目                          │
└─────────────────────────────────────────────────────┘

---

跨 Skill 联动

调用的 Skill（按需）

被调用 Skill	调用时机	传递信息
诉讼可视化	用户需要更精细的交互式图表，或需独立图表文件时	主体列表 + 关系列表，输出独立 .html

默认情况下，本技能直接生成 HTML 图表，不强制依赖「诉讼可视化」；仅在用户需要更复杂的交互式可视化或独立图表文件时调用。

被调用接口

调用方式：调用「案件事实梳理」技能
输入参数：
  - materials: 案件材料内容或文件路径列表
  - scenario: 主诉 / 被诉 / 中立分析
  - focus: 重点关注的法律关系类型（可选）
  - output: 全部（主文档+两图） / 仅关系图 / 仅时间图 / 仅大事记表

---

常见案件类型的梳理要点

合同纠纷

• 重点：合同成立→生效→履行→违约→解除 的完整链条
• 时间线关注：履行期限、通知到达日、宽限期
• 法律关系重点：主合同关系、从合同关系（担保等）

侵权纠纷

• 重点：侵权行为→损害结果→因果关系→过错
• 时间线关注：侵权行为发生日、损害发现日、持续侵权期间
• 法律关系重点：加害行为主体、共同侵权、补充责任

公司纠纷

• 重点：股东关系、决议效力、高管义务
• 时间线关注：决议日期、工商变更日期、知情日期
• 法律关系重点：股权结构、实际控制关系、关联交易

劳动纠纷

• 重点：入职→履行→变更→解除/终止 的完整链条
• 时间线关注：入职日、合同期限、解除通知日、仲裁时效
• 法律关系重点：劳动关系确认、劳务派遣关系

---

质量检查清单

法律关系分析图（HTML）检查

• 单文件 HTML 可独立在浏览器打开
• 所有涉案主体均已纳入、同一主体未重复出现
• 法律关系定性准确（含并存的多层关系）
• 连线均有文字说明（关系类型/金额/状态）
• 角色配色与图例正确、争议关系虚线、已终止关系标灰
• 连线交叉已尽量减少（节点≤15，过多则拆分）

法律事实时间图（HTML）检查

• 单文件 HTML 纯 CSS 渲染、无外部依赖即可显示
• 时间点精确到年月日、按先后排列
• 事件卡片格式统一、文字简洁
• 关键事实（🔴）已高亮、与大事记数据一致

主文档（md）检查

• 元数据头完整（案件/日期/视角/来源/条目统计/关键事实）
• 「一、法律关系分析图」含可点击 file:// 链接 + 一段客观文字说明（主体/核心关系/争议关系）
• 「二、法律事实时间轴图」含可点击 file:// 链接
• 「三、大事记」事件按时间正序排列、无遗漏关键节点
• 每条均有来源标注，非文件来源用标准标签
• 重要性评级遵循侧重点框架、🔴 未滥用
• 「关键事件」逐条说明对理论的意义
• 「缺口」区已列出（日期空档/预期缺失/不可达来源/待核实时间）
• 版本号已标注；如有先行版本，已呈现 diff
• 无主观评价性语言、争议时间点已标注各方主张

整体检查

• 主文档中两条图链接路径正确、点击可打开对应 HTML
• 三份文件信息一致（关系图主体 ↔ 时间图行为方 ↔ 大事记行为方相互对应）
• 文字说明与图、大事记内容相互印证、无冲突
• 已完成保密门禁
• 未预设任何一方立场
• 已请用户复核 🔴 条目

---

本技能不做什么

• 不解决矛盾：当两份文件就同一事件说法不同时，两个条目都放入并标记，由律师判断取舍。
• 不发明来源中没有的事件：不在文件中的，就不在产物中（联网/模型推断须打标签）。
• 不保证完整性：产物仅与来源一样好，缺口必须如实写入「缺口」区。
• 不替代法律判断：仅提供客观事实整理与可视化，不作法律适用结论。

---

注意事项

1. 材料引用准确：所有事实必须有材料依据，不得推测；推断须打来源标签。
2. 动态更新：用户补充材料后更新主文档与两张图，主文档大事记版本号递增。
3. 保密意识：每次先过保密门禁；提醒用户注意材料中的敏感信息。
4. 篇幅适度：大事记时间线建议控制在 30 行以内，过长应分段或附索引。

---

案件管家联动（强制）

本 skill 完成产出后，必须在输出文档之前调用「案件管家」的台账回写协议，六步流程 / 降级 / 不阻塞规则统一由套件 Hub 维护：

协议单一权威源：skills/case-manager/references/downstream-writeback-protocol.md 入口条款：/case-manager SKILL.md §0.7

本 skill 的产出：事实梳理表 md + 关系图 HTML + 时间轴 HTML

差异化字段回写：阶段进度 → 事实梳理完成；下一步动作 → 制定策略