Client Instruction Schedule

---
name: client-instruction-schedule
description: 构建一份客户指示表（client instruction schedule）— 一份通俗英语、Scott Schedule 风格的 Word 表格，逐项收集陷入困境的客户的证据和指示，并附一页式说明函。每当用户要求"client instruction schedule"、"instruction schedule"、"client questionnaire"、"schedule of questions for the client"、"get instructions from the client on the papers"，或表示客户不知所措、需要将案件分解为可管理的问题时使用。当被要求将案件文件转化为对客户输入的结构化请求时也触发。不要用于面向法院的 Scott Schedules、诉状、证人陈述或意见函 — 本技能只产出面向客户的工作文件。输出始终是供事务律师审阅的 .docx 草稿，绝非最终文件。
license: Apache-2.0
metadata:
  author: Serhan Handani
  jurisdiction: UK (England & Wales)
  category: litigation
  language: en
---

# 客户指示表（Client Instruction Schedule）

## 目的

在文件密集的争议中，客户被开放式地要求"发表意见"时往往会僵住。本技能产出一份**客户指示表**：一张横版 Word 表格，借用 Scott Schedule 的纪律，但以通俗英语*写给客户*，每个争议问题一行，附具体且大多为封闭式的问题。它配有一封简短说明函，告诉客户如何完成。立场精确溯源到陈述、函件和证据页，以便日后从中起草面向法院的 Scott Schedule 时容易得多（客户的通俗英语答案仍需要转化为诉讼主张立场 — 指示表是一座采石场，而非转化器）。

## 重要限制

本技能起草一份供事务律师审阅、修改和批准的工作文件。它不提供法律意见，未经人工审阅不得发送给客户，且它产出的每份草稿都带有说明此点的横幅。事务律师仍对指示表中每项立场、引用和问题的准确性负责。另有四项限制：

- **保密优先。** 技能读取整个诉讼文件夹，包括律师意见。运行前，检查律所的 AI 和保密政策是否允许将这些文件加载到所使用的工具中，并在政策要求时对材料进行匿名化或排除。
- **证人证据（PD 57AC）。** 指示表大多使用封闭式问题，并在询问客户回忆之前向其展示对方立场。如果任何答案日后可能进入庭审证人陈述，事务律师应在发送前考虑《实务指引 57AC》（Practice Direction 57AC）：在有争议的重大事项上向客户提出对方说法，可能被批评为诱导。对受争议的回忆问题，考虑泛化或移除"对方立场"列，并保留向客户展示了哪些文件的记录。
- **客户适格性。** 与主管事务律师确认书面指示表适合该客户。一些不知所措的客户是弱势客户，对他们而言这种格式是错误的工具，电话会谈才是正确的。
- **残余风险。** 下文核验步骤降低但并未消除虚构引用、不公平转述和静默遗漏问题的风险。覆盖图（步骤 3）的存在是为了让审阅事务律师能看到遗漏了什么，而不仅仅是放入了什么。

## 法域与语域

英格兰法律（英格兰与威尔士）。英式拼写。货币用 £。**客户必须阅读或完成的任何内容中不得出现 CPR 术语或法定引注** — 用"the court's disclosure order"，而非"the Order of ICCJ [X] under CPR 3.1(7)"。文件引用（如"Mr [X]'s 2nd statement, para 22"）没问题：它们正是日后转换为 Scott Schedule 的基础。其他地区的执业者可以调整语域，但通俗英语的纪律在任何地方都是要点。

## 工作流

### 1. 阅读所有内容，按内容识别

- 阅读案件文件夹中的每份文件。**按内容识别文件，绝不按文件名** — 文件名会骗人（盖错证人首字母的证据册、证明错误证据名称的封面页）。基于内容的识别也可能出错：在汇报（步骤 10）中记录每次识别的依据，以便事务律师检查。
- 注明任何**在文件中被引用但文件夹中缺失**的文件（一份提到某证据但未提供的陈述、提到附件的函件）。在汇报中列出这些 — 文件夹不能被假定完整。
- 无文本层的扫描版 PDF 必须 OCR（`pdftoppm` 200dpi + `tesseract`，页面并行）。在依赖之前，对照页面图像核验 OCR 出的数字和引文。
- 读取前对文件取哈希（`md5sum`）以发现重复项。
- 注明文件中发现的每处内部不一致（日期、证据标签、误引数字）— 这些成为高亮的事务律师说明（步骤 6），而非静默更正。

### 2. 提取争议问题

列出客户输入 — 答案、回忆或文件 — 确实需要的每个问题。来源：双方证人陈述（逐段）、律师意见（尤其是"we need instructions on…"段落）、致客户且未获答复的函件，以及客户自身的部分回应。排除：

- 程序和法理论证（无需客户输入）；
- 成本和策略要点；
- 文件中已回答的任何内容 — 但仅当存在**完整**答案且可引用时才排除；在排除清单（步骤 3）中引用它。

等待客户的决策点（如"您是否同意委托会计师？"）计为行；宽泛的策略决定属于说明函或单独的意见，而非指示表。

### 3. 构建覆盖图（来源到行）

此工作流最危险的失败是静默遗漏问题：审阅事务律师看到一份光鲜的表格，却无从看出什么被丢弃了。因此，起草前产出一份**来源到行映射图**：每个提出事实争议的证人陈述段落、律师意见中每段"we need instructions on…"、每封函件中每个未答复的请求，都必须以 (a) 指示表行或 (b) "已考虑并排除的问题"清单条目（各附一行理由）出现。该排除清单**要进入指示表文档本身**，作为表格之后的律师说明附录（高亮约定同步骤 6），而不仅仅进入聊天汇报 — 被审阅的工件必须自带其遗漏内容的说明。

### 4. 对照已持有内容交叉检查

对每个问题，检查即将索取的材料是否已存在于文件夹中。**绝不向客户索取律所已持有的文件** — 相反，请他们*识别其中的相关条目*（如"银行对账单已在我们手中（证据 X）— 请指出匹配的条目"）。"我们已持有的证据"列是执行机制：诚实地填写它会暴露任何懒惰的索取。

### 5. 构建指示表（.docx）

横版 A4，Times New Roman 12，使用 `docx` npm 包生成（经 docx@9.6.1 测试；完整可运行脚本参见 `references/build-schedule-example.js`）。单张表格，标题行重复（`tableHeader: true`），**问题编号使用 Word 原生自动编号（带 `LevelFormat.DECIMAL` 的 `numbering` 配置）— 绝不手打数字**。`docx` 包关键点：在表格上设置 `columnWidths` 并在每个单元格上设置 `width`，两者都用 DXA；底纹用 `ShadingType.CLEAR`（绝不用 `SOLID`）；横版时传纵向 A4 尺寸加 `orientation: PageOrientation.LANDSCAPE`。八列（DXA 宽度合计 ≤15398，对应 0.5" 边距）：

| # | 列 | 内容规则 |
|---|--------|---------------|
| 1 | 问题（Issue） | 自动编号 + 粗体短标签（3–8 个词） |
| 2 | 我方立场（Our position） | 1–2 句通俗英语 |
| 3 | 对方立场（The other side's position） | 同样简短，但精确溯源：陈述 + 段落、函件 + 日期、证据 + 盖章页码 |
| 4 | 我们已持有的证据（Evidence we already hold） | 已入档的所有相关内容文件引用 |
| 5 | 我们需要您提供什么（What we need from you） | 具体、实在、大多为封闭式的问题（"您是否出席了 [date] 的会议？还有谁在场？"）。绝不用"please comment"。告诉客户"cannot recall"（记不清）是可接受的答案 |
| 6 | 您的回应（Your response） | 空白，空间充裕 |
| 7 | 您要发送的文件（Documents you are sending） | 空白 — 客户逐行列出附件 |
| 8 | 优先级（Priority） | 高 / 中 / 低，让客户可以分诊而非僵住 |

表格上方：标题、"Draft NN"行、一行斜体说明（高优先级行优先），然后是任何高亮的事务律师说明。

**优先级指导：** 高 = 触及核心争议、时效敏感，或阻塞下一步的决定。中 = 重要但可随后。低 = 背景或已有充分记录。

### 6. 准确性约定

- 凡文件中任何立场、日期、金额或归属不清楚：插入 `[UNCLEAR — PLEASE REVIEW]` — 绝不猜测，绝不虚构事实、引用或引文。其他标记：`[DATE TBC]`、`[AMOUNT TO BE CONFIRMED]`、`[SOLICITOR TO VERIFY]`。
- 来源文件中的不一致（相互冲突的陈述日期、标签错误的证据）放在**表格上方粗体、黄色高亮的段落**中，前缀 `[SOLICITOR TO VERIFY — DELETE BEFORE SENDING TO CLIENT: …]`。
- 每页都带页眉横幅：`AI-ASSISTED DRAFT — FOR SOLICITOR REVIEW — NOT YET APPROVED OR SENT`，以及含客户姓名、草稿编号、日期和第 X 页共 Y 页的页脚。

### 7. 说明函（.docx，一页）

单独的纵向文档，同字体，以名字直呼客户的信件形式。内容：指示表是什么；每行如何运作；编号的操作指南清单（高优先级行优先；在哪里写答案和列文件；带一句解释的封闭式答案；"cannot recall"是恰当的；分阶段返回没问题）；时间表用 `[    ]` 由事务律师设定；省钱的鼓励；署名。同样的草稿横幅。语气平静 — 客户已受聘但不知所措。

### 8. 交付前核验

1. 如有验证器可用，对照 OOXML 模式验证两份文件；至少打开它们检查渲染。注意：`docx` 包为高亮 run 发出无效的 `<w:highlightCs>` 元素 — 从 `word/document.xml` 中剥离它（解压 → `sed 's|<w:highlightCs w:val="yellow"/>||g'` → 重新压缩），否则模式验证会失败。
2. 转换为 PDF 并**查看每一页**（`soffice` → `pdftoppm`）：检查列标题没有严重换行、编号正常渲染、高亮可见。
3. 程序化确认原生编号（存在 numPr，单元格文本中无手打前导数字）。
4. 对每一行，**重读所引的段落或页面**，确认所概括的立场是公平的转述 — 而不仅仅是所引文件存在。逐字对照来源核验每个数字、日期和引文（来源经 OCR 时对照页面图像）。
5. 重新检查覆盖图（步骤 3）：确认每个映射的来源条目都作为行或列出的排除项出现，且排除附录存在于文档中。
6. 检查优先级：确认每个时效敏感或阻塞决定的问题都标记为高，并在汇报中记录优先级推理。

### 9. 保存与命名

- 建议约定：`<case>-client-instruction-schedule-draft-NN-YYYY-MM-DD.docx` 和 `<case>-client-covering-note-draft-NN-YYYY-MM-DD.docx`（ISO 日期 = 起草日期），保存到事项的草稿区 — 绝不保存到任何存放定稿或已归档文件的文件夹。按律所自身的命名和归档约定调整。
- 如果律所保留一份供人工填写的空白先例版（说明函页后接指示表），该先例不必带 AI 草稿横幅；AI 生成的草稿必须始终携带上述横幅和律师说明。

### 10. 汇报

最后列出：发现的问题（按优先级分组，附每项高标记的推理）；覆盖图，包括每个已考虑并排除的问题及原因；文件中被引用但文件夹中缺失的文件；每份文件的识别依据；每处被标记的不一致；以及给事务律师的未决问题。

## 参考文件

- `references/schedule-data-example.js` — 来自一个**虚构**争议（Frayne v Kestrel，一个虚构的谷仓改建案件）的示例行数据，展示每列所需的语域和溯源风格。
- `references/build-schedule-example.js` — 指示表文档的完整可运行构建脚本。

## 免责声明

本技能供法律专业人士使用。它不提供法律意见，其产出是在任何使用前须经合格事务律师审阅的草稿。作者对依赖未经审阅产出不承担任何责任。