Lawd Civil Complaint

---
name: 起诉状生成
name_en: lawd-civil-complaint
displayName: 起诉状生成
description_en: "Civil complaint drafting skill: from a senior civil and commercial litigator's perspective, drafts civil complaints meeting the element requirements of Article 122 of the Civil Procedure Law, routing by cause of action across six major categories (contract, tort, marriage and family, labor, company, and others), and outputs rigorously formatted Word documents. Triggered when users mention keywords such as complaint, filing, or lawsuit, describe dispute facts with intent to sue, or need to move cases with failed arbitration or mediation into litigation."
argument-hint: "案件事实与诉讼请求"
description: 民事起诉状起草技能。以资深民商事诉讼律师视角，按案由分流起草符合《民事诉讼法》第122条要素要求的民事起诉状，输出格式严谨的Word文档。TRIGGER when (1) 用户提及起诉状/民事起诉状/起诉书/诉状/起草起诉状/立案材料/准备起诉等关键词，(2) 用户描述纠纷事实并表达诉讼意愿，(3) 用户需要将仲裁/调解失败的案件转入诉讼程序。支持合同/侵权/婚姻家庭/劳动/公司及其他六大类民商事案由。合同纠纷必须全面阅读合同条款（权利义务/违约责任/合同解除/争议解决），识别到有效仲裁条款时强制提示用户管辖风险，用户坚持起诉时才继续输出。文档生成强依赖 scripts/generate_complaint.py 脚本，由模型组装 JSON 后调用脚本输出 Word，避免格式漂移。
---

# 民事起诉状起草

专业的民事起诉状起草技能，输出符合中国大陆地区法院立案规范的 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个文件，见下方映射表）
```

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

| 案由 | 细分文件 |
|------|---------|
| 买卖合同纠纷 | `contracts/sale-contract.md` |
| **房屋买卖合同纠纷**（商品房预售/二手房买卖） | `contracts/house-sale-contract.md` |
| 民间借贷纠纷 / 保证合同纠纷 / 抵押合同纠纷 | `contracts/loan-private.md` |
| 金融借款合同纠纷 / 银行信用卡纠纷 | `contracts/loan-financial.md` |
| 租赁合同纠纷 / 房屋租赁合同纠纷 / 融资租赁合同纠纷 | `contracts/lease-contract.md` |
| 承揽合同纠纷 | `contracts/undertaking-contract.md` |
| 建设工程施工合同纠纷 / 建设工程合同纠纷 | `contracts/construction-contract.md` |
| 装饰装修合同纠纷 | `contracts/decoration-contract.md` |
| 劳务合同纠纷 | `contracts/labor-service-contract.md` |
| 服务合同纠纷 / 物业服务合同纠纷 / 咨询服务合同纠纷 | `contracts/service-contract.md` |
| 委托合同纠纷 / 委托理财合同纠纷 / 资产管理合同纠纷 | `contracts/entrust-contract.md` |
| 其他合同纠纷（运输/保管/仓储/行纪/中介/合伙等） | `contracts/contract-general.md`（仅读通识文件，无细分文件） |

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

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

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

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

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

| 案由 | 细分文件 |
|------|---------|
| 离婚纠纷（含子女抚养、财产分割、损害赔偿） | `family/divorce.md` |
| 离婚后财产纠纷 | `family/divorce-property.md` |
| 抚养费纠纷（追索欠付/初次主张/增减抚养费） | `family/child-support.md` |
| 变更抚养关系纠纷 | `family/custody-change.md` |
| 分家析产纠纷 | `family/family-property-division.md` |
| 赡养纠纷 / 婚约财产纠纷 / 继承纠纷 / 同居关系析产 | `family.md`（旧版，一步加载，无需读 family-general.md） |

### 侵权类加载规则

| 案由 | 加载文件 |
|------|---------|
| 名誉权纠纷 / 网络侵权（名誉）纠纷 | `templates/tort/reputation-right.md` |
| 生命权、身体权、健康权纠纷 / 安全保障义务违反纠纷 | `templates/tort/life-body-health.md` |
| 其他侵权案由（交通事故/医疗/产品责任/财产损害等） | `templates/tort.md` |

| 步骤 | 何时读取 | 读取文件 |
|------|---------|---------| 
| Step 1.5 | 用户选择「要素式」或「两种都要」，或案由命中 11 类白名单 | `references/element-based-format.md` |
| Step 2 | 案由识别阶段 | `references/case-types-index.md` |
| Step 3a | 案由为合同纠纷类 | `references/templates/contracts/contract-general.md` |
| Step 3b | 案由为合同纠纷类，读完 3a 后 | `references/templates/contracts/{细分文件}.md`（见上表） |
| Step 3 | 案由为**非合同类** | 见下方各类加载规则（婚家/侵权已拆分为子目录，劳动/公司/其他仍用单文件） |
| Step 4 | 管辖审查阶段 | `references/jurisdiction.md` |
| Step 5 | 当事人信息标准化阶段 | `references/parties-format.md` |
| Step 6 | 诉讼请求起草阶段 | `references/claims-drafting.md` |
| Step 6.5 | 法律法规检索 | 调用 `律师法规检索` skill（**强制**） |
| Step 7 | 事实理由撰写阶段 | `references/facts-reasoning.md` |
| Step 7.5 | 类案检索 | 调用 `律师类案检索与报告` skill（**强制**） |
| Step 8 | 文档生成阶段 | `references/script-usage.md` |

> **合同纠纷 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` 传入：
   ```bash
   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. 已明确绑定唯一案件且案件管家可用时，成果完成后提交标准案件事件；无案件不建档、不回写，回写失败不得阻塞成果交付。