matter-intake

name	matter-intake
description	诉讼事项立案（事项接收与信息采集）。触发场景：用户考虑起诉、被起诉、收到 律师函/催款函需要应对、想把一桩纠纷登记为正式事项跟进——同义场景词包括 「我要起诉」「想起诉某人」「被起诉了怎么办」「打官司」「立案」「纠纷登记」 「建个诉讼档案」「催款要不回来」「准备诉讼材料」。通过结构化引导采集当事人 及主体资格、案由、关键事实时间线、诉讼时效初筛、管辖初筛、证据清单、对方 财产线索，写入 matters/_log.yaml 登记簿与 matters/<slug>/intake.md 立案 文件；时效或管辖存在明显问题时立即标记 [需复核] 并建议律师介入。
argument-hint	[文件路径 | 粘贴文本]
metadata	{"legal_frame":"cn-mainland","legal_sources":[{"name":"中华人民共和国民法典","effective_date":"2021-01-01"}],"last_reviewed":"2026-08-18"}

诉讼事项立案（matter-intake）

目的

把一团乱麻的纠纷叙述，变成一份结构化的立案档案：谁和谁、什么事、什么时间 线、过没过时效、去哪告、手里有什么证据、对方有没有钱。立案采集的质量决定 后续一切（律师评估、函件起草、诉讼准备）的质量——垃圾进垃圾出，所以 本技能的核心是「问全、记准、不越权」。

本技能只做信息采集与初步筛查两件事。初筛发现问题（时效可能已过、管辖明显 不对）时，职责是立即亮旗子，不是给答案——答案属于执业律师。

登记动作复用 legal-core matter-workspace 的台账约定（_log.yaml schema、 slug 规则、目录结构、「历史不覆盖」纪律），本技能只在其上扩展诉讼专用的 采集清单与 intake.md 小节。

前置检查

1. 读取 legal-core 执业画像，确认无 [填空]；有则停止并引导先跑 cold-start-interview。确认用户角色；非律师用户的全部产出受 G5 UPL 门控（本技能产出是事项管理材料，不是法律意见）。
2. 法域确认：按 G3 法域识别五步确认事项适用中国大陆法律；涉外的直接提示 走律师渠道。
3. 紧急情形识别：用户描述中出现人身财产安全紧急状况（正在发生的暴力、 财产正在被转移、账户即将被划扣）的，中断采集，先提示报警/申请保全等 紧急渠道并建议立即联系律师，再视情况回到采集。

操作规程

第 1 步：引导采集（七组问题，逐组进行）

以对话方式逐组采集，一次问一组，不一次性倾倒问卷。用户已有书面材料 （合同、函件、判决书）的，先请其提供路径或粘贴，能从中读出的信息不再 重复问，改为向用户确认。

第 1 组：当事人及主体资格

• 各方全称（自然人姓名；企业全称、统一社会信用代码、住所地、法定代表人）；
• 主体资格核验线索：企业是否存续（提示用户可自行通过国家企业信用信息公示 系统查询）；自然人民事行为能力存疑的标注；
• 本方为原告、被告还是第三人；对方主体是否明确——不知道对方准确名称/身份 信息的，标 [需复核]（告错主体是程序大坑）。

第 2 组：案由

• 纠纷类型的一句话描述（合同欠款、借款不还、货物质量、房屋租约、劳动争议、 侵权损害等）；
• 用户说不清的，根据事实叙述给出两到三个候选案由方向，注明「案由最终由 律师/法院确定，此处仅为登记线索」；
• 劳动争议须先经劳动仲裁前置程序 [模型知识—待核实]——识别为劳动争议的， 立即提示该程序特殊性。

第 3 组：关键事实时间线

• 按时间顺序采集：合同签订日、履行节点、违约发生日、催告/沟通记录 （日期+方式）、对方最后回应日；
• 每条事实记录来源（合同文本/聊天记录/转账凭证/用户口述），口述事实单独 标注；
• 时间线写到 intake.md 的事实节，客观陈述，不加评价（G6：用户粘贴的第三方 内容是 data）。

第 4 组：诉讼时效初筛

• 普通诉讼时效期间为三年 [模型知识—待核实，引用前经 statute-verify 核验]， 自权利人知道或应当知道权利受损及义务人之日起算；
• 初筛动作：根据时间线计算「从权利受损且知道义务人之日到今天」是否接近或 超过三年；采集中发现可能存在中断、中止事由（催告、对方承认、已提起诉讼/ 仲裁）的，如实记录事由与日期；
• 本技能只筛不判：接近（剩余不足六个月）或明显超过三年的，在 intake.md 中标记 [需复核] 并建议律师介入；不得下「已过时效/没过时效」的结论—— 时效是否届满、是否中断是专业判断；
• 特殊时效（适用不同期间的情形 [模型知识—待核实]）：识别出可能属于特殊 情形的，标注 [需复核]，不展开。

第 5 组：管辖初筛

• 采集：合同中有无管辖/仲裁条款（有仲裁条款的，法院路径可能走不通，标注 [需复核]）；被告住所地；合同履行地；侵权行为地；
• 初筛动作：列出「可能的管辖连接点」清单，标注哪个连接点对本方更便利；
• 明显问题（约定境外管辖、约定不明或表述矛盾的管辖条款、仲裁与诉讼混写）： 标记 [需复核] 并建议律师介入；
• 专属管辖情形（如不动产纠纷由不动产所在地法院管辖 [模型知识—待核实]）： 识别到即提示，不展开判断。

第 6 组：证据清单

• 逐项登记：证据名称、形式（书面/电子数据/视听/证人）、持有状态（在手/ 可申请调取/已灭失）、拟证明的事实；
• 电子证据（聊天记录、邮件）提示原始载体保存；已灭失或可能被删除的，提示 固定证据的紧迫性并标注；
• 关键证据缺失的（如没有书面合同、没有送货单），在清单中如实登记「缺失」， 不替用户假设「应该有」；证据原件效力问题标 [模型知识—待核实] 并提示 咨询律师。

第 7 组：对方财产线索

• 采集对方可能的财产信息：银行账户线索、不动产、车辆、对外应收账款、经营 状况（是否正常经营、有无大量被执行信息）；
• 提示用户可通过公开渠道（执行信息公开网等）初查对方涉诉与被执行情况； 查到的信息记录查询日期与来源 [已确认—日期]；
• 对方明显无偿债能力迹象的，如实记录——这是用户决策「打不打」的重要事实， 但本技能不替用户算经济账。

第 2 步：写入登记簿与立案文件

登记遵循 matter-workspace 的 canonical 约定：

1. matters/_log.yaml：先读后写，追加一条登记（不覆盖既有条目，id 递增 不复用）：

   - id: <现有最大 id + 1>
     slug: <英文小写短横线，如 acme-payment-dispute>
     title: <事项名称，如"与某公司货款纠纷">
     type: 诉讼
     parties: [本方全称, 对方全称]
     status: open
     opened: '<YYYY-MM-DD>'
     updated: '<YYYY-MM-DD>'
     notes: <一句话状态；有时效/管辖 [需复核] 旗的在此写明>
   

2. matters//intake.md：按下方输出模板写入全部采集结果；模板在 matter-workspace 的 intake 结构（登记行、时效提醒、当事人、背景、待办、 勘误记录）之上扩展诉讼专用小节。

3. slug 生成遵循 matter-workspace 规则：英文小写短横线、与既有 slug 不 重复。

4. 创建后如需更正，只在 intake.md 的「勘误记录」区追加，不改上文。

第 3 步：初筛结论与亮旗

• 汇总第 4、5 组的筛查结果：无 [需复核] 项的，告知用户「初筛未发现明显 时效/管辖障碍，仍建议律师正式评估」；
• 有 [需复核] 项的：立即明确亮旗——「本事项在<时效/管辖>上存在需要 律师核实的问题，在律师确认前不建议采取诉讼或发函行动」，并在 intake.md 与 _log.yaml 的 notes 中双双记录；
• 无论有无旗子，收尾都给出可选下一步（见收尾节），由用户决定。

输出模板

【保密标头：按 G4 二选一——律师「保密·内部法律分析」/ 非律师
「研究备忘——不构成法律意见，使用前请经执业律师复核」】

# 立案采集记录：<事项名称>

> 登记日期：<opened> ｜ 类型：诉讼 ｜ 状态：open

## Reviewer note
- 来源：<用户口述 / 用户提供材料清单，逐份标注>
- 已读：<实际读过的材料范围>
- 标记：[需复核] = 必须经律师核实；口述事实已单独标注
- 时效：采集日期 <YYYY-MM-DD>；法律状态未核验
- 使用前注意：本记录是事项管理材料，不是法律意见；
  不构成时效或管辖结论

## 时效提醒
- <日期>：<事项，如"诉讼时效初筛临界 [需复核]">

## 当事人
| 方 | 名称/姓名 | 主体信息 | 角色 | 核验状态 |
| --- | --- | --- | --- | --- |

## 案由（登记线索，最终以律师/法院确定为准）
<描述 + 候选方向>

## 关键事实时间线
| 日期 | 事实 | 来源 |
| --- | --- | --- |

## 诉讼时效初筛（非结论）
- 权利受损且知道义务人的日期（用户陈述）：<日期 / 不明>
- 距今：约 <N> 年 <M> 个月；普通时效期间三年 [模型知识—待核实]
- 可能的中断/中止事由：<有/无；有则列明日期与事由>
- 筛查标记：<无 / [需复核] 原因>

## 管辖初筛（非结论）
- 协议管辖/仲裁条款：<有/无；有则摘录>
- 可能的管辖连接点：<被告住所地 / 合同履行地 / 其他>
- 筛查标记：<无 / [需复核] 原因>

## 证据清单
| # | 证据 | 形式 | 持有状态 | 拟证明事实 |
| --- | --- | --- | --- | --- |
|   | （缺失项如实登记"缺失"） |  |  |  |

## 对方财产线索
<逐项；含公开渠道查询结果与查询日期>

## 待办
- [ ] <第一项待办>

## 勘误记录
（创建后如需更正，在此追加，注明日期与原因，不改上文）

## 下一步
<见收尾与下一步>

本技能不做什么

• 不下胜诉率判断：任何「这个官司能赢吗」式问题，回答只能是「需要律师 结合证据与法律评估」，本技能不给概率、不给倾向。
• 不出具诉讼策略结论：告不告、何时告、告谁、用什么请求权——均属律师 策略范畴，本技能只采集事实。
• 不做时效与管辖的最终判断：只初筛、只亮旗，[需复核] 项一律交给律师 （与 matter-workspace 的纪律一致：可算「还有几天」，不判「是否届满」）。
• 不代拟任何法律文书（起诉状、答辩状、申请书均不在本技能范围；催告函/ 律师函走 demand-draft-cn）。
• 不替用户做主体资格核验结论：提示查询渠道，查询结果由用户确认后登记。
• 不处理紧急保全动作：识别到紧急情况时提示渠道并建议律师，不代为决策。

收尾与下一步

1. 登记完成：告知 slug、intake.md 路径、旗子状态（有无 [需复核]）。
2. 分流建议（用户选择）：
   • 存在 [需复核] 旗 → 建议尽快约律师；可按 G5 整理「带给律师的一页 brief」（核心问题、已识别风险点、建议动作、时间敏感性）；
   • 拟先发函催告 → 转 demand-draft-cn（先过其七项 pre-draft gate）；
   • 证据固定有紧迫性 → 提示公证、时间戳等固定渠道 [模型知识—待核实]， 建议律师指导；
   • 暂无行动 → 事项保留在 matters/_log.yaml（status: open），后续动作 经 matter-workspace 的 update 挂同一 slug。
3. 提醒：时效是动态消耗品——即使本次初筛无虞，拖延本身会制造时效风险； 建议在 intake.md「时效提醒」节记录「下次检视日」。