视觉画布设计
canvas-design
基于设计原则创作静态视觉作品，用于海报与品牌图形。
探索技能
文档与办公 · SKILL.md
client-instruction-schedule
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…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
技能说明
GitHubname: 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（
pdftoppm200dpi +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. 交付前核验
- 如有验证器可用，对照 OOXML 模式验证两份文件；至少打开它们检查渲染。注意：
docx包为高亮 run 发出无效的<w:highlightCs>元素 — 从word/document.xml中剥离它（解压 →sed 's|<w:highlightCs w:val="yellow"/>||g'→ 重新压缩），否则模式验证会失败。 - 转换为 PDF 并查看每一页（
soffice→pdftoppm）：检查列标题没有严重换行、编号正常渲染、高亮可见。 - 程序化确认原生编号（存在 numPr，单元格文本中无手打前导数字）。
- 对每一行，重读所引的段落或页面，确认所概括的立场是公平的转述 — 而不仅仅是所引文件存在。逐字对照来源核验每个数字、日期和引文（来源经 OCR 时对照页面图像）。
- 重新检查覆盖图（步骤 3）：确认每个映射的来源条目都作为行或列出的排除项出现，且排除附录存在于文档中。
- 检查优先级：确认每个时效敏感或阻塞决定的问题都标记为高，并在汇报中记录优先级推理。
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— 指示表文档的完整可运行构建脚本。
免责声明
本技能供法律专业人士使用。它不提供法律意见，其产出是在任何使用前须经合格事务律师审阅的草稿。作者对依赖未经审阅产出不承担任何责任。