/legal-skill-alignment

name: legal-skill-alignment
homepage: https://github.com/cat-xierluo/legal-skills
author: 杨卫薪律师（微信ywxlaw）
version: "1.0.7"
license: CC-BY-NC
description: 写法律 Skill 前的前置对齐步骤——通过苏格拉底式提问把零散的法律经验/素材/直觉厘清为结构化 Brief（legal-skill-brief/v1），交给 skill-creator 编译。适用于律师想把文书经验、办案 SOP、咨询记录做成 Skill 的场景。不适用于非法律类 Skill 创建，也不适用于用户已提供完整可执行 Brief 且明确要求直接编译的情况。

法律 Skill 目标对齐

定位

**本 Skill 是写法律 Skill 前的前置步骤**——通过苏格拉底式提问，帮助你把零散的"经验/素材/直觉"转化为一份结构化、可被通用 `skill-creator` 等下游编译器消费的 **Legal Skill Brief v1**（详见 [standard-prompt-output.md](references/standard-prompt-output.md)）。本 Skill **不直接生成 Skill 文件**，只产出喂给下游编译器的 Brief。

**分工**：

• `legal-skill-alignment`（本 Skill）：负责"想清楚要做什么"——把意图结构化。
• 通用 `skill-creator`（或你环境中可用的法律领域 Skill 编排器）：负责"做出来"——把 Brief 编译为 SKILL.md / references / scripts。

---

方法论：question-set/v1（当前默认五问）

本 Skill 当前落地采用 **question-set/v1**（五问实例）——从五个关键维度对齐目标：

| # | 要素 | 解决的问题 | 在 Brief v1 中对应的字段 | |---|------|-----------|--------------------------| | 1 | **输入什么** | 这个 Skill 吃什么数据 | `## 二、1. 输入什么（Inputs）` | | 2 | **输出什么** | 产出长什么样 | `## 二、2. 输出什么（Outputs）` | | 3 | **处理逻辑** | 从输入到输出怎么走 | `## 二、3. 处理逻辑（Workflow）` | | 4 | **向谁交付**（v1 拆三子项） | 谁用、谁代表、写给谁看 | `## 二、4. 向谁交付（Context.Delivery）` | | 5 | **需要哪些知识支撑** | 法律依据、范本、风险清单、风格偏好 | `## 二、5. 需要哪些知识支撑（Knowledge Base）` |

第 4、5 问是相对"经典三问"补全的两问——**向谁交付**决定语气与详略，**需要哪些知识支撑**决定这个 Skill 是"空壳模板"还是"有肉的真本事"。

为什么叫 question-set/v1 而不是"五问法"

• **不锁数字**：v1 是当前默认实例（5 问），未来 v2 可扩展为 6 问 / 7 问 / 缩减为 4 问，Skill 名不变。
• **版本化约束**：v1 锁定的不是问数，而是**完整性规则**（见下文）和**字段语义**（如下文"第 4 问拆三子项"）。
• **扩展方式**：修改本 SKILL.md 的问数 + 对应 references，发布新版本（如 `question-set/v2`）。

v1 第 4 问的三子项

第 4 问在 v1 中拆为三类角色，三者**经常被混淆**，必须分别明确：

| 子项 | 含义 | 典型值 | 决定什么 | |------|------|--------|---------| | `operator` | 直接使用本 Skill 的角色 | 律师 / 律师助理 / 法务 / 合规专员 / AI 操作员 | 能调用什么工具 / 看到哪些字段 | | `represented_party` | Skill 产出物实质服务的当事人 | 原告 / 被告 / 雇主 / 收购方 | 内容立场 / 利益偏好 / 保密等级 | | `output_audience` | 最终文书的读者 | 法官 / 对方律师 / 客户 / 监管机关 | 语气基调 / 详略取舍 / 术语密度 |

**最常见错误**：把 `output_audience` 写成 `represented_party`（如把"法官"误填到 `represented_party`）。法官是读者，不是被代表的当事人。

---

完整性规则（question-set/v1 必读）

产出 Brief 前必须满足以下规则。完整性是**对齐内部约束**，不阻塞下游消费者接收（下游不做 schema 校验），但**阻塞 alignment 自身判定为"可交接"**。

非目标（Non-goals）

本 Skill **不做**：

• **不替代法律判断**：厘清出的处理逻辑和风险清单需由执业律师最终确认。
• **不产出最终文书**：只产出 Brief，下游编译才是 Skill 文件。
• **不做合规审查**：Brief 的内容不构成法律意见或合规承诺。
• **不验证法源时效**：法源生效日期由用户在 `effective_date` 与 `verification_status` 中标注，未确认的标 `unverified`。

禁止事项（Prohibited）

• **禁止编造法条 / 案例**：每条法源引用必须可溯源；无法提供原文 URL 或本地原文路径的，标 `verification_status: unverified`。
• **禁止把个案事实硬编码为通用规则**：单样本反推出的规则必须标"待补"，不直接当通用结论。
• **禁止替用户做价值判断**：当事人立场 / 策略选择 / 风险偏好，由用户确认而非 alignment 推断。
• **禁止默默推断缺口**：每个推断要素必须在"待确认清单"中标注推断依据和确认方式。

成功标准与状态判定（Success Criteria，v1.0.2 起拆分两状态）

一份 Brief 的可交接性用**两个独立状态**判定，避免"字段齐全但含 blocker 却标可交接"的歧义：

`structurally_complete`（结构完整）

Brief 满足以下全部条件即判定为 `structurally_complete = true`：

• 五问每问都有答案（明确答案 / 推断答案 / 标"待补"，三者之一）
• 法源条目带 `effective_date` 与 `verification_status`（即便值是 `unverified`）
• 素材溯源 quality 字段已填写（`unrated` 也算）
• 安全与脱敏说明段已填（即便无敏感信息也填"无敏感信息识别"）
• 待确认清单已按 `blocker` / `warning` 分类

> `structurally_complete` 只看"字段是否齐全 + 是否标注"，**不看 blocker 是否清零**。含"待补"标记的 Brief 仍可满足此状态。

`handoff_ready`（可交接）

在 `structurally_complete = true` 基础上，**且待确认清单中 blocker 项 = 0**，才判定为 `handoff_ready = true`。

存在以下任一情况，`handoff_ready = false`（即使 `structurally_complete = true`）：

• `operator` 未确认（仅 warning 级别标"待补"**不**算未确认；但完全空白或无任何推断依据算 blocker）
• 五问中任何一问完全空白且未标"待补"（同时导致 `structurally_complete = false`）
• Brief 产出涉及具体法律建议，但没有任何可追溯的关键法源原文（`source_url` 或 `source_file`）

**关键法源缺失的唯一判定**：只要 Brief 会产出具体法律建议（包括法律意见、诉讼/应诉策略、起诉状或答辩状、合同定稿或审查结论、需据法源作出的合规整改建议），且相应关键法源没有原文 URL 或本地原文路径，就必须登记一项 `blocker`，并判定 `handoff_ready = false`。是否已知或可推定法域不改变该结论。纯流程整理、素材归档或不包含具体法律建议的工具型 Brief，法源原文缺失可登记为 `warning`。

状态转换规则（v1.0.2 核心修复，解决 T-014 歧义）

| 当前状态 | 待确认清单 blocker 数 | 操作 | |---------|---------------------|------| | `structurally_complete = false` | — | 回到对应步骤补全字段，**不**交付 | | `structurally_complete = true`，`handoff_ready = false` | ≥ 1 | 交付时**必须**在 Brief 顶部与待确认清单显式标注"含 blocker，不建议下游直接编译"；由用户决定是否强行交接 | | `structurally_complete = true`，`handoff_ready = true` | 0 | 可正常交付；warning 项允许保留 |

**判定唯一性**：任何 Agent 读同一份 Brief，只要按上述规则，对 `structurally_complete` / `handoff_ready` 的判定结果必须一致。如果出现"一个 Agent 判可交接、另一个判不可"的分歧，以 `handoff_ready = (blocker 数 = 0)` 为准。

失败条件（Failure Conditions）

出现以下情况，Brief 应**判定为 `structurally_complete = false` 而非交付**：

• 五问中任何一问完全空白且未标"待补"
• 涉及最终法律结论但未声明"需执业律师复核"
• 素材中含明显敏感信息（身份证 / 手机号 / 当事人真实姓名）但未声明脱敏状态

> 关键法源缺失不改变 `structurally_complete` 的字段完整性判断；只要缺口已如实列为 `blocker`，则应判定为 `structurally_complete = true`、`handoff_ready = false`，不得把它同时写成结构不完整和可带 warning 交接。

人工复核点（Human Review）

以下产出**必须**由执业律师复核（与 T-010 安全边界联动）：

• 最终法律意见书 / 起诉状 / 答辩状 / 合同定稿
• 起诉应诉策略建议
• 合规整改建议（涉及监管报送的）
• 高额标的（合同金额 / 索赔金额 > 一定阈值，建议用户团队阈值表）的合同审查结论

---

工作流程

步骤 0：判定路径（最先做）+ 安全预检

读用户第一条消息，判断走哪条路径：

| 用户说话特征 | 路径 | |------------|------| | 提到"这是我的样本/SOP/Q&A/历史文书/案例"，或粘贴/上传了素材 | **有素材路径** | | 说"我想做个 XX skill 但不知道怎么开始""我脑子里有经验但没整理过""教我做" | **无素材路径** | | 同时满足 | 先走有素材路径，再用访谈补缺口 |

**安全预检**（无论哪条路径都要做）：

1. **敏感材料识别**：检查用户上传或粘贴的内容是否含明显敏感信息（见 [alignment-strategies.md](references/alignment-strategies.md) 顶部的"敏感材料识别清单"）。 2. **脱敏提示**：如有敏感信息，提示用户："检测到 [敏感信息类型]，请确认是否已脱敏 / 是否需要本 Skill 协助脱敏（仅提示，不自动改写原文件）"。 3. **外传确认**：默认**不**上传 / 共享给任何外部服务。如需外部检索或服务，**必须**显式询问用户确认。

不要在没素材的情况下硬走有素材路径——会产出空洞的 Brief。

步骤 0.5：负向触发判定（v1.0.4 起强制）

在判定路径**之后、开始访谈/厘清之前**，必须先用下表排除**不应触发**本 Skill 的场景。命中任一行即**不进入**对齐流程，按"建议去向"收尾（不产出 Brief）。

| 用户输入特征 | 判定 | 建议去向 | |------------|------|---------| | 非法律类 Skill 创建（视频下载 / 读书笔记 / 通用工具 / 内容创作） | ❌ 不触发 | 通用 `skill-creator` 或工具类技能 | | 已提供完整可执行 Brief 且明确要求"直接编译 / 直接生成，别问我" | ❌ 不触发 | 直接交 `skill-creator` 编译 | | 仅问"skill 是什么 / 怎么装 / 适不适合我"（使用咨询） | ❌ 不触发 | 通用帮助文档 / `skill-manager` |

**灰度场景**（命中下表须**先追问再判定**，不得直接触发或拒绝）：

| 用户输入特征 | 追问话术 | 倾向 | |------------|---------|------| | "帮律师做案件管理工具" | "核心是法律业务流程，还是通用排期/项目管理？" | 法律业务流程→触发；通用排期→不触发 | | "审查合同条款合规性，但走技术合规"