起诉状生成

民事起诉状起草

专业的民事起诉状起草技能，输出符合中国大陆地区法院立案规范的 Word 文档。本技能由资深民商事诉讼律师视角设计，覆盖《最高人民法院民事案件案由规定》（2020 修订）下的高频案由。

技能定位

• 法理严谨：诉讼请求与事实理由采用「请求权基础分析法」（Anspruchsmethode）
• 格式合规：严格遵循《民事诉讼法》第 122 条及司法解释关于起诉状必备要素的规定
• 要素完整：通过结构化提问主动补全缺失要素
• 格式稳定：Word 排版由 Python 脚本固化，不依赖模型自由发挥

Token 加载策略（关键）

本技能采用「按需加载」架构：本文件仅作为路由器，下列 references 文件仅在工作流执行到对应步骤、且确有需要时才使用 Read 工具读取。严禁开局预读全部 references。

两步加载规则（重要）

templates文件须按相应案由的”通识规则+细分案由文件“两步顺序加载，两个文件都必须读取，以合同纠纷为例：

Step 3a：先读取 references/templates/contracts/contract-general.md
          （合同纠纷通识规则，所有合同案由共用，定义六段式结构、利息三要素、违约金双轨等）

Step 3b：再读取 references/templates/contracts/{细分案由文件}.md
          （仅读取与本案案由精确对应的1个文件，见下方映射表）

合同纠纷案由 → 细分文件映射表

婚家类纠纷两步加载规则（重要）

婚家类案由须按以下两步顺序加载，两个文件都必须读取：

Step 3a：先读取 references/templates/family/family-general.md
          （婚家通识规则，所有婚家案由共用，定义称谓、法条索引、金钱给付格式等）

Step 3b：再读取 references/templates/family/{细分案由文件}.md
          （仅读取与本案案由精确对应的1个文件，见下方映射表）

婚家类案由 → 细分文件映射表

侵权类加载规则

合同纠纷 Step 3 禁止行为：禁止读取已废弃的 references/templates/contract.md（旧版单文件，已完整并入 contracts/contract-general.md，内容包含合同条款阅读规则、仲裁管辖提示流程、违约金利息并存判断、买卖合同专项、委托合同专项等）。

信息收集最小要素清单（内嵌，无需外部 Read）

启动时如用户提供的信息不全，请一次性列出以下缺项请求补充（避免反复打扰）。

⚠ 与 Step 5.5 的分工（避免重复打扰）：企业主体（法人/非法人组织/合伙企业/个体工商户）的 USCC、法定代表人、注册住所地由 Step 5.5 通过「企业工商信息查询」能力自动补全，不要向用户索取这三项；向用户只需确认企业全称（营业执照全称，或可供定位的简称）。仅当 Step 5.5 走完 parties-format.md §9.4 三个出口仍无法取得时，才转而请用户提供。

1. 原告信息：自然人需姓名（含别名/曾用名）、性别、民族、出生年月日（精确到日，不可写年龄）、身份证号、住所（精确到门牌号；实际地址与身份证不一致时同时注明现住地址）、联系电话/邮箱、国籍（外国人/港澳台居民需写明证件号）；企业主体只需提供全称 + 联系方式（USCC / 法定代表人 / 住所地由 Step 5.5 自动补全，不向用户索取）；其他主体类型详见 references/parties-format.md
2. 被告信息：要素同上；多被告需逐一提供
3. 第三人（如有）：信息要素同上
4. 纠纷概要：发生时间、地点、起因、经过、当前状态
5. 诉讼标的：金额（如涉及给付）、行为内容（如涉及作为/不作为）、标的物（如涉及交付）
6. 关键证据线索：现有书证、物证、电子数据、证人等（仅作起草参考，本技能不生成证据清单）
7. 前置程序：是否经过仲裁、调解、行政处理（劳动争议、医疗纠纷、农村土地承包等需特别注意）
8. 管辖偏好：原告住所地法院 / 被告住所地法院 / 合同履行地 / 协议管辖 等

工作流程

Step 1：信息完整性检查

对照「最小要素清单」逐项核对，缺项一次性向用户询问。

Step 1.5：起诉状格式确认（显著位置，必问）

⚠ 本步骤优先级最高：在询问任何案件细节之前，必须先确认输出格式。

判定规则：

• 用户原始指令已显式声明「要素式」/「传统」/「都要」/「两种」→ 锁定该选择，跳过提问；
• 否则必须以显著方式询问用户：

⚠ 请确认起诉状格式（最高人民法院已对部分案件发布要素式示范文本）：
  ① 传统民事起诉状（自由叙述式，传统通用格式）
  ② 要素式民事起诉状（按要素勾选/填空式，部分法院立案要求）
  ③ 两种格式都需要（同时输出）

将用户选择保存为会话变量 output_styles（值为集合：{"traditional"} / {"element"} / {"traditional", "element"}）。

Step 2：识别案由

Read references/case-types-index.md，根据用户描述匹配 1-2 个最贴切的具体案由（精确到三级或四级），并锁定对应的 template 文件路径（合同类按上方映射表确定细分文件）。

Step 2.5：11 类案由合规提示（仅当 output_styles 仅含 traditional 时执行）

若 Step 2 识别出的案由命中下列 11 类白名单（《关于印发部分案件民事起诉状、答辩状示范文本（试行）的通知》明确覆盖），且用户在 Step 1.5 仅选择了「传统」，必须主动重点提示用户：

11 类白名单：金融借款合同纠纷、银行信用卡纠纷、民间借贷纠纷、保证保险合同纠纷、买卖合同纠纷、物业服务合同纠纷、融资租赁合同纠纷、证券虚假陈述责任纠纷、机动车交通事故责任纠纷、劳动争议纠纷、离婚纠纷。

显著提示模板：

📌 合规提示：根据最高人民法院《关于印发部分案件民事起诉状、答辩状示范
文本（试行）的通知》，本案案由（{案由}）属于人民法院可能要求提交要素
式起诉状的 11 类案件之一。建议：
  ① 仅传统（继续当前流程）
  ② 仅要素式（替换为要素式版本）
  ③ 两种都要（同时输出）

用户回应后更新 output_styles 集合。

Step 3：读取专项模板

详细路由规则见顶部「Token 加载策略」中的各映射表，此处仅列执行指令。

合同纠纷：先读 contracts/contract-general.md（必读），再读对应细分文件（见上方合同映射表，仅读1个）。

⚠ 合同纠纷强制前置：读取合同材料后，必须立即执行 contract-general.md §二「合同条款强制阅读规则」：

1. 核查双方权利义务条款 → 确立守约/违约事实框架
2. 核查违约责任条款 → 确定可主张的违约金类型和金额
3. 核查合同解除条款 → 确定解除路径（确认解除 vs 判令解除）
4. 核查争议解决条款（最高优先级） → 识别仲裁条款，如发现疑似有效仲裁条款，立即停止起草，执行 contract-general.md §十一仲裁管辖提示流程，等待用户确认后方可继续

婚家纠纷：先读 family/family-general.md（必读），再读对应细分文件（见上方婚家映射表，仅读1个）。

侵权纠纷：按案由一步加载（见上方侵权加载规则表）。

劳动 / 公司 / 其他：先读对应大案由目录下的 general 文件（labor/labor-general.md / company/company-general.md / general/general-general.md），再读对应细分子案由文件（仅读1个）。

Step 4：管辖审查

Read references/jurisdiction.md，确定有管辖权的法院全称（精确到区/县级），如存在多个可选管辖法院，向用户说明优劣并请其确认。

Step 5：当事人信息标准化

Read references/parties-format.md，按主体类型（自然人/法人/非法人组织/个体工商户/未成年人/涉外）将当事人信息整理为合规表述。

Step 5.5：企业工商信息自动补全企业当事人信息（企业主体必须执行）

凡案件存在企业主体（法人/非法人组织/合伙企业/个体工商户），且以下任一要素缺失，必须立即通过「企业工商信息查询」能力自动补全，无需等待用户提供：

• 统一社会信用代码（USCC）
• 法定代表人姓名
• 注册住所地（须精确到街道/镇级，例如「拱墅区大关街道祥园路88号」，仅到区/县级不合格）

能力语义（两段能力，缺一不可，均不绑定任何具体工具名或供应商，运行时动态探测已连接的 MCP 并按语义选用）：

1. 「企业主体定位 / 模糊搜索」能力——输入企业名称（可能是简称、品牌名、部分名称），返回候选企业清单（企业全称 + 该连接器内部主体标识）；
2. 「工商登记信息查询」能力——以已确认的企业全称（或主体标识）为入参，返回 USCC、法定代表人、注册地址（含街道级）、经营状态。

⚠ 直接以简称或未定位的名称调用登记类能力，通常返回空数据或错误命中，反而把本可核验的案件推进降级区。两步不可合并、不可跳过第 1 步。

调用步骤（三段式探测 + 两步取数，必须严格按序执行）：

1. 探测：调用 qwenwork_mcp_tool_list，keyword 覆盖能力中英文名与供应商中英文名：企业 / 工商 / 企业信息 / 工商登记 / 企查查 / 天眼查 / 元典 / 启信宝 / registration / company / enterprise / qcc / tianyancha / qibook / yuandian；
2. 匹配：在返回工具中分别匹配出上述两类能力——定位类按 description 含「企业搜索」「模糊搜索」「主体定位」「企业名称检索」「company search」「fuzzy search」等语义判定；登记类按含「企业登记」「工商信息」「企业基本信息查询」「company registration」「basic profile」等语义判定。用 qwenwork_mcp_tool_get 验证 schema（定位类须返回企业全称，登记类须返回 USCC/法定代表人/注册地址），不符则切下一家候选；
3. 调用第一步——定位唯一主体：用 qwenwork_mcp_tool_call 调定位类能力确认营业执照全称。返回多个候选时必须把候选清单完整展示给用户并等待其明确选定，严禁自行选择；零命中时提示用户核对全称后重试；
4. 调用第二步——取登记字段：以第 3 步锁定的企业全称（或主体标识）为入参调登记类能力，获取 USCC、法定代表人、注册地址（含街道）、经营状态；多家可用时按匹配度（语义贴合度与字段完整度）选用，首选出错切下一家；
5. USCC 字段缺口续探：若所选登记类工具不返回 USCC（部分连接器的基础画像类能力就是如此），先回看第 3 步候选清单是否已带 USCC；仍缺失时须继续在同一连接器下探测可提供 USCC 的其他能力（如"可用维度/能力清单查询 + 通用维度调用"两段式、或"企业详情"类能力），同一连接器全无则切下一家；
6. 地址完整性核验：若返回地址不含街道层级，address 字段仍填连接器返回原文（不得在字段值里追加括注），改在交付说明/质量自检报告中提示「住所地缺街道层级，立案前须补全」；
7. 经营状态预警：若企业状态为「注销」「吊销」「撤销」，必须向用户提示主体资格风险，由用户确认是否继续。

降级（A 档·拒绝编造）：当事人信息须提交法院，准确性即价值。降级处理口径以 references/parties-format.md §9.4 为唯一真源（覆盖三种触发情形：探测不到连接器 / 调用失败 / 字段不全；及三个统一出口），执行时按该节办理，本文不复述出口清单以免话术漂移。

❗ 正文洁净铁律：uscc / address / legal_rep_name 等字段会被 scripts/generate_complaint.py 原样拼进起诉状当事人段落。字段值内只允许填真实值或中性占位「（待补充）」；「（用户自报，待核验）」「（待补全街道）」等核验状态标注一律只写在交付说明/质量自检报告，严禁进入文书正文。 严禁在本技能中写死任何具体工具名或供应商调用命令；严禁连接器不可用时凭模型记忆或网络检索编造企业登记信息。 详见 references/parties-format.md §九。

Step 6：诉讼请求起草

Read references/claims-drafting.md，结合 Step 3 模板内的请求范例，起草明确、具体、可执行、可量化的诉讼请求（含利息、违约金、诉讼费、保全费等）。

⚠ 互斥诉讼请求强制自查：起草完诉讼请求后，必须对照 claims-drafting.md §八「互斥诉讼请求判断矩阵」逐一检查，确认所有请求之间不存在互斥关系。重点检查：

• 继续履行 vs 解除合同（不可并存）
• 违约责任 vs 侵权责任（同一事实，择一）
• 定金双倍返还 vs 违约金（择高适用，不可并用）
• 约定逾期违约金 vs LPR资金占用损失（实质重叠，采用主位+备位双轨写法）
• 精神损害赔偿（违约路径不支持，须走侵权路径）
• 各案由专项互斥规则（公司/婚家/物权/继承/合伙/侵权，见§八各子节）

自查结果必须显式输出：在交付说明/质量自检报告中逐组列出对照结论（如"继续履行 vs 解除合同 → 不并存（本案主张继续履行）""约定逾期违约金 vs LPR利息 → 不并存（合同无约定违约金）"），不得只写"已自查"。

合同纠纷的利息四要素、违约金双轨、合同解除两种写法等专项规范，见 Step 3 已读取的 contract-general.md §三至§五，此处不重复内嵌。

Step 6.5：法律法规检索（强制调用 律师法规检索 skill）

必须调用 律师法规检索 skill 进行法律法规检索，严禁编造法条。

⚠ 调用口径： ❌ 直接使用 pkulaw / fy-law-search-service 等 MCP 工具检索 = 未完成本步骤（缺 Query 改写、归一化落盘、verify_laws.py 门禁） ✅ 通过 Skill 工具调用 律师法规检索 = 正确执行

• 检索目标：本案案由对应的请求权基础、构成要件、抗辩排除规则、诉讼时效、利率/违约金上限等关键法条
• 检索维度：法律 → 司法解释 → 司法文件 → 地方规定
• 验证：核查每条法规的有效性状态（现行 / 已失效 / 已修正），优先引用最新版本
• 输出沉淀：将检索结果中的「法律全名 + 条款序号 + 条文摘要」用于 Step 7 的事实理由撰写与 Step 6 诉讼请求依据引用
• 失败兜底：若 律师法规检索 不可用，必须明确告知用户「未完成法规检索，请律师补充核验法条时效」，不得自行编造

Step 7：事实和理由撰写

Read references/facts-reasoning.md，运用请求权基础分析法四步（定性 → 涵摄 → 抗辩排除 → 法律后果）撰写事实和理由部分。引用法条以 Step 6.5 检索结果为准，不得凭记忆引用未经验证的条款。

合同纠纷事实六段式结构（签订→原告履约→被告违约→催告→损失量化→收束），见 Step 3 已读取的 contract-general.md §六，此处不重复内嵌。

Step 7.5：类案检索（强制调用 律师类案检索与报告 skill）

必须调用 律师类案检索与报告 skill 进行类案检索，严禁编造案例。

⚠ 调用口径： ❌ 直接使用 pkulaw search_case 等 MCP 工具检索 = 未完成本步骤（缺案例核验、裁判观点提炼等增强流程） ✅ 通过 Skill 工具调用 律师类案检索与报告 = 正确执行

• 检索维度：受理法院 / 上级法院 / 最高院 × 相同案由或近似案由 × 近三年优先
• 权威性层级：指导案例（应当参照）> 公报案例（可参照）> 典型案例 > 普通案例
• 用途：验证请求金额/利率/违约金等是否在裁判尺度合理区间；识别本院类案倾向
• 失败兜底：若不可用，必须明确告知用户，不得编造案号或裁判规则

Step 8：质量自检 → 生成 Word

对照下方「质量自检清单」逐项核查通过后，按 output_styles 分流生成：

1. Read references/script-usage.md 学习 JSON 输入 schema；

2. 如 output_styles 含 traditional：组装传统 JSON → 调用 scripts/generate_complaint.py；

3. 如 output_styles 含 element：

   • Read references/element-based-format.md（若 Step 1.5 未读过）；
   • 按 references/script-usage.md 第 9-10 节组装 JSON：命中模板时用 template_fill.fields（路径 A），无模板时用 elements（路径 B）；
   • 调用 scripts/generate_element_complaint.py 生成 Word；

4. 同时含两种时，分别生成 2 个 Word 文件，并行返回路径；

5. 对每个生成文件运行正式文书轻量门禁。将本案全部已确认的原告、被告名称分别通过可重复的 --plaintiff、--defendant 传入；将需要前后一致的关键金额通过可重复的 --amount 传入：

   python3 scripts/validate_complaint.py <起诉状.md|txt|docx> \
     --plaintiff "张三" --defendant "某某公司" --amount "100000元"
   

   • 脚本检查必备结构、空壳章节、残留占位符、法院/落款/日期，以及已确认名称和关键金额是否出现在成稿；
   • 退出码为 0 才可标记为「门禁通过稿」；退出码非 0 时按提示修稿后重跑；确需先给用户查看时只能标记为「草稿」或「待核验稿」；
   • 该门禁只做机械检查，不判断事实真实性、法律适用、管辖、诉讼策略或金额计算是否正确。

6. 向用户返回所有文件绝对路径 + 质量自检和门禁结果；

7. 交付说明必写「企业主体工商核验状态」（案件含企业主体时）：逐个企业主体标明

   • ✅ 已经连接器核验（注明取数字段：USCC / 法定代表人 / 注册地址），或
   • ⚠ 用户自报，未经连接器核验 —— 此时必须在交付说明显著位置提示：「立案前须由律师核对营业执照原件或国家企业信用信息公示系统（gsxt.gov.cn）」，并列出待补/待核字段清单。

   核验状态标注只出现在交付说明与质量自检报告中，不得写入起诉状正文（正文只能是真实值或「（待补充）」）。

质量自检清单（内嵌，通用项 + 合同 / 要素式专项引用）

生成前必须逐项确认：

1. ✅ 当事人信息齐全：自然人六要素、法人四要素 + 法定代表人
   • 1a. 法人四要素中如有字段确实无法核验到（已按 parties-format.md §9.4 走完三个出口），正文允许以中性占位「（待补充）」呈现，但必须在交付说明中列为待补项；正文出现「（用户自报，待核验）」「（待补全街道）」等标注视为不合格
2. ✅ 诉讼请求明确具体：金额精确，利率表述完整（含起算日、基数），不写「按法律规定」
3. ✅ 诉讼请求有相应的法律依据和事实依据（但不需要在诉讼请求中写明依据条款）
4. ✅ 诉讼请求互斥自查已执行：已对照 claims-drafting.md §八互斥判断矩阵逐一核查，确认无互斥请求并存（继续履行/解除互斥；违约/侵权择一；定金/违约金择高；逾期违约金/LPR利息采用主位+备位双轨；精神损害赔偿须走侵权路径；各案由专项互斥规则已核查）
5. ✅ 事实陈述五要素齐全：时间、地点、当事人、行为、结果
6. ✅ 关键事实与证据呼应：行文中以「详见在案证据」或「有相关凭证为证」指引
7. ✅ 法条引用规范：法律全名 + 条款序号（如《中华人民共和国民法典》第五百七十七条）
8. ✅ 管辖法院全称正确：精确到「XX 市 XX 区/县人民法院」
9. ✅ 案由表述符合《民事案件案由规定》（2020 修订）
10. ✅ 落款格式正确：「此致」段首空两格；法院名称顶格；自然人原告→「原告（签字）：姓名」；法人原告→「原告（盖章）：名称」+下一行「法定代表人（签字）：」；非法人组织→「原告（盖章）：名称」+下一行「执行事务合伙人（签字）：」；个体工商户→「原告（签字）：经营者姓名」
11. ✅ 不含情绪化语言、不暴露己方瑕疵、不主张应由法院依职权处理事项
12. ✅ （合同纠纷专项） 对照 Step 3 已读取的 contract-general.md §八完成合同专项自检（利息四要素：基数+具体起算日+LPR全称+暂计截止日及金额；违约金与利息并存已按§九判断；维权费用已按§十核查；违约金双轨；解除写法；担保责任；原告履约先于被告违约陈述；事实理由无小标题无"上述事实有证据为证"结尾）
13. ✅ （要素式专属） 所有要素项已逐项填写或注明「无」/「不适用」；复选框已勾选不留空（☐→☑）；template_fill.fields 中无空值字段；命中模板时未改动模板原有字体/字号/表格结构
14. ✅ Step 6.5 法规检索已调用 律师法规检索，所引法条经检索验证且现行有效（或已明确告知用户未完成检索）；Step 7.5 类案检索已调用 律师类案检索与报告（或已明确告知未完成）
15. ✅ （含企业主体时必查）企业主体工商核验状态已在交付说明中逐主体标明：「已经连接器核验」或「用户自报未核验」；属后者的已在交付说明显著位置提示「立案前须律师核对营业执照或国家企业信用信息公示系统」；且起诉状正文内无任何核验状态括注（仅允许真实值或「（待补充）」）
16. ✅ references 完整读取：本次执行所引用的 references 文件（case-types-index / contract-general / 细分模板 / jurisdiction / parties-format / claims-drafting / facts-reasoning / script-usage / element-based-format）均已完整读取，未用 limit 等参数截断；凭前次执行记忆跳读视为不合格（见「重新执行规则」）
17. ✅ scripts/validate_complaint.py 已对每份成稿运行；只有退出码为 0 的文件才标记为「门禁通过稿」

输出文件命名规则

传统：民事起诉状-{原告简称}诉{被告简称}-{案由}-{YYYYMMDD}.docx
要素式：要素式民事起诉状-{原告简称}诉{被告简称}-{案由}-{YYYYMMDD}.docx

文件由对应脚本（scripts/generate_complaint.py / scripts/generate_element_complaint.py）自动按上述规则命名，输出至当前工作目录或用户指定路径。

约束原则

一、检索工具强制调用

法律法规检索必须调用 律师法规检索，类案检索必须调用 律师类案检索与报告。严禁编造、虚构或杜撰任何案例或法条 — 虚构的法条或案号会导致律师据此提交的起诉状面临驳回、败诉或律师执业风险。所有引用必须标注检索来源（工具名 + 检索时间 + 关键词）。

二、被整合调用模式

当本技能由 律师庭前准备 或其他上游 skill 整合调用时：

• 跳过检索：若上游已提供法规 / 类案检索结果，直接使用，不再调用 律师法规检索 与 律师类案检索与报告。边界说明："上游已提供"特指上游 skill 通过其自身检索流程产出的结构化检索结果；在本技能内部直接使用 MCP 工具（pkulaw / fy-law-search-service 等）检索得到的结果不视为"上游已提供"，独立调用时仍须按 Step 6.5 / 7.5 通过 Skill 工具调用检索 skill
• 跳过信息收集：使用上游已收集的案件材料，不再重复向用户询问
• 跳过 Step 1.5 / 2.5 询问：若上游已指定 output_styles，直接锁定

独立调用时，上述步骤照常执行。

三、检索失败兜底

律师法规检索 或 律师类案检索与报告 调用失败时，不得自行编造法条或案例，必须：

1. 在质量自检报告中明确标注「未完成 XX 检索」
2. 提醒用户由执业律师人工补充核验
3. 起诉状内法条引用降级为「保守引用现行有效的《民法典》《民诉法》总则性条款」，避免引用具体细则

重新执行规则

用户要求"重新执行 / 重新跑一次 / 上文当作没发生"时：

1. 所有 references 文件必须重新完整读取（不得凭前次执行的记忆跳读，不得用 limit 截断）；
2. Step 1-8 全部重新执行，包括案由识别、模板加载、管辖审查、互斥自查、检索与门禁；
3. 前次执行中用户已确认的信息（格式选择、金额认定、仲裁/诉讼选择等）可以引用，但须在回复中注明"根据您此前的确认…"，并允许用户推翻；
4. "当作没发生"仅指丢弃前次产出，不豁免本技能任何流程步骤。

风险提示与免责声明

• 本技能生成的起诉状属于格式与内容的初稿，正式提交法院前应当由执业律师终审定稿
• 法律法规存在动态修订，本技能依据当前现行有效的《民法典》（2020）、《民诉法》（2023 修正）及相关司法解释，使用前请由律师核验法条时效
• 复杂案件（重大涉外、群体性、刑民交叉）建议启动专项尽调，不宜直接套用本技能输出

可选套件上下文（不影响独立使用）

1. 工作目录根存在 套件运行规则.md 时必须先读取并执行；不存在时以本技能硬规则为准，不影响独立使用。
2. 工作目录根存在 办案画像.md 时，只读取与当前任务有关的诉讼立场、风险偏好和文书风格；不存在时按本技能默认运行，不追问、不报错。
3. 仅当用户明确切换到某案或提供唯一案件路径时，读取 cases/{案件简称}/案件画像.md；不得猜测案件，不得跨案带入。
4. 画像只影响表达与偏好，不得覆盖事实、法律依据、必备结构、验证结果或本技能硬规则。
5. 已明确绑定唯一案件且案件管家可用时，成果完成后提交标准案件事件；无案件不建档、不回写，回写失败不得阻塞成果交付。