起诉状要点（complaint-outline）

目的

起诉状是诉讼的起点文件：请求写宽了浪费诉讼费与举证精力，写窄了漏掉保护； 事实写错了是自证其误；管辖写错了可能被移送、拖延甚至不予立案。起诉状的 质量，一半取决于动笔之前的整理功夫。

本技能做「动笔之前」的那一半：把 matter-intake 采集的立案信息整理成 一份起诉状要点文件——当事人怎么列、请求怎么写、事实怎么排、管辖 怎么论证、每项请求靠什么证据。它的读者是执业律师（或经律师复核的使用者 本人），用途是供律师据此成稿。

三条铁律：

1. 本技能输出要点文件，不是起诉状成稿——成稿、定稿与提交属于执业 律师；非律师使用者向法院提交任何文件前必须经执业律师复核（G5 UPL 门控），该提示不得省略、不得弱化；
2. 法条一律 CITE:__ 占位（G10）——民事诉讼法及其司法解释的具体 条文号、表述凡未经 statute-verify 核验，标 [模型知识—待核实，引用前经 statute-verify 核验]，不以模型记忆填实；
3. 七项 gate 不逐项确认就停止——沿用 demand-draft-cn 的 pre-draft gate 纪律并做起诉场景变体（见第 6 步），「都差不多先写吧」不接受。

前置检查

1. 读取 legal-core 执业画像，确认无 [填空]；有则停止并引导先跑 cold-start-interview。确认用户角色，确定 G4 保密标头档位；画像未 完成时按非律师档处理（更保守）。
2. 输入定位：参数为 matter slug 的，先读 matters/_log.yaml 定位， 再读 matters/<slug>/intake.md 与该事项 evidence/ 目录索引；匹配不到 slug 时列出 open 事项让用户选。参数为案情描述的，提示「未走 matter-intake 建档，信息未经结构化采集」，建议先建档；用户坚持的， 允许继续，但在 reviewer note 中记录「无 intake 档案」。
3. 旗子检查：intake.md 中时效或管辖带 [需复核] 旗的，停止， 提示先由律师核该旗——在时效、管辖存疑时推进起诉状要点，轻则返工， 重则程序事故。用户明确知悉仍要求继续的，可以继续，但要点文件相应 章节整体标 需复核。
4. 法域确认：按 G3 默认锚定 cn-mainland；识别到涉外因素的，显式声明 法域判断并提示走律师渠道。
5. 衔接检查：是否已有 evidence-list.md——有则引用其证据编号；无则 在第 5 步提示补做，证据编号体系先按本技能约定（E001…）占位，后续 与 evidence-list 对齐。

操作规程

第 1 步：当事人主体信息核对

逐方核对并输出「当事人信息核对表」，缺项如实列「缺失」，不替用户假设：

• 自然人：姓名、性别、出生日期、民族、住所、联系方式、公民身份 号码——起诉状当事人栏目的具体要求以受理法院要求与司法解释为准 模型知识—待核实，引用前经 statute-verify 核验；以身份证记载为准， 口头提供的姓名用字请用户逐字确认；
• 法人：名称（与营业执照一致的全称）、住所、统一社会信用代码、 法定代表人姓名及职务；提示用户通过国家企业信用信息公示系统核验 存续状态与最新登记信息，核验结果记查询日期 已确认—日期；
• 其他组织（非法人组织）：名称、住所、主要负责人；主体类型存疑的 标 需复核；
• 一致性核对：当事人与合同签约方、函件往来主体、付款主体是否一致 （告错主体是程序大坑，与 matter-intake 的纪律一致）；主体发生更名、 合并分立、注销线索的，标 需复核 并建议律师处理承继问题；
• 共同原告/共同被告/第三人的可能性：只列线索（如共同借款人、保证人、 发包链条），列与不列是诉讼策略，留给律师判断。

第 2 步：诉讼请求设计

逐项设计诉讼请求，每项按四个标准检验：

1. 具体：金额精确到分（或写明计算方式），行为请求写明行为内容与 履行期限；「赔偿损失若干」式的概括请求不合格；
2. 可执行：想象判决主文照抄该项能否直接执行——不能的，改写；
3. 有出处：每项请求对应请求权基础（合同约定条款 + 法条 CITE:__ 占位），没有依据的请求不进要点；
4. 有证据：每项请求标注支撑强度——证据齐备 🟢 / 证据有缺口 🟡 / 无证据支撑 🔴（与第 5 步对应表联动，🔴 项必须向用户明示）。

金钱类请求的专项核对：

• 本金与利息/违约金分列，不混写；
• 利息计算起点：应付款日、催告到达日、起诉之日——不同起点利益 差异可能很大，列出候选起点与对应期间，请用户与律师确认；利率标准 （约定利率、全国银行间同业拆借中心贷款市场报价利率等 模型知识—待核实）同样列候选不定案；
• 诉讼费承担：提示惯例请求写法（由被告负担）模型知识—待核实；
• 请求过宽的反提示：诉讼费按标的计收、举证负担随请求加重；请求遗漏 的亮旗：漏掉的请求一审不审，漏请求 = 漏保护 模型知识—待核实。

第 3 步：事实与理由组织

• 把 intake 时间线改写为「要件对应」结构：每项诉讼请求拆出构成 要件（以合同欠款为例：合同成立 → 己方已履行 → 对方到期未付 → 欠款金额），每个要件配对应事实与证据编号；
• 事实部分只写有出处的事实（沿用 Gate ① 纪律）；口述事实以「据我方 记录」限定，不写成不容置疑的断言；
• 理由部分的法条引用一律 CITE:__ 占位，由律师经 statute-verify 核验后填实；
• 语气执行 Gate ⑤ 标准：客观克制，不评价对方动机，不写无法证明的 指控，零感叹号。

第 4 步：管辖依据论证

1. 先查约定：合同争议解决条款——约定仲裁的立即停止，提示 法院路径可能走不通（与 matter-intake 管辖初筛纪律一致），建议律师 评估；约定管辖法院的，核对该约定与争议连接点的有效性线索（约定 须与争议有实际联系等 模型知识—待核实，引用前经 statute-verify 核验），存疑标 需复核；
2. 无法定约定或约定存疑的：列法定管辖连接点——被告住所地、合同 履行地、侵权行为地等 模型知识—待核实，逐个写出本案对应事实， 依据条文保持 CITE:__ 占位；
3. 专属管辖识别：不动产纠纷等专属管辖情形 模型知识—待核实， 识别到即提示，不展开判断；
4. 产出表述为「建议管辖法院 + 依据要点」，不定案——管辖的最终 判断属于律师，受理决定属于法院；level 管辖（基层/中级）线索一并 列出 模型知识—待核实。

第 5 步：证据与诉请对应表

建立三列映射表：诉讼请求 ← 待证事实 ← 证据编号（E001…，与 evidence-list 同一编号体系）：

• 已有 evidence-list.md 的，直接引用其编号与缺口结论；
• 未建的，提示转 evidence-list 补齐，本表先用 intake 证据节登记；
• 有请求无证据的行标 🔴，逐项向用户明示；证据形式瑕疵（无原件、 电子数据未固定）标 🟡；齐备标 🟢；
• 本表既是起诉状附件证据清单的骨架，也是律师评估诉讼基础的工作 底稿——🔴 行不处理，律师无法对该请求给出正面评估。

第 6 步：七项 pre-draft gate（起诉场景变体）

沿用 demand-draft-cn 七项 gate 的纪律——逐项出示、逐项得到明确 确认、逐项记录；任何一项被跳过或含糊，停止生成。起诉场景变体：

• Gate ① 事实准确性 → 事实-证据一一对应：起诉状中每个事实陈述 都必须能在第 5 步对应表中找到证据编号；找不到的，删事实或补证据， 二选一，请用户定；
• Gate ② 承认风险：事实与理由部分不得构成本方不利承认；对己方 履行情况的描述限定在与请求直接相关且属实的最小范围；
• Gate ③ 时效影响：起诉与时效的关系（提起诉讼是时效中断事由之 一 模型知识—待核实，引用前经 statute-verify 核验）；intake 有 时效旗的按前置检查第 3 条处理；
• Gate ④ 管辖与主体资格：第 1 步核对表与第 4 步管辖要点逐项 确认，重点是主体全称与受理法院；
• Gate ⑤ 语气：全篇客观克制，零感叹号；
• Gate ⑥ 保密过滤 → 信息分层：要点文件是内部材料，不外发；提示 用户与律师：成稿起诉状会依法送达对方，哪些细节「上法庭再展开」由 律师把握，本技能不做策略裁剪结论；
• Gate ⑦ 提交方式与留痕 → 立案渠道：现场立案、网上立案等渠道 与材料份数要求以受理法院为准 模型知识—待核实；本技能只列通用 提示，不替用户启动任何提交动作（G5 动作闸门）。

第 7 步：生成 complaint-outline.md

• 存放：已建事项的存入 matters/<slug>/drafts/complaint-outline-v1.md， 版本纪律与 matter-workspace 一致——修改出新版（-v2、-v3…），永不 覆盖；未建事项的存当前工作目录，reviewer note 记录「未建事项」；
• 头部：G4 保密标头（第一行，先于标题）+ reviewer note 五行块；
• 文末：汇总全部 需复核 清单（G8）；gate 确认记录随附（内部材料， 不进入任何外发文本）。

输出模板

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

# 起诉状要点：<事项名称>（v<N>，供律师成稿，非成稿）

## Reviewer note
- 来源：matters/<slug>/intake.md；<用户补充材料清单，逐份标注来源>
- 已读：<实际读过的材料范围；未读部分如实写明>
- 标记：🟢/🟡/🔴 = 证据支撑强度；[需复核] = 必须经律师核实；
  [CITE:__] = 法条占位，经 statute-verify 核验后填实
- 时效：法律状态核查日期 <YYYY-MM-DD 或「未核验」>
- 使用前注意：本文件是供律师成稿的内部要点，不是起诉状；
  非律师使用者向法院提交前必须经执业律师复核（G5）

## 一、当事人信息核对表
| 方 | 类型 | 名称/姓名 | 主体信息要点 | 核验状态 |
| --- | --- | --- | --- | --- |
| 原告 | <自然人/法人/其他组织> | <全称> | <住所/信用代码/法定代表人等> | <已核验[已确认—日期] / 缺失 / [需复核]> |
| 被告 | | | | |

## 二、诉讼请求（设计稿）
| # | 请求内容（具体、可执行） | 请求权基础 | 支撑强度 |
| --- | --- | --- | --- |
| 1 | <如：判令被告支付货款本金 ¥___> | 合同第_条 + [CITE:__] | 🟢/🟡/🔴 |
| 2 | <如：判令被告支付逾期利息，以¥___为基数，按___标准，自<起点候选>起算至实际清偿日> | [CITE:__] | |
| 3 | 诉讼费由被告负担 [模型知识—待核实] | [CITE:__] | — |

## 三、事实与理由要点（要件对应）
<按请求逐项拆要件：要件 → 对应事实（带时间线日期与出处）→ 证据编号>

## 四、管辖依据要点
- 协议管辖/仲裁条款：<有/无；有则摘录与有效性线索>
- 法定连接点：<被告住所地/合同履行地/…，本案对应事实>
- 建议管辖法院与依据：[CITE:__]（最终由律师与法院确定）

## 五、证据与诉请对应表
| 诉讼请求 | 待证事实 | 证据编号 | 状态 |
| --- | --- | --- | --- |
| 请求 1 | <事实> | E001、E003 | 🟢 |
| 请求 2 | <事实> | （无） | 🔴 |

## 六、gate 确认记录（内部）
<①—⑦ 逐项：确认/修正内容 + 日期>

## 七、[需复核] 清单
<逐条汇总>

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

本技能不做什么

• 不出起诉状成稿：本技能的全部产出是供律师成稿的内部要点文件， 不仿造法院文书格式，不生成可径直提交的文本；
• 不填条文号：法条一律 CITE:__ 占位（G10）；民事诉讼法及司法 解释的细节标 模型知识—待核实，引用前经 statute-verify 核验；
• 不做胜诉率与诉讼策略判断：告谁、列几项请求、请求权选择、是否 申请保全——均属律师策略范畴，本技能只列线索与缺口；
• 不启动任何提交动作：不代用户网上立案、不向法院或任何第三方 发送文件（G5 动作闸门）；
• 不做诉讼费金额结论：诉讼费以法院核算为准 模型知识—待核实；
• 非律师场景不豁免律师复核：UPL 门控不可协商（G5）；
• 不让内部信息进入外发文本：要点文件（含 reviewer note、gate 记录、支撑强度标注）仅供内部与律师使用，不对外发出。

收尾与下一步

1. 交付说明：要点文件路径、🔴 项数、需复核 项数；🔴 项未处理前 不建议进入成稿阶段。
2. 非律师用户：再次明示「向法院提交前必须经执业律师复核」，按 G5 整理「带给律师的一页 brief」（核心问题、已识别风险点、建议动作、 时间敏感性——时效旗优先写入）。
3. 建议下一步（用户选择）：
   • 证据缺口（🔴/🟡 行）→ 转 evidence-list 补齐与固定；
   • 法条引用 → 列引用需求清单，经 statute-verify 核验后由律师填实；
   • 律师成稿后 → 成稿版本回写 matters/<slug>/drafts/（新版本号， 不覆盖），外发/提交前过 citation-audit（G10）。
4. 立案后（用户告知已立案时）：经 matter-workspace update 挂同一 slug 记录立案日期、案号、举证期限与开庭日期；举证期限提醒与 evidence-list 联动登记。