# Complaint Outline > 当用户准备起诉、需要把立案信息整理成起诉状要点时使用——同义场景词包括 「写起诉状」「起草起诉书」「准备起诉材料」「诉讼请求怎么写」「帮我列 诉讼请求」「整理起诉要点」。从 matters//intake.md 读取立案采集， 完成当事人主体信息核对（自然人/法人/其他组织表述规范）、诉讼请求设计 （具体可执行、利息计算起点、诉讼费承担）、事实与理由组织（时间线+要件 对应）、管辖依据论证（约定/法定，法条一律 [CITE:__] 占位）、证据与诉请 对应表，输出 complaint-outline.md——它是供执业律师成稿的要点文件，不是 可径直提交的起诉状成稿；沿用 demand-draft-cn 七项 pre-draft gate 并做 起诉场景变体，逐项不确认即停止；非律师使用者向法院提交前必须经执业律师 复核（G5 UPL 门控）。 - Skill: `minimax-ai/complaint-outline` (Agent Skill) - Install (CLI): `npx skillmds@latest add minimax-ai/complaint-outline` - Raw SKILL.md: https://api.skillmd.com/api/skills/minimax-ai/complaint-outline/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: MiniMax AI (https://skillmd.com/u/minimax-ai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/minimax-ai/complaint-outline --- # 起诉状要点（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//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//drafts/complaint-outline-v1.md`， 版本纪律与 matter-workspace 一致——修改出新版（-v2、-v3…），**永不 覆盖**；未建事项的存当前工作目录，reviewer note 记录「未建事项」； - 头部：G4 保密标头（第一行，先于标题）+ reviewer note 五行块； - 文末：汇总全部 [需复核] 清单（G8）；gate 确认记录随附（内部材料， 不进入任何外发文本）。 ## 输出模板 ```markdown 【保密标头：按 G4 二选一——律师「保密·内部法律分析」/ 非律师 「研究备忘——不构成法律意见，使用前请经执业律师复核」】 # 起诉状要点：<事项名称>（v，供律师成稿，非成稿） ## Reviewer note - 来源：matters//intake.md；<用户补充材料清单，逐份标注来源> - 已读：<实际读过的材料范围；未读部分如实写明> - 标记：🟢/🟡/🔴 = 证据支撑强度；[需复核] = 必须经律师核实； [CITE:__] = 法条占位，经 statute-verify 核验后填实 - 时效：法律状态核查日期 - 使用前注意：本文件是供律师成稿的内部要点，不是起诉状； 非律师使用者向法院提交前必须经执业律师复核（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//drafts/`（新版本号， 不覆盖），外发/提交前过 `citation-audit`（G10）。 4. 立案后（用户告知已立案时）：经 `matter-workspace` update 挂同一 slug 记录立案日期、案号、举证期限与开庭日期；举证期限提醒与 `evidence-list` 联动登记。