Contract Scenario Router

---
name: contract-scenario-router
description: Identify the user's true contract-work intent and route it to the correct scenario (C1-C9). Use this skill FIRST for every contract request to determine scenario type, core objective, binding output standard, whether interactive intake is required, output weight tier, and the next skill in the chain — before any drafting, review or research happens.
---

# 合同 · 场景识别与意图路由

> 这是合同专家的**第一道工序**。每次接到用户的合同类需求，都必须先用本 skill 完成"识别意图 → 命中场景 → 锁定输出标准与工作流 → 判断是否需要交互采集"，再进入后续工序。**不要跳过本步骤直接起草/审查。**

## 本 skill 解决什么

把用户一句自然语言的需求，转化为一份明确的「合同任务单」，包含：
1. **命中的合同场景**（来自 C1–C9 场景决策表）
2. **该场景的核心应用目的、输出标准、典型工作流**
3. **是否需要交互采集**：合同工作高度依赖交易细节，绝大多数场景需先采集；判断是否进入 `contract-intake`
4. **输出档位与交付形态**：写明【输出档位】【交付物形态】【下一步技能】
5. **是否有需向用户澄清的关键缺口**

## 工作步骤

### 第一步：识别基础意图（六大基础意图）

先把用户需求归入以下一类，决定工作的"形状"：

| 基础意图 | 特征 | 主导工序 |
|---|---|---|
| **体系搭建** | 建管理架构、管理制度、模板库 | 生命周期顾问 / 起草引擎 |
| **合同生成** | 起草具体合同、补充协议 | 起草引擎 |
| **合同审查** | 审合同、评估签约背景与风险 | 审查引擎 |
| **谈判支持** | 制定谈判策略、要价让步 | 生命周期顾问 |
| **履行处置** | 履行中违约/纠纷的非诉应对 | 生命周期顾问 |
| **简易咨询** | 单点确认性合同问题 | 直接回答或轻量检索 |

### 第二步：命中具体场景（查决策表）

打开 `references/contract-scenario-table.md`，用「场景快速判别索引」把需求精确命中到某个三级场景（C1–C9）。命中后，**锁定该场景的四件事**：
- 核心应用目的（要达到什么）
- 输出标准（最终成果长什么样）
- 典型工作流（按什么步骤做）
- 输出档位与交付形态：按决策表写入【输出档位】【交付物形态】【下一步技能】

### 第三步：判断是否需要交互采集（关键）

合同工作几乎都依赖具体交易事实。按下表判断是否先进入 `contract-intake`：

| 场景 | 是否强制交互采集 | 必须先收集的关键事实 |
|---|---|---|
| C1 合同管理架构 | 是 | 组织架构图、核心业务线、各部门岗位职责 |
| C2 合同管理制度 | 是 | 现状（有无系统）、管理目标、痛点、合同类型分布 |
| C3 合同模板库建设 | 是 | 核心业务场景、需建模板的合同类型 |
| C4 具体合同起草 | 是 | 商业目的、资金流向、各方权责、商业预期与底线 |
| C5 合同背景评估 | 是 | 交易主体、交易类型、标的、金额、行业、特殊背景 |
| C6 合同条款审查 | 是 | 待审合同文本、本方立场口径、合同背景/特殊需求 |
| C7 合同谈判支持 | 是 | 本方交易地位、核心诉求与底线、冲突点 |
| C8 合同纠纷应急处置 | 是 | 案情时间线、已签合同与证据材料、对方反应 |
| C9 合同变更增删 | 是 | 原合同文本、要变更的条款与诉求 |

> 原则：**信息不足先采集，绝不臆造**。但能用互斥假设覆盖的（如"按已书面约定/仅口头约定"两分支），可在任务单中标注由后续工序并行假设，不必每次都停下追问。

### 第三·二步：判断是否需要接入用户标准（起草/审查类）

命中**起草类（C3/C4/C9）或审查类（C5/C6）**场景时，在任务单中标注是否走 `contract-standards-ingest`：

- 用户已附/已提及自有模板、范本、惯用条款、规则库、审查 Playbook、过往审查意见 → 标注【接入用户标准：是】，转化为条款库/审查 Playbook 后优先采用。
- 用户未提供 → 标注【接入用户标准：待告知】，在 intake 阶段或开工前主动一句话告知此能力可用，由用户选择是否提供；不提供则用通用标准，不强制。

### 第四步：输出合同任务单

以如下结构小结，交给下一工序。任务单不是最终成果；输出后必须按【下一步技能】逐个交接：

```
【命中场景】C4 具体合同起草
【基础意图】合同生成
【核心目的】为既有模板无法匹配的特殊合作量身起草完整合同
【输出标准】完整合同文本 + 特殊条款 + 风险批注
【是否交互采集】是 —— 需收集：商业目的/资金流向/各方权责/商业预期与底线
【输出档位】重量：完整合同文本（交付物）
【交付物形态】合同文本（含风险批注）
【下一步技能】contract-intake → contract-legal-research → contract-drafting-engine → contract-output-formatter
【关键缺口】交易频率与复杂度未知 → intake 中确认以选择合同结构套餐
```

## 输出档位与交付形态

档位按交付目的与成果分量判断，不按单个样例硬编码：

| 输出档位 | 典型交付形态 | 是否需交互采集 |
|---|---|---|
| 轻量 | 单点合同知识咨询、条款含义解释 | 通常否 |
| 中量 | 合同背景评估意见、谈判要点、补充协议、单类模板 | 是 |
| 重量 | 完整合同文本、合同审查意见书/风险清单、管理制度、模板库体系、纠纷非诉处置方案 | 是 |

重量级场景任务单必须写明完整技能链，并经交互采集补齐关键事实后再进入实质工序。

## 关键约束

- 场景识别**只做判断与规划，不做实质起草/审查**。
- 不确定命中哪个场景时，宁可向用户确认一句，也不要错判导致输出标准跑偏。
- 用户一个需求可能横跨多个场景（如"先评估这个合作要点、再帮我起草"= C5 + C4），允许命中多个场景并在任务单中按先后列出。
- 合同工作几乎都要交互采集；除非是单点知识咨询，否则不要在信息不全时直接产出合同/审查结论。

## References

- `references/contract-scenario-table.md` — 合同场景决策表（C1–C9：场景分类/二级/三级场景 × 核心目的/输出标准/典型工作流/提问示例 + 快速判别索引 + 档位规则）