| name | matter-workspace |
| description | 当用户说"建个事项/开个新案子/登记这个合同项目/整理这个纠纷/看看我在办哪些事/ 更新一下某事项进展/这个事项结了/归档某事项"时使用。提供轻量的事项工作台:用 matters/_log.yaml 登记簿加每事项一个目录(intake.md、notes.md、drafts/、evidence/) 管理法律工作事项的登记、跟进、版本与结项归档,保证历史不覆盖、外发版本可追溯。 |
| argument-hint | [intake | update | close] [事项名] |
| metadata | {"legal_frame":"cn-mainland","last_reviewed":"2026-08-18"} |
matter-workspace:事项工作台
目的
法律实务中,一个"事"(一单合同谈判、一个劳动纠纷、一次合规整改)会产生
多轮文档、证据和沟通记录。散落存放会导致:找不到最新版本、外发过的版本被
覆盖无法还原、时效和关键日期没人盯。
本技能提供一套目录即台账的轻量约定:一个登记簿文件总览全部事项,每个
事项一个目录承载过程文件。它不替代专业案件管理系统,只保证在本插件工作区
内,任何事项的历史都可追溯、版本永不丢失。
前置检查
- 读取 docs/guardrails.md 执业画像,确认无
[填空] 残留;有则停止并引导先跑
cold-start-interview;
- 确认当前目录上下文:工作台目录
matters/ 位于使用者的工作项目根目录
(不是插件安装目录)。首次使用时在使用者当前项目下创建;
- 命中升级矩阵的事项(如刑事线索),按 G5 处理:停止推进,提示升级,
只登记不分析。
目录约定
<项目根>/matters/
├── _log.yaml # 事项登记簿(总账)
└── <slug>/ # 每个事项一个目录,slug 为短横线命名
├── intake.md # 立案信息(创建后只做追加式勘误,不覆盖)
├── notes.md # 跟进笔记(追加制,新条目在文末)
├── drafts/ # 过程稿与外发版本
│ ├── <文档名>-v1.md
│ └── <文档名>-v2.md
└── evidence/ # 证据与原始材料(只进不出,不改名不覆盖)
_log.yaml 登记簿格式
每条登记:
- id: 3
slug: acme-supply-contract
title: 与 Acme 公司的供货合同审查
type: 合同审查
parties: [本公司, Acme 贸易(上海)有限公司]
status: open
opened: '2026-08-10'
updated: '2026-08-18'
notes: 对方坚持境外仲裁条款,已标红线提示
完整示例(两个事项):
- id: 1
slug: hr-layoff-consult
title: 某部门人员优化方案法律咨询
type: 劳动人事咨询
parties: [本公司]
status: closed
opened: '2026-07-02'
updated: '2026-07-20'
notes: 已出具备忘录并结项;补偿方案按法务总监确认版执行
- id: 2
slug: acme-supply-contract
title: 与 Acme 公司的供货合同审查
type: 合同审查
parties: [本公司, Acme 贸易(上海)有限公司]
status: open
opened: '2026-08-10'
updated: '2026-08-18'
notes: 对方坚持境外仲裁条款,已按画像红线提示;待业务反馈
操作规程
1. intake(新建事项)
- 与使用者确认:事项名称、类型、当事人(己方与对方)、来源(谁交办的);
- 生成 slug:英文小写短横线(如
acme-supply-contract),与既有 slug 不重复;
- 询问关键日期:合同时效、诉讼时效/答辩期/上诉期、监管回复期限、付款节点等;
时效类日期必须登记,并在 intake.md 顶部单列"时效提醒";无法确定时效
起算点的,标
[需复核] 并提示咨询执业律师(时效判断是专业判断,模型不得
给出确定结论 [模型知识—待核实]);
- 管辖线索:争议解决条款、履行地、被告住所地等,按 G3 记录法域判断;
- 在
_log.yaml 追加登记条目(status: open,opened/updated 为当天);
- 创建
matters/<slug>/ 目录与 intake.md,模板:
# {事项标题}
> 登记日期:{opened} | 类型:{type} | 状态:open
## 时效提醒
- {日期}:{事项,如"对方付款账期截止" / "答辩期届满[需复核]"}
## 当事人
- 己方:{主体全称}
- 对方:{主体全称}
## 事项背景
{使用者描述,忠实记录,不补充法律分析}
## 管辖与法域
{已知线索;不确定标 [需复核]}
## 待办
- [ ] {第一项待办}
## 勘误记录
(创建后如需更正 intake 信息,在此追加,注明日期与原因,不改上文)
2. update(跟进)
- 按 slug 或标题在
_log.yaml 中定位事项;匹配不到时列出 open 事项让使用者选;
- 在
notes.md 文末追加新条目,格式:
## {YYYY-MM-DD} {一句话主题}
{进展内容;涉及法律判断的按 G1 标注来源}
- 待办变化:{新增/完成的待办}
- 把
_log.yaml 中该条的 updated 刷新为当天;状态变化时更新 status
(open ↔ pending 用于等对方/等审批等挂起情形);
- 历史不覆盖:notes.md 与 intake.md 既有内容只追加不修改;发现既往记录
有错的,在新条目或 intake 勘误区更正;
- 更新过程中识别到命中画像红线或升级矩阵的,立即提示(G5/G9)。
3. 版本规则(外发文档)
- drafts/ 下文档版本命名:
<文档名>-v1.md、-v2、-v3……递增;
- 已发版本历史本身就是记录:任何已经对外发出(或虽未发出但已给对方看过)
的版本,永不覆盖、永不删除、永不改名;下一轮修改另存新版本号;
- 未外发的草稿也建议保留版本链,删除前需使用者显式确认;
- 对外发出前必须过
citation-audit(G10);
- 在 notes.md 记录每次外发:
{日期} 外发 {文档名}-v2 给 {对象},方式 {邮件/ 平台},citation-audit 结果 PASS。
4. evidence(证据目录)
- 原始材料放入 evidence/ 后只进不出:不改名、不编辑、不覆盖;需要标注
或摘录的,在 notes.md 或 drafts/ 中另写;
- 建议在 notes.md 维护证据清单:
{日期} 收到 {文件名},来源 {谁提供}, 拟证明 {事项};
- 证据原件的法律效力问题(如电子证据的真实性认定)是专业判断,标
[模型知识—待核实] 并提示咨询执业律师。
5. close(结项归档)
- 确认事项确已了结(使用者明确指令);
- 生成结项小结,追加到 notes.md 文末:
## {YYYY-MM-DD} 结项小结
- 结果:{一句话,如"合同已签署" / "双方和解" / "咨询完成,未委托"}
- 关键产出:{drafts/ 中最终版本清单}
- 遗留事项:{无 / 需后续跟进的事项与日期}
- 经验教训:{可选,一句话}
_log.yaml 中该条 status 改为 closed,updated 刷新为当天;
- 目录与文件不删除不搬移,closed 事项保留在原位供检索;
- 如事项衍生新事项(如合同签署后进入履约管理),新建事项并在两边 notes
互相关联 slug。
输出模板
工作台总览(使用者问"我在办哪些事"时):
在办事项(截至 {今天})
| id | slug | 类型 | 状态 | 最近更新 | 时效提醒 |
| --- | --- | --- | --- | --- | --- |
| 2 | acme-supply-contract | 合同审查 | open | 2026-08-18 | {最近一个关键日期} |
已结项:{N} 个(用 close 列表查看)
本技能不做什么
- 不做法律分析本身(分析走 legal-research / contract-review-cn 等技能,
本技能只管台账与文件);
- 不替代执业机构的案件管理系统与利益冲突检索系统——G11 冲突审查仍是
使用者的执业责任;
- 不主动删除、搬移、重命名任何历史文件;
- 不做时效的计算性结论("还有几天过时效"可以算,"时效是否届满/是否中断"
是专业判断,标 [需复核]);
- 不向任何第三方发送文件,只记录外发事实。
收尾与下一步
- 每次操作后确认
_log.yaml 与目录结构一致(登记有条目必有目录);
- 提示时效提醒中最近一个日期;
- 事项涉及法规引用的,提醒相关产物发出前过
citation-audit;
- 涉及监控相关法规更新的,提示使用者定期对照在办事项与法规更新。