case-intake-issue-map

name	case_intake_issue_map
description	将用户叙述转化为事实清单、程序信息、诉求目标和初步争议焦点矩阵。

Skill：案件摄入与争议焦点识别

事项记忆要求

• 本技能是分析镜头。默认把结果写入会话回复、matter.md 或目标交付文件。
• 只有长期协作、审计追踪或用户明确要求时，才更新 skill_outputs.md。
• 如果本技能没有实际执行，不能在报告中暗示已完成；如果信息不足，输出缺口、影响和下一步。

适用场景

用户刚开始讲述纠纷，材料零散，尚未形成清晰争议焦点时使用。

目标

1. 把叙述转化为结构化案件概要。
2. 区分事实、推测、评价和法律结论。
3. 初步识别请求、抗辩、争议焦点和证据缺口。
4. 对复杂纠纷按 docs/LEGAL_REASONING.md 形成母命题、条件命题和反制命题雏形。
5. 对案件工作台事项按 docs/CASE_WORKBENCH.md 生成或更新 case_dashboard.md 和 consultation_note.md。
6. 为后续证据台账、要件矩阵和策略分析提供基础。

输入

• 用户事实描述。
• 对方说法或行为。
• 用户目标。
• 已有证据。
• 程序阶段。

工作流

1. 拆分叙述

把用户内容分成四类：

类型	判断标准	示例表达
事实	可被证据证明或反驳	某日签约、某日付款、某日收到通知
推测	用户根据事实作出的猜想	对方可能故意拖延
评价	情绪或价值判断	对方很不诚信
法律结论	需要法律判断	对方构成违约、侵权、欺诈

2. 建立案件概要

提取：

• 当事人角色。
• 合同/关系基础。
• 关键时间节点。
• 核心行为。
• 损害或后果。
• 用户请求。
• 对方回应。
• 已有证据。
• 目前程序位置。

3. 识别争议焦点

按照五类争议焦点生成清单，并进一步判断哪些争议焦点属于母命题、条件命题或反制命题：

1. 事实争议焦点。
2. 法律争议焦点。
3. 证据争议焦点。
4. 因果争议焦点。
5. 程序争议焦点。

复杂纠纷不得只列平铺争议焦点；必须写出“哪个争议焦点决定全案方向，哪些争议焦点依赖该争议焦点，哪些争议焦点专门回应对方主张”。

4. 形成初步案件地图

将争议压缩为：

谁基于什么法律关系，因什么行为，主张什么权利，要求什么结果；
对方可能如何否认、抗辩或反诉；
核心证据和缺口在哪里。

输出格式

## 案件一句话地图

## 事实/推测/评价/法律结论区分
| 内容 | 类型 | 证据状态 | 备注 |
|---|---|---|---|

## 初步争议焦点矩阵
| 编号 | 争议焦点 | 层级 | 类型 | 对用户的重要性 | 现有证据 | 缺口 |
|---|---|---|---|---|---|---|

## 争议焦点依赖关系
| 前置争议焦点 | 后续影响 | 对方替代解释 | 需要优先补强的事实 |
|---|---|---|---|

## 用户请求与可选路径
| 请求 | 现实目标 | 法律路径 | 所需证明 | 风险 |
|---|---|---|---|---|

## 下一步需要补充的信息
1. 
2. 

案件工作台事项还必须同步输出：

• case_dashboard.md：一页式案件地图、关键判断变量、争议焦点关系图、证明责任、证据缺口、对方打法、来源状态和当前可信度。
• consultation_note.md：面向用户的当前判断、不能判断的事项、主要风险、补证材料、表达风险和下一次协作清单。

case_dashboard.md 不写“下一步五个动作”或输出分流；这些内容写入会话回复、matter.md 或后续 case_package.md。

质量检查

• 不把情绪评价当事实。
• 不把法律结论当已证明事实。
• 每个争议焦点都能连接到至少一个事实或证据缺口。
• 复杂纠纷必须识别母命题、条件命题和反制命题。
• 案件工作台事项必须让 case_dashboard.md 能独立回答“现在这个案件应当如何理解”。
• 输出应为后续技能可直接使用的结构化输入。