---
name: regulatory-incoming-letter
description: 处理监管下发函件（行政处罚通知 / 责令整改 / 监管谈话 / 程序性通知 / 专项自查工作函 / 监管问询）的全流程：录入 + 6 分法自动归类 + 任务派发 + 进度跟踪 + 上报材料汇总。本土化版的核心亮点 —— 原版 regulatory-legal 没有这条主线。用户说"我们收到 [监管单位] 一份 [函件类型]"、"监管下发了"、"工作函"、"自查通知"、"约谈"、"监管问询"、"警示函"、"行政处罚决定书"，或上传函件 PDF / 扫描件时使用。
argument-hint: "[函件文件路径 或 粘贴函件文本]"
---

# /incoming-letter

1. 读 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` → 公司画像、escalation_path、归口部门联系人
2. 用下面的 7 阶段工作流
3. 录入（OCR + 字段抽取）→ 自动归类（6 分法）→ 按类处置 → 任务派发 → 进度跟踪 → 上报材料汇总 → 闭环
4. 关键截止日自动锁到监管要求回复期前的内部缓冲日期（默认 5 个工作日）

---

## 事项上下文

**事项上下文**：核查实务层级 `profile.md` 中 `## 事项工作区`。如果 `启用` 是 `✗`（企业内部法务用户默认），跳过本段 —— 技能用实务层级上下文，事项机制不可见。如果启用且没有当前事项，问："这是哪个事项？跑 `regulatory-matter-workspace switch <slug>` 或说切到实务层级。"

对监管下发函的特殊处理：**每一份独立的监管函件都可以视作一个独立事项**（特别是涉及处罚 / 约谈类高风险函件）。建议在私人执业场景下为重要函件单独建事项，企业内部法务场景下走实务层级 + 内规差异台账（`gap-tracker.yaml`）跟踪。

---

## 用途

中国企业内部法务最高频的工作是**响应**监管下发的函件 —— 这与原版的"主动监控"工作流方向相反，是本土化版的**核心增量**。本技能处理：

- **接收**：纸质函件扫描、邮件附件、监管平台推送（如金管总局检查通报系统、网信办约谈通知等）
- **理解**：抽取关键字段（来文单位、文号、要求事项、回复期限）
- **分类**：按 6 分法判定函件类型，决定处置路径
- **派发**：根据要求事项拆解为内部整改任务（`inspection-task`），按归口部门派到具体负责人
- **跟踪**：截止日三档预警（30 / 15 / 5 天，反映监管截止日的硬刚性）
- **上报**：到期前自动汇总各部门提交的整改材料，生成上报草稿
- **闭环**：等监管回函（通过 `regulatory-reg-feed-watcher`（监管动态监测）或人工录入），决定是否结案

**与 `regulatory-reg-feed-watcher`（监管动态监测）的区别**：

- 监管动态监测：**主动监控** —— 抓取监管公开发布的规则、处罚通报、答记者问等
- 监管来函处置：**被动响应** —— 处理监管**直接发给本公司**的函件（有明确受文单位 = 本公司）

监管动态监测可能会捕获到"金管总局自查工作函"等普遍性通知，**如本公司也是受文单位**，应转入本技能（监管来函处置）流程做完整处置。

---

## 第 1 步：录入与字段抽取

### 1.1 接收来源

支持三种入口：

- **文件路径**：用户上传 PDF / 图片扫描件 / Word 等到工作目录或文档存储
- **粘贴文本**：函件正文已 OCR / 转写好的纯文本
- **手工字段输入**：监管平台推送的结构化数据，用户手工填关键字段

### 1.2 字段抽取（调用能力 `document.extract_fields`）

调用 `document.extract_fields` 能力抽取以下字段（**必填项 ✱**）：

| 字段 | 必填 | 说明 |
|---|---|---|
| `来文单位` ✱ | 是 | 具体监管机构名称（如"国家金融监督管理总局上海监管局"、"国家网信办网络数据管理局"），含层级（中央 / 省 / 市） |
| `文号` ✱ | 是 | 格式如 `沪金监函〔2026〕XX 号` —— 关键追溯标识 |
| `收文日期` ✱ | 是 | 公司实际收到的日期（**不是**函件落款日期），可能差几天 |
| `落款日期` | 否 | 监管在函件上的落款日期 |
| `函件名称` ✱ | 是 | 如《关于开展消费金融业务合规自查的工作函》 |
| `函件类型 (初判)` | 否 | 字段抽取大模型的初步判断，**第 2 步会用 6 分法重新核定** |
| `受文单位` ✱ | 是 | 必须是本公司全称（如果不是 → 函件转错，确认后退回） |
| `抄送范围` | 否 | 其他抄送方（如"抄送：上海地方金融监管局") |
| `要求事项` ✱ | 是 | **列表**，从函件正文抽取每条具体要求（如"自查放贷利率合规性、自查营销话术合规性、提交自查报告"等） |
| `回复期限` ✱ | 是 | 监管要求公司提交回复 / 整改报告的最晚日期。如函件用"X 日内"等相对表述，结合**收文日期**计算 |
| `是否要求书面回复` | 否 | 如"以书面形式提交"、"提交整改报告" |
| `是否要求面谈 / 到场` | 否 | 如"派分管负责人参加 X 月 X 日座谈" |
| `是否含听证 / 申辩告知` | 否 | 如有 → 触发**第 4 类程序性通知** 的紧急路径 |
| `提交方式` | 否 | 如"密码邮件至 xxx@xxx.gov.cn"、"现场提交"、"挂号信" |
| `执法人员 / 联系人` | 否 | 函件中署名的执法人员或具体联系人电话 |
| `附件清单` | 否 | 函件附带的清单、自查表等 |

**抽取后必须给用户人工核对**，特别是 ✱ 必填字段。在大模型抽取结果旁标 `[抽取自第 X 段]` 让用户能溯源核对。

### 1.3 抽取结果保存

抽取后落地为结构化 YAML 文件到 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/incoming-letters/<letter-id>/letter.yaml`，附原始扫描件 / 文本副本到同目录。

`letter-id` 命名建议：`YYYY-MM-DD-<监管缩写>-<文号尾号>`，例如 `2026-05-25-金管沪-XX`。

---

## 第 2 步：自动归类（6 分法 + 子类）

按以下决策树自动归类（详细分类规则见 `references/letter-classification-rules.md`）：

```
是否含"作出行政处罚决定 / 罚款 / 没收 / 暂停业务 / 吊销许可"等表述？
├── 是 → 第 1 类 行政处罚类
└── 否
    │
    是否含"事先告知 / 听证通知 / 陈述申辩告知"等表述？
    ├── 是 → 第 4 类 程序性通知类（行政处罚法第 44-47 条）
    └── 否
        │
        是否含"约谈 / 监管谈话 / 派负责人到场说明"等表述？
        ├── 是 → 第 3 类 监管谈话类
        └── 否
            │
            是否含"现场检查 / 现场检查意见书"等表述？
            ├── 是 → 第 2 类（子类 2b）行政监管措施—现场检查反馈
            └── 否
                │
                是否含"自查 / 专项整改 / 排查"等表述？
                ├── 是 → 第 5 类 专项自查 / 工作函类
                └── 否
                    │
                    是否含"说明情况 / 反馈材料 / 提供资料"等表述？
                    ├── 是 → 第 6 类 监管问询类
                    └── 否（默认）→ 第 2 类（子类 2a）行政监管措施—责令整改
```

**归类后输出给用户人工确认**（除非置信度 > 0.95）：

> "根据要求事项和函件语言，**初判为第 X 类（[类别名]）**。处置路径：[简短说明]。
> 确认归类后我会触发对应处置流程。如归错，请告诉我正确类别。"

---

## 第 3 步：按类别选择处置路径

### 第 1 类：行政处罚类

**触发动作**：

1. **法定时效核查**（最高优先级，**当天**完成）：
   - 行政复议申请期限：**60 日**（《行政复议法》第 9 条），自收到决定书之日起算
   - 行政诉讼期限：**6 个月**（《行政诉讼法》第 46 条），自知道或者应当知道作出行政行为之日起算
   - **特别注意**：证监会等特别监管领域可能有更短的复议期，需对照具体法规
   - 在 `letter.yaml` 中记录两个法定截止日：`reconsider_deadline`、`litigation_deadline`

2. **法务总监 + 首席合规官紧急会签**（`escalation_path.重大业务影响决策`）：
   - 是否接受处罚？
   - 是否申请行政复议？
   - 是否提起行政诉讼？
   - 是否进行公司内部责任追究？

3. **内部整改任务派发**：将处罚决定中"责令整改"部分拆解为 `inspection-task`

4. **舆情准备**：如处罚涉及公众披露（上市公司、消费者保护类），同步触发产品 / 公关部门信息披露评估

**关键风险点**：处罚事实的认定 + 处罚程序的合法性 + 是否有从轻 / 从重 / 不予处罚情节未被采纳 —— 这些是后续复议 / 诉讼的核心争点。

### 第 2 类：行政监管措施类（子类 2a 责令整改 / 2b 现场检查反馈）

**触发动作**：

1. **时效核查**：
   - 多数监管措施类决定也可申请行政复议 / 诉讼，但**时效与处罚相同（60 日 / 6 月）**
   - 警示函 / 监管意见书在部分领域被认为"不可诉"（如证券公司收到证监会警示函），但 2020 年以来司法实务有变化，建议保留复议 / 诉讼路径

2. **限期整改 → 拆解为 `inspection-task`**：
   - 子类 2a（责令整改）：整改任务通常较具体，按业务部门派单
   - 子类 2b（现场检查反馈）：常伴检查发现的问题清单，需逐项拆解 + 内部根因分析

3. **整改报告（如要求书面回复）**：
   - 收文 + 缓冲 30/15/5 天三档预警
   - 到期前 X 天自动汇总各部门提交材料 → 上报草稿

### 第 3 类：监管谈话类

**触发动作**：

1. **派人到场的准备**：
   - 谁去？默认派"业务对应分管 + 法务"组合，按 `escalation_path.重大业务影响决策` 决定具体人选
   - 准备材料：本次涉及业务的近期数据、合规自查结论、已经采取的措施

2. **谈话纪要的处置**：
   - 谈话结束后**几天内**通常会有"约谈通报"或"谈话纪要"发回
   - 如要求出具书面承诺 / 整改计划：拆解为 `inspection-task`

3. **是否触发行政复议 / 诉讼**：一般认为单独的监管谈话**不可诉**（不直接产生权利义务变动），但**约谈通报**如含"责令整改"等内容，按第 2 类处理

### 第 4 类：程序性通知类（新增，原 6 分法没有）

**触发动作 —— 这是法定程序，时效极短，错过有不利后果**：

1. **听证申请期限**：收到事先告知书之日起 **3 个工作日内**（行政处罚法第 47 条）。**当天计算，预留 1 个工作日内部决策缓冲。**

2. **陈述申辩准备**：
   - 行政处罚法第 44 条：拟作出行政处罚决定前，应告知拟作出的内容、依据、事实
   - 陈述申辩材料应当指向：事实认定有误 / 法律适用不当 / 程序违法 / 从轻减轻情节

3. **`escalation_path.重大业务影响决策` 紧急触发**：
   - 是否申请听证？
   - 是否提交陈述申辩？
   - 谁去陈述 / 听证？

4. **法务 + 外聘律师协同**：建议立即启动外聘律师介入（特别是听证）

### 第 5 类：专项自查 / 工作函类

**触发动作**：

1. **要求事项拆解为 `inspection-task`**：
   - 14 条自查事项 → 14 个 `inspection-task`
   - 每条任务自动匹配归口部门（按 `policy_owner` 索引）
   - 整改负责人按业务部门指派（`task_owner`）

2. **进度跟踪**：30 / 15 / 5 天三档预警

3. **上报材料汇总**（到期前 X 天）：
   - 自动收集各部门提交的自查材料
   - 按监管要求格式生成上报草稿
   - 走法务总监 + 首席合规官会签后由法务联系人提交

### 第 6 类：监管问询类

**触发动作**：

1. **判断问询性质**：
   - 普通问询函（如证监会问询）—— 要求公司说明情况、提供材料
   - 关注函（深沪交易所对上市公司）—— 监管关注但不必然导致后续动作
   - 信息核实函（如反洗钱可疑交易核实）—— 涉具体客户 / 业务的事实问询

2. **回函起草**：
   - 按监管问询事项逐条回应
   - 涉具体客户 / 业务数据需脱敏处理
   - **不要**主动披露问询范围外的事项

3. **是否触发后续监管动作**：问询本身一般不直接产生权利义务，**但回函内容会被监管援引**，故回函质量决定后续走向

---

## 第 4 步：任务派发（拆解为 inspection-task）

将函件要求事项拆解为 N 条 `inspection-task` 类型的整改事项，写入 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/gap-tracker.yaml`：

```yaml
gaps:
  - id: INS-001                            # 函件相关任务 ID 用 INS- 前缀（区别于 GAP- 前缀的政策内规差异）
    requirement: "自查放贷利率合规性 —— 是否符合金管总局新规第 X 条"
    regulation: "金管总局《关于开展消费金融业务合规自查的工作函》 沪金监函〔2026〕XX 号"
    policy_affected: "消费金融业务合规手册"
    gap_type: "inspection-task"            # 阶段 3 启用的新类型
    inspection_letter_id: "2026-05-25-金管沪-XX"  # 关联到 letter.yaml
    inspection_category: "第 5 类 专项自查"  # 来自第 2 步的归类结果

    # 负责人模型（与 gap-surfacer 的结构定义 v2 对齐）
    policy_owner:
      name: "王琳"
      department: "法务部"
      dm_id: "feishu_xxx"
    task_owner:
      name: "张总"
      department: "业务一部"
      dm_id: "feishu_yyy"

    # 时效
    opened: 2026-05-25
    due: 2026-06-19                        # 监管要求回复期 - 5 个工作日内部缓冲
    regulatory_deadline: 2026-06-24        # 监管要求的硬截止日
    status: "open"
    status_verified: true                  # 函件来源已核实（监管直接下发）

    # 任务派发追踪
    notified_task_owner: false
    notified_policy_owner: false
    reminders_sent: []

    # 上报追踪
    submission_required: true              # 是否需要纳入上报材料
    submission_received: false             # 是否已收到业务部门反馈
    submission_received_date: ""           # 收到反馈的日期
    submission_content: ""                 # 业务部门提交内容摘要

    source_tags:
      - "[监管下发函]"
      - "[金管总局公开栏目]"
```

派发后**逐条预审**给法务联系人审核后才发 DM（继承 `regulatory-gap-surfacer`（内规差异呈现）的逐条预审 + 显式批准规则）。

---

## 第 5 步：进度跟踪

复用 `regulatory-gap-surfacer`（内规差异呈现）的提醒机制，但 **`inspection-task` 用三档预警**（比常规内规差异更紧）：

| 距离监管截止日 | 提醒动作 |
|---|---|
| 30 天 | 一次预提醒给 `task_owner`（"监管要求 30 天后提交，开始动手"） |
| 15 天 | 二次提醒，**抄送** `policy_owner` |
| 5 天 | 三次紧急提醒，`task_owner` + `policy_owner` + `escalation_path.重大业务影响决策` |
| 已超期（监管截止日已过且未上报） | **🔴 红色告警**，立即上报 `escalation_path.最终决策` + 法务总监紧急会议 |

提醒发送严格走 `notification.preview_and_send` 能力 + 逐条预审。

---

## 第 6 步：上报材料汇总

监管截止日前 **X 个工作日**（默认 5 天，可在冷启动访谈中配置），自动汇总：

### 6.1 收集

- 遍历该 `inspection_letter_id` 下的所有 `inspection-task`
- 收集每条任务的 `submission_content`、`submission_received_date`
- 标识缺失项（仍未收到反馈的任务）

### 6.2 生成上报草稿

按 `references/report-material-template.md`（上报材料模板）中的格式生成草稿：

```markdown
# [函件名称] 整改 / 自查报告

致：[来文单位]
关于：[函件名称]
文号引用：[文号]
公司名称：[本公司]

---

## 一、回应概述

本公司收到贵 [局 / 委] 于 [日期] 下发的 [函件名称]（[文号]），高度重视，
立即组织相关部门开展自查 / 整改工作。现将工作情况报告如下：

## 二、整改 / 自查事项明细

### 事项 1：[要求事项 1]

**整改情况**：
[业务部门提交的内容]

**已完成 / 进行中 / 风险接受**：[状态]

**支持材料**：[附件清单]

[逐条罗列每个 `inspection-task`]

## 三、整体结论

[整改 / 自查整体结论。如有未完成项需诚实说明，给出后续时间表]

## 四、本公司承诺

[本公司就本次自查 / 整改作出的承诺]

---

附件：
- 附件 1：[支持材料 1]
- 附件 2：[支持材料 2]
- ...

公司盖章：[公章位置]
签发人：[签字]
日期：[日期]
联系人：[姓名 + 电话]
```

### 6.3 走会签

按 `escalation_path`：
- 法务负责人初审
- 首席合规官（CCO）复审
- 总经理 / 法定代表人签字（如要求公章 + 法人签字）
- 法务联系人提交

### 6.4 提交追踪

提交后在 `letter.yaml` 中记录 `submission_date`、`submission_method`（密码邮件 / 现场 / 挂号信）、`submission_receipt`（监管收讫回执）。

---

## 第 7 步：闭环

**等监管回函**：

- 提交后通常 7-30 天内收到回函（监管确认收讫 / 提补充要求 / 通过验收 / 启动下一轮）
- 通过 `regulatory-reg-feed-watcher`（监管动态监测）监控相关监管栏目，或通过邮箱 / 收发室人工录入回函
- 回函如要求"补充材料"或"再次自查" → **进入新一轮监管来函处置流程**（同一 `letter-id` 下加 `round: 2`）
- 回函如确认"通过验收 / 不再追究" → 标 `letter.yaml` 的 `status: closed` + 同步关闭关联的 `inspection-task`

**长期未收到回函**（>60 天）：

- 标 `status: 待回函`
- 不自动关闭，但移出活跃台账显示
- 重要函件（处罚类 / 重大整改类）保持关注，重要节点（如周年）触发"回函未到提醒"

---

## 重大动作确认环节（按函件类别分档触发）

| 当前动作 | 触发 `escalation_path` 字段 | 提示内容 |
|---|---|---|
| 第 1 类 行政处罚：决定是否复议 / 诉讼 | `重大业务影响决策` + 法务总监 + 首席合规官联签 | "本动作涉及处罚决定的法定救济。业务规范显示需要 [角色] 拍板。是否已上报？" |
| 第 4 类 程序性通知：决定是否申请听证 / 陈述申辩 | `重大业务影响决策`（紧急） | "听证申请期限 3 个工作日。业务规范显示需要 [角色] 立即拍板。" |
| 第 1 / 2 / 3 / 5 / 6 类：提交上报材料 / 整改报告 / 回函 | `重大业务影响决策` + 会签 | "本动作进入监管档案，作为公司正式表态。业务规范显示需要 [角色 A] + [角色 B] 会签。是否完成？" |
| 任一类：标某 `inspection-task` 为风险接受 | `显著不符合项目会签` | "风险接受是有意识的合规决策。需要 [角色] 签字。是否已完成？" |
| 任一类：关闭整个函件（`status: closed`） | `首道审核`（法务确认） | "确认本函件相关整改均已完成且监管已确认。是否标记为关闭？" |

未明确"是"前**不**触发对应动作。

---

## 输出

```markdown
[工作秘密标识 —— 按 ## 谁在用这个插件 + shared/header-by-role.md 选定，通常为"内部合规分析 — 公司内部使用"]

> **⚠️ 复核提示**
> - **来源**：函件 [letter-id]（原件保存在 $LEGAL_AGENT_PROFILE_HOME/regulatory-legal/incoming-letters/[letter-id]/）
> - **分类**：第 X 类 [类别名] —— [简短依据]
> - **关键截止日**：监管要求 [日期]，内部缓冲 [日期]
> - **拆解任务**：[N] 条 `inspection-task`，[已分配 / 待分配]
> - **需要你判断的事项**：[N 项已用 `[复核]` 内联标注]

## 监管来函处置工单：[函件名称]

**来文**：[来文单位] [文号]
**收文**：[收文日期]
**函件类型**：第 X 类 [类别名]
**回复期限**：[日期]（剩 [N] 天）

### 字段抽取结果

| 字段 | 值 |
|---|---|
| 来文单位 | [...] |
| 文号 | [...] |
| 函件名称 | [...] |
| 要求事项 | [...] |
| 回复期限 | [...] |
| 抄送范围 | [...] |
| ...（其余字段） | ... |

### 6 分法归类依据

[函件文本中触发归类的关键短语 + 类别置信度]

### 处置路径

[按类别的具体动作清单，含时效 / 责任人 / 必要文档]

### `inspection-task` 拆解

| ID | 要求事项 | 归口部门 | 整改负责人 | 截止日 |
|---|---|---|---|---|
| INS-001 | [...] | [...] | [...] | [...] |
| ...（共 N 条） | | | | |

### 下一步必做

1. [紧急动作 1，如"3 个工作日内决定是否申请听证"]
2. [紧急动作 2]
3. [常规动作]

---

**下一步？选一个我来展开**：

1. **派发任务** —— 我把 [N] 条 `inspection-task` 通过 DM 通道（逐条预审）发给负责人
2. **触发会签** —— 我起草给法务总监 + 首席合规官的简报，含函件全文 + 分类依据 + 待决策点
3. **追加补充信息** —— 我注意到 [事项] 在函件中表述含糊，需要 [获取来源] 进一步确认
4. **打开任一任务详情** —— 告诉我 INS-XX，我展开任务的细节 + 起草给具体负责人的 DM
5. **生成上报材料草稿** —— 各部门反馈到位后，我按 `references/report-material-template.md`（上报材料模板）生成草稿
6. **其他** —— 告诉我

**清单之外我会问的一个问题**：[本函件中可能被遗漏但有影响的事项 —— 如"本次自查范围是否会牵出关联问题"、"抄送方上海地方金融监管局是否会单独跟进"等]
```

---

## 与其他技能的协作

| 上游 / 下游 | 协作方式 |
|---|---|
| **`regulatory-reg-feed-watcher`（监管动态监测）** ← | 如果监管信息源中识别到"针对本公司"的工作函（通常通过反向匹配关注清单 + 公司全称），转入本技能处理 |
| **`regulatory-gap-surfacer`（内规差异呈现）** → | `inspection-task` 写入 `gap-tracker.yaml`，复用其内规修改跟进 / 提醒 / 关闭机制 |
| **`regulatory-policy-diff`（政策比对）** → | 函件中如涉及具体监管规则（如新发布的部门规章），可触发政策比对对照公司政策库分析 |
| **`regulatory-policy-redraft`（政策修订红线）** → | 整改过程中如需修订内部政策，触发政策修订红线起草修订草案 |
| **`regulatory-customize`（个性化调整）** → | 用户可通过个性化调整：上报材料缓冲天数、字段抽取置信度阈值、各类别的默认负责人 |

---

## 配置依赖降级

| 配置项缺失 | 行为 |
|---|---|
| `document.extract_fields` 能力未配置 | 退化为纯文本输入模式（用户粘贴文本而非上传 PDF），其他流程不变 |
| `escalation_path` 未配置 | 重大动作确认环节降级为通用提示，不路由到具体角色 |
| 政策库索引未填写归口部门 | `inspection-task` 派不到 `task_owner`，标"未跟进"，由冷启动访谈流程引导用户填 |
| 关键截止日未识别（监管函件中文表述含糊） | **停下来问用户**，不擅自补 |

---

## 收尾决策树

按 `profile.md` 中 `## 输出` 的决策树收尾。**对监管下发函的特殊性**：

- 决策树的"选项 2 上报 / 会签"通常是高优先 —— 监管函件多数会涉及对外提交，需要会签链
- 决策树的"选项 4 观察等待"对监管函件**慎用** —— 监管截止日是硬刚性的，不响应有处罚后果

---

## 本技能不做的事

- **不**起草处罚决定的复议申请书 / 诉讼起诉状（这是律师代理工作的专业内容，本技能仅触发"建议启动外聘律师"的提示）
- **不**起草听证申请书 / 陈述申辩书（同上，建议外聘律师介入）
- **不**判定监管处罚 / 措施的合法性（这是法律意见，需律师出具）
- **不**自动提交上报材料（必须经法务负责人 + 首席合规官会签 + 法定代表人 / 法务联系人手工提交）
- **不**自动监控监管回函（与 `regulatory-reg-feed-watcher`（监管动态监测）协作 + 人工录入兜底，不替代秘书 / 收发室）
- **不**做监管沟通策略建议（如"要不要主动联系执法人员"等 —— 这是合规 / 公关策略，超出本技能范围）

详细 6 分法处置规则见 `references/letter-classification-rules.md`；`inspection-task` 模板见 `references/inspection-task-template.md`；上报材料模板见 `references/report-material-template.md`。