client-instruction-schedule构建一份客户指示表（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、诉状、证人陈…
Independent GitHub snapshot · Automated classification · Original documentation governs
在文件密集的争议中，客户被开放式地要求"发表意见"时往往会僵住。本技能产出一份客户指示表：一张横版 Word 表格，借用 Scott Schedule 的纪律，但以通俗英语写给客户，每个争议问题一行，附具体且大多为封闭式的问题。它配有一封简短说明函，告诉客户如何完成。立场精确溯源到陈述、函件和证据页，以便日后从中起草面向法院的 Scott Schedule 时容易得多（客户的通俗英语答案仍需要转化为诉讼主张立场 — 指示表是一座采石场，而非转化器）。
本技能起草一份供事务律师审阅、修改和批准的工作文件。它不提供法律意见，未经人工审阅不得发送给客户，且它产出的每份草稿都带有说明此点的横幅。事务律师仍对指示表中每项立场、引用和问题的准确性负责。另有四项限制：
英格兰法律（英格兰与威尔士）。英式拼写。货币用 £。客户必须阅读或完成的任何内容中不得出现 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 的基础。其他地区的执业者可以调整语域，但通俗英语的纪律在任何地方都是要点。
pdftoppm 200dpi + tesseract，页面并行）。在依赖之前，对照页面图像核验 OCR 出的数字和引文。md5sum）以发现重复项。列出客户输入 — 答案、回忆或文件 — 确实需要的每个问题。来源：双方证人陈述（逐段）、律师意见（尤其是"we need instructions on…"段落）、致客户且未获答复的函件，以及客户自身的部分回应。排除：
等待客户的决策点（如"您是否同意委托会计师？"）计为行；宽泛的策略决定属于说明函或单独的意见，而非指示表。
此工作流最危险的失败是静默遗漏问题：审阅事务律师看到一份光鲜的表格，却无从看出什么被丢弃了。因此，起草前产出一份来源到行映射图：每个提出事实争议的证人陈述段落、律师意见中每段"we need instructions on…"、每封函件中每个未答复的请求，都必须以 (a) 指示表行或 (b) "已考虑并排除的问题"清单条目（各附一行理由）出现。该排除清单要进入指示表文档本身，作为表格之后的律师说明附录（高亮约定同步骤 6），而不仅仅进入聊天汇报 — 被审阅的工件必须自带其遗漏内容的说明。
对每个问题，检查即将索取的材料是否已存在于文件夹中。绝不向客户索取律所已持有的文件 — 相反，请他们识别其中的相关条目（如"银行对账单已在我们手中（证据 X）— 请指出匹配的条目"）。"我们已持有的证据"列是执行机制：诚实地填写它会暴露任何懒惰的索取。
横版 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"行、一行斜体说明（高优先级行优先），然后是任何高亮的事务律师说明。
优先级指导： 高 = 触及核心争议、时效敏感，或阻塞下一步的决定。中 = 重要但可随后。低 = 背景或已有充分记录。
[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 页的页脚。单独的纵向文档，同字体，以名字直呼客户的信件形式。内容：指示表是什么；每行如何运作；编号的操作指南清单（高优先级行优先；在哪里写答案和列文件；带一句解释的封闭式答案；"cannot recall"是恰当的；分阶段返回没问题）；时间表用 [ ] 由事务律师设定；省钱的鼓励；署名。同样的草稿横幅。语气平静 — 客户已受聘但不知所措。
docx 包为高亮 run 发出无效的 <w:highlightCs> 元素 — 从 word/document.xml 中剥离它（解压 → sed 's|<w:highlightCs w:val="yellow"/>||g' → 重新压缩），否则模式验证会失败。soffice → pdftoppm）：检查列标题没有严重换行、编号正常渲染、高亮可见。<case>-client-instruction-schedule-draft-NN-YYYY-MM-DD.docx 和 <case>-client-covering-note-draft-NN-YYYY-MM-DD.docx（ISO 日期 = 起草日期），保存到事项的草稿区 — 绝不保存到任何存放定稿或已归档文件的文件夹。按律所自身的命名和归档约定调整。最后列出：发现的问题（按优先级分组，附每项高标记的推理）；覆盖图，包括每个已考虑并排除的问题及原因；文件中被引用但文件夹中缺失的文件；每份文件的识别依据；每处被标记的不一致；以及给事务律师的未决问题。
references/schedule-data-example.js — 来自一个虚构争议（Frayne v Kestrel，一个虚构的谷仓改建案件）的示例行数据，展示每列所需的语域和溯源风格。references/build-schedule-example.js — 指示表文档的完整可运行构建脚本。本技能供法律专业人士使用。它不提供法律意见，其产出是在任何使用前须经合格事务律师审阅的草稿。作者对依赖未经审阅产出不承担任何责任。