法律 Skill 目标对齐
定位
本 Skill 是写法律 Skill 前的前置步骤——通过苏格拉底式提问，帮助你把零散的"经验/素材/直觉"转化为一份结构化、可被通用 skill-creator 等下游编译器消费的 Legal Skill Brief v1（详见 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 但不知道怎么开始""我脑子里有经验但没整理过""教我做" | 无素材路径 |
| 同时满足 | 先走有素材路径，再用访谈补缺口 |
安全预检（无论哪条路径都要做）：
- 敏感材料识别：检查用户上传或粘贴的内容是否含明显敏感信息（见 alignment-strategies.md 顶部的"敏感材料识别清单"）。
- 脱敏提示：如有敏感信息，提示用户："检测到 [敏感信息类型]，请确认是否已脱敏 / 是否需要本 Skill 协助脱敏（仅提示，不自动改写原文件）"。
- 外传确认：默认不上传 / 共享给任何外部服务。如需外部检索或服务，必须显式询问用户确认。
不要在没素材的情况下硬走有素材路径——会产出空洞的 Brief。
步骤 0.5：负向触发判定（v1.0.4 起强制）
在判定路径之后、开始访谈/厘清之前，必须先用下表排除不应触发本 Skill 的场景。命中任一行即不进入对齐流程，按"建议去向"收尾（不产出 Brief）。
| 用户输入特征 | 判定 | 建议去向 |
|---|---|---|
| 非法律类 Skill 创建（视频下载 / 读书笔记 / 通用工具 / 内容创作） | ❌ 不触发 | 通用 skill-creator 或工具类技能 |
| 已提供完整可执行 Brief 且明确要求"直接编译 / 直接生成，别问我" | ❌ 不触发 | 直接交 skill-creator 编译 |
| 仅问"skill 是什么 / 怎么装 / 适不适合我"（使用咨询） | ❌ 不触发 | 通用帮助文档 / skill-manager |
灰度场景（命中下表须先追问再判定，不得直接触发或拒绝）：
| 用户输入特征 | 追问话术 | 倾向 |
|---|---|---|
| "帮律师做案件管理工具" | "核心是法律业务流程，还是通用排期/项目管理？" | 法律业务流程→触发；通用排期→不触发 |
| "审查合同条款合规性，但走技术合规" | 指出"技术合规 ≠ 法律合规" | 不触发 |
| "把公司审批流程做成 skill" | "流程是否涉及法律判断（合同/合规/劳动关系）？" | 涉及→触发；纯 OA→不触发 |
灰度判定唯一原则：场景是否涉及法律领域（合同/诉讼/合规/尽调/知产/劳动/公司/家事/税务/刑事）。不确定时问用户"你是想把法律经验做成 Skill 吗？"——答否则不触发。
步骤 1A：有素材路径——多分类厘清
1A.1 材料分类（v1 起扩展为可组合类型）
v1 把素材分类从三类扩展为七类可组合类型（原 3 类保留并新增 4 类）：
| 分类 | 识别特征 | 厘清重点 |
|---|---|---|
| 样本（sample） | 成品文书：律师函、起诉状、合同、审查意见 | 提炼结构骨架 + 风格特征 + 风险点清单 |
| 流程 SOP（sop） | 步骤化文档：办案流程、审查清单、出庭准备 | 提炼决策点 + 分支条件 + 质量检查点 |
| 问答 Q&A（qa） | 一问一答：客户咨询、培训答疑、内部 FAQ | 提炼高频问题 + 标准答法 + 例外情形 |
| 规则包（rules） | 结构化规则：阈值表、判断标准、合规清单 | 提炼阈值与判断逻辑 + 来源 + 适用范围 |
| 对话修订记录（revisions） | 历史对话 / 反复修改痕迹：律师-客户沟通、稿件修改批注 | 提炼风格偏好 + 反馈修订倾向 + 常见避坑 |
| 工具与数据源（tools-data） | 工具输出、API 数据、数据库快照 | 提炼输入/输出格式 + 数据来源 + 联动方式 |
| 法源原文（authorities） | 法律条文、司法解释、案例原文、监管文件 | 提炼法源时效 + 适用范围 + 引用格式 |
迁移提示：v0.x 仅支持前三类，v1 起后四类也作为正式素材类型。各 references（alignment-strategies.md）给出每类的完整厘清策略。
1A.2 领域 / 阶段 / 任务识别（v1 起正交标签）
v0.x 强制单一"法律模板骨架"。v1 起改为正交标签——四个维度独立选择：
| 维度 | 说明 | 典型值 |
|---|---|---|
| 任务动作类型（action） | Skill 做什么动作 | 起草 / 审查 / 谈判 / 起诉 / 答辩 / 尽调 / 扫描 / 抽取 / 组织 / 监控 |
| 法律领域（domain） | 涉及的法律分支 | 合同 / 诉讼 / 合规 / 尽调 / 知产 / 劳动 / 公司 / 家事 / 税务 / 刑事 / 其他 |
| 程序阶段（stage） | 时间或程序位置 | 见 legal-domain-mapping.md 的 stage 枚举 |
| 文书类型（doc_type） | 产出形态 | demand-letter / complaint / answer / contract-review / compliance-report / tool / data-pack |
v1 起不再强制所有 Skill 选单一法律模板骨架。一个跨领域任务可同时挂多个
domain标签；非文书 / 工具型任务用doc_type: tool或data-pack标识。
1A.3 引导补全五问
厘清完，把已从素材中提取的要素列给用户看，明确指出缺口（通常是第 4 问"向谁交付"的三子项和第 5 问"知识支撑"的法源时效），引导用户补全。一次只问 1-2 个缺口，不要一次抛出五个空字段吓退用户。
1A.4 素材未覆盖要素的补全策略
当素材未直接体现某要素时，按以下策略处理，不要默默推断：
| 要素 | 素材中有线索 | 素材中无线索 |
|---|---|---|
第 4 问 operator |
从使用场景反推，列出推断依据，请用户确认 | 切换为访谈模式，用 interview-guide.md 第 4 问引导用户补全 |
第 4 问 represented_party |
从文书抬头 / 落款 / 立场反推，请用户确认 | 访谈模式补全；常见错误是误填为法官（法官是 output_audience） |
第 4 问 output_audience |
从文书语言风格 / 引用格式反推，请用户确认 | 访谈模式补全 |
第 5 问 法源 effective_date |
从素材中标注的版本号 / 引用日期提取 | 标 unverified + 在待确认清单列出 |
| 第 3 问 决策点 | 从 SOP 提取步骤 + 从样本逆推决策点 | 标"决策点基于样本反推，可能遗漏分支" |
关键原则：推断不可怕，可怕的是不告知用户"这部分是我推断的"。每个推断要素必须在"待确认清单"中标注推断依据和确认方式。
步骤 1B：无素材路径——苏格拉底式访谈
不假设用户有任何素材。通过逐题引导，从用户脑中的"经验直觉"挖出五问答案。
访谈遵循三条铁律：
- 一次一问：不要一次列五个问题，用户会放弃。
- 给锚点不给答案：每个问题配 2-3 个具体例子帮助联想，但不替用户做决定。
- 追问直到具体：用户说"帮助客户"→ 追问"哪个阶段、什么角色、什么场景下需要帮助"。
第 4 问在 v1 拆为三个子问题逐次访谈（详见 interview-guide.md）：
- 4a：
operator—— 谁会直接用这个 Skill？ - 4b：
represented_party—— Skill 是为谁的立场服务的？ - 4c：
output_audience—— 产出物最终交给谁看？
第 5 问在 v1 新增法源时效确认子问题（详见 interview-guide.md）：法律依据的生效日期 / 法域 / 是否最新有效。
步骤 2：识别一组正交标签
无论素材路径还是访谈路径，最终都要落到一组正交标签上：
- 任务动作类型：审查 / 起草 / 扫描 / 抽取 / ...（详见 legal-domain-mapping.md）
- 法律领域：合同 / 诉讼 / 合规 / ...
- 程序阶段：见 stage 枚举
- 产出形态：text-document / table / tool / data-pack
标签组合示例：
- 劳动合同审查 = 审查 + 劳动 + non_litigation + text-document
- App 数据合规扫描 = 扫描 + 合规 + post_launch + table
- 证据组织器 = 组织 + 诉讼 + first_instance + data-pack（非文书型）
- 知识产权维权策略 = 策略 + 知产 + enforcement + text-document
不再强制"单一法律模板骨架"，让跨领域 / 工具型任务能正确路由。
步骤 3：产出 legal-skill-brief/v1
把五问的答案组装成一份 Legal Skill Brief v1，格式遵循 standard-prompt-output.md。
Brief v1 关键约束：
- Brief 顶部必须标注
legal-skill-brief/v1与question-set/v1版本。 - 上下文元数据（
skill_family/jurisdiction/stage/operator/represented_party/output_audience/doc_type/tags）为可选 metadata——下游消费者可不读，但不读不影响 Brief 完整性。 - 五问要素齐全，缺一不可。如果某要素访谈完仍无法确定，标
[待用户确认]并在末尾"待确认清单"中按blocker/warning分类列出，不要编造。 - 法源条目必须带
effective_date（施行日期）/jurisdiction/verification_status三列，verified条目须补证据列（见上）。 - 阈值与判断标准必须带
source（来源）。 - 素材溯源 quality 必须填写（
unrated也算）。 - 安全与脱敏说明段必须填写（即便无敏感信息也填"无敏感信息识别"）。
- 标识符
skill_family使用 kebab-case（如labor-contract-review）；stage / role / doc_type 使用 snake_case。 - 第 4 问三子项防错核对（v1.0.4 起强制，对应 C-06）：组装 Brief 前，必须对
operator/represented_party/output_audience做一次互斥核对，并在 Brief 二.4 段末尾追加一行"防错核对"：逐一确认 (a) 三者均非空、(b)represented_party不是读者类角色（法官/对方律师/监管机关属output_audience，绝不填入represented_party）、(c)operator与output_audience不混淆。任一项存疑，不得静默放过，须在"待确认清单"标 blocker 或 warning。 - 法源缺失结构化降级（v1.0.6 起强制，对应 C-07/C-08）：当素材或访谈未提供任何 authorities 法源原文（只有法条名称、或无任何法源线索）时，二.5 法律依据表必须显式写首行占位："法源原文缺失：以下条目均
unverified，待用户补充权威出处后升级"，且每一法源行verification_status一律unverified、effective_date填unverified（不得凭名称编造施行日）。若 Brief 会产出具体法律建议，必须在"待确认清单"登记blocker（"关键法源原文缺失"）并判定handoff_ready = false；否则登记 warning（"法源时效未验证"）。法域已知或可定位不能降低 blocker 等级。 - 不登记空壳法源行（finding#1 回填，v1.0.5 起强制，对应 C-07/C-08 细化）：二.5 法律依据表的每一行必须是「可定位的具体法源」——至少具备
jurisdiction+ 可识别的法条/文件标识（条号、文件全称、或案例案号）+effective_date/verification_status三列。当素材仅给出法源主题或法规名称（如"《个人信息保护法》"）、但无条号、无原文、无适用指向时，不得为凑满表格而登记一行「名称 + 三列全空unverified」的空壳条目；正确做法是：仅在降级首行占位中转录该名称作为"待补线索"，并在"待确认清单"明确列出"需补充《XX法》具体条号/适用版本"，由用户补齐后再登记正式法源行。例外：若素材已点名法域且名称足以定位法源范围（如 case-03 明确 CN + 四部法规名称），可转录名称行但effective_date/verification_status仍须unverified，且须注明"仅名称、待补条号与施行日"，不得据此编写任何具体法律结论。
步骤 4：交付与移交
- 把 Brief 展示给用户确认。
- 用户确认后，明确提示下一步可调用：
- 通用
skill-creator（自然语言意图友好） - 或你环境中可用的法律领域 Skill 编排器（路由决策友好）
- 通用
- 本 Skill 不直接产出 SKILL.md / references / scripts——那是下游的事。
五问要素自检清单
产出 Brief 前，必须逐条核对：
- 第 1 问 输入什么：列出了必要输入与可选输入，标注了信息来源
- 第 2 问 输出什么：明确了产出格式、字数/结构要求、质量标准、产出形态
- 第 3 问 处理逻辑：写了主要步骤、决策点、可选分支、异常路径
- 第 4 问 向谁交付（v1 三子项）：
-
operator明确或标"待补" -
represented_party明确或标"待补"（不与output_audience混淆） -
output_audience明确或标"待补" - 触发场景 + 语气基调已写
-
- 第 5 问 知识支撑：法源带三列（jurisdiction / effective_date / verification_status）；范本来源；风险清单；风格偏好
- 上下文元数据：identifier 使用 kebab-case；stage / role / doc_type 使用 snake_case
- 规则引擎（如适用）：阈值与判断标准带 source
- 素材溯源：quality 字段已填
- 安全与脱敏：敏感信息状态、外传策略、高风险结论复核已写
- 待确认清单：按 blocker / warning 分类
- 状态判定：标注
structurally_complete与handoff_ready（见完整性规则段）
任一项缺失或模糊，回到对应步骤补全，不放过半成品。handoff_ready = false 时须在 Brief 顶部显式标注 blocker 数量。
安全与合规边界
本 Skill 在处理用户材料时遵循以下安全约束（与 standard-prompt-output.md 的"五、安全与脱敏说明"段联动）：
敏感材料处理
- 默认不假设用户已脱敏：处理历史文书、咨询记录、内部 SOP 时，主动识别明显敏感信息（见 alignment-strategies.md 顶部"敏感材料识别清单"）。
- 提示但不自动改写原文件：发现敏感信息后，提示用户脱敏并请其确认，不擅自修改用户提供的内容。
- Brief 中默认使用脱敏表述：用户提供的真实姓名 / 金额 / 案件名在 Brief 内引用时，建议替换为脱敏形式（如"买方/卖方""XX 公司"）。
禁止默认外传
- 任何外部检索 / 上传 / 分享须由用户显式确认。默认行为是不外传、不上传、不调用外部 API。
- 如需联网检索（如查最新司法解释），先告知用户再执行。
法源时点与版本
- 每条法源引用必须包含
effective_date（施行日期，不是通过日 / 公布日）与jurisdiction（法域）。 - 用户未确认时效的法源，标
verification_status: unverified，不当作确定性依据输出。 - 涉及监管规则 / 行业规范的，须额外标注最近一次更新日期。
- verified 证据门槛（v1.0.2 起）：标
verified的法源必须满足最小证据要求（source_url/source_file+verified_by+verified_at+version_as_of）；仅有法条名称或从样本反推时不得升级为verified（详见 standard-prompt-output.md）。
高风险结论必须执业律师复核
以下产出在 Brief 中必须标注"需执业律师复核"：
- 最终法律意见书 / 起诉状 / 答辩状 / 合同定稿类文书
- 起诉应诉策略建议（涉及程序选择、时效判断）
- 合规整改建议（涉及监管报送或重大经营变更）
- 高额标的（用户团队阈值表定义）的合同审查结论
alignment 不替代律师复核；下游编译出的 Skill 也不替代。
输入要求
本 Skill 接受以下输入：
- 素材路径：用户提供的文件路径（支持 .md / .txt / .docx）
- 粘贴内容：用户直接粘贴的样本 / SOP / Q&A / 规则 / 对话修订 / 工具数据 / 法源原文
- 场景描述：用户用自然语言描述"我想做一个 XX skill"
- 混合：上述任意组合
输出要求
- 一份 Legal Skill Brief v1（markdown 格式，遵循 standard-prompt-output.md）
- Brief 末尾附"待确认清单"（按 blocker / warning 分类）
- 明确提示调用通用
skill-creator（或法律领域 Skill 编排器）完成编译
适用场景
- 律师把多年积累的某类文书做成可复用 Skill
- 律所把内部 SOP 沉淀为团队级 Skill
- 从客户咨询记录中提炼可复用问答 Skill
- 法律培训师把课程方法论转化为 Skill
- 把规则包 / 阈值表沉淀为可执行 Skill
- 把工具 / 数据源打包成可调用 Skill
- 跨领域任务（同时涉及合同 + 诉讼 + 合规的复合 Skill）
- 任何"我有经验/素材，想做成 Skill 但不知如何下手"的场景
边界
- 不直接生成 Skill 文件：只产出 Brief v1，编译交给下游。
- 不替代法律判断：厘清出的"处理逻辑"和"风险清单"需由执业律师最终确认。
- 不做证据不足的推断：素材或访谈不足以支撑的结论，标
[需补充]，不臆测。 - 不外传用户数据：默认不调用外部服务；外部操作须用户显式确认。
- 不验证法源时效：法源是否现行有效由用户在
effective_date/verification_status中标注，alignment 不替用户做判断。
不应触发的场景（负向边界，T-017）
以下场景不应触发本 Skill：
- 非法律类 Skill 创建：通用工具类、内容创作类、非法律业务流程类 Skill 的前置对齐，不归本 Skill。判断标准：场景是否涉及法律领域（合同 / 诉讼 / 合规 / 尽调 / 知产 / 劳动 / 公司 / 家事 / 税务 / 刑事）。
- 用户已提供完整可执行 Brief 且明确要求直接编译：当用户已给出结构完整的 Brief 并明确说"直接编译 / 直接生成 SKILL.md"，应直接交给 skill-creator，不走本 Skill 的对齐流程。
- 用户只是问"什么是 Skill / 怎么用 Skill"：这是使用咨询，不是创建前置对齐，不触发。
如果不确定是否应触发，优先询问用户"你是想把法律经验做成 Skill 吗？"——若回答为否，则不触发。