---
name: legal-reasoning
license: Apache-2.0 (adapted from anthropics/claude-for-legal, legal-clinic/skills/memo; complete terms in LICENSE.txt)
description:
  用 IRAC（争点-规则-适用-结论）框架把事实和法律结合起来构建论证，并显式标注哪些
  规则已核实、哪些是未核实的框架性认知。Use when 用户要求"帮我分析一下这个案子"
  "这属于什么法律关系""这个诉求站不站得住""帮我理一下论证逻辑""写一份法律分析
  备忘录"等需要结构化论证而非简单问答的场景。产出是论证脚手架，不是最终法律意见。
metadata:
  origin: IRAC 脚手架结构、"规则=未核实的研究缺口而非结论"原则、引用来源标注体系、
    "检索不足不能悄悄补"原则，改编自 anthropics/claude-for-legal 的
    legal-clinic/skills/memo/SKILL.md（Apache-2.0）；已移除该项目诊所式教学场景
    （督导批改风格、教授交接、学生training posture 等），改为面向单用户的通用论证工具
---

# Skill: legal-reasoning

法律推理的价值不在于说出一个听起来对的结论，而在于让"事实 → 规则 → 适用 → 结论"
这条链路每一环都经得起检验。这个技能提供 IRAC 脚手架，并且强制区分"已核实的规
则"和"未核实的知识"，避免看起来自信、实际没有依据的分析。

## 核心原则

**规则是研究缺口，不是默认结论。** 除非你已经从权威来源（国家法律法规数据库、
裁判文书网、用户提供的法条/合同/材料）确认了具体规则，否则不要把模型训练知识里
"大概是这样"的规则当成确定依据写进 Rule 部分。可以给出框架性认知，但必须显式标
注为"未核实"。

**不悄悄补检索缺口。** 如果检索/技能返回的结果对某条规则覆盖不足，明确说出来，
给用户选项（换关键词重搜 / 换信息源 / 用网络检索但标注待核实 / 直接标记待核实并
停在这里），不要为了让分析看起来完整就用模型记忆填坑。一个诚实的"这里还没查清
楚"比一个自信的错误规则更有价值。

## 引用来源标注体系

论证里出现的每一条法条/判例引用都标注来源，方便使用者判断可信度：

| 标签 | 含义 |
|---|---|
| `[官方检索]` | 来自国家法律法规数据库、裁判文书网等官方源，或用户配置的法律检索技能/工具 |
| `[网络检索-待核实]` | 来自 web_search/web_fetch，未必是权威源，需要核实 |
| `[模型记忆-待核实]` | 从训练知识里回忆出来的规则/条文，未经检索确认，虚构风险最高 |
| `[用户提供]` | 用户直接给出的材料（合同文本、案情陈述、已有法律意见） |

`待核实`标签不能省略或合并——它是使用者判断"这条该先去核实"的最快信号。

**遇到用户或材料引用的具体法条，如果你不确定是否准确：** 不要凭印象描述该条款
"大概是什么意思"。要么去检索确认原文并引用，要么直接说"这条我没有把握准确复述
内容，建议核对原文"。凭印象编出一个听起来合理但错误的条文内容，比说"不确定"更
糟糕——前者会被当真，后者不会。

## 工作流程

### 第一步：把争点表述成问题

从事实材料里提炼出真正需要回答的法律问题，用问句表述，而不是一个名词短语。
不写"违约责任"，写"合同约定的交付延迟是否构成根本违约，能否据此解除合同并
主张违约金"。多个争点各自独立成一个 IRAC 块。

### 第二步：搭建每个争点的 IRAC

**争点（Issue）：** 第一步得到的问句。

**规则（Rule）：** 这是研究缺口，不是结论。按上面的核心原则，明确写出：

> `[待核实：需要确认xx地区/xx法律关系下的具体规则——从xx法律的xx章节入手，
> 再看是否有对应司法解释或指导性案例。]`

如果你对通用法律框架有较高把握（例如"违约方需承担继续履行、采取补救措施或
赔偿损失等违约责任"是常见的一般性认知），可以先给出框架作为起点，但必须显式
标注未核实：

> *框架性认知（未核实，需按具体适用法律确认）：* [一般性规则] `[待核实：
> 具体构成要件和法律后果]`

**适用（Application）：** 把关键事实逐条对应到规则的构成要件上，列出哪些事实
支持、哪些事实不利、哪些事实还不清楚。这一步不能跳过论证直接给结论——如果某个
要件的事实不足以判断，明确写"事实不足，需要补充：xxx"。

**结论（Conclusion）：** 基于前面的规则和适用得出，而不是先有结论再倒推论证。
如果规则部分还有未核实的关键项，结论要相应降低确定性并说明前提。

### 第三步：梳理优势、劣势、未决问题

在所有 IRAC 块之后，单独列出：

- **有利事实：** 对论证有利的事实点及原因
- **不利事实：** 对论证不利的事实点及原因（不确定是否真的不利时标 `[待判断]`）
- **未决问题：**
  - 事实类：还需要向用户/当事人确认什么
  - 法律类：还需要检索什么（这部分直接对应"待核实"标签，可以逐条去检索核实）
  - 策略类：需要用户自己权衡取舍的判断题，不代替用户做决定

## 输出格式

```markdown
# 法律分析备忘录：[事项名称]

## 结论先行
[基于现有信息的初步判断，以及这个判断依赖哪些还未核实的前提]

## 争点
1. [争点1，问句形式]
2. [争点2，问句形式]

## 争点 1：[争点]

### 规则
[已核实规则 + 来源标签，或待核实框架]

### 适用
[事实逐条对应]

### 结论
[基于以上的判断，附带确定性说明]

---

## 优势
[列表，附标注]

## 劣势
[列表，附标注]

## 未决问题
**事实：** [列表]
**法律：** [列表——这些是下一步该去检索核实的]
**策略：** [列表——需要用户自己判断]

---

**引用核验提醒：** 以上标注 `[网络检索-待核实]` `[模型记忆-待核实]` 的规则/条文，
在用于任何正式场合（合同修改、函件、诉讼材料）之前，请通过国家法律法规数据库、
裁判文书网或专业法律数据库核实准确性和现行有效性。

**本备忘录是论证脚手架，不是最终法律意见。** 结论部分给出的是基于现有信息的
推演，重大决策（是否起诉、是否签署、赔偿金额谈判底线）请交由持证律师复核。
```

## 边界

- 不代替用户做策略性判断（打不打这场官司、接不接受和解条件）——"策略"类未决
  问题就是把这类判断题清楚地摆出来，决定权在用户。
- 不在"规则"部分伪造确定性——宁可多标一个"待核实"，也不要漏标一个。
- 批量处理多份文档、多个类似案例找规律：这是 `legal-due-diligence` 的场景，
  本技能聚焦单一争议/单一事项的论证构建。