complaint-outline

Files (2)

• SKILL.md
• plugin-context.md · references/

SKILL.md (first lines)

# 起诉状要点（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…，与

From Hylouis233/workbuddy-skills, MIT.

More from Hylouis233/workbuddy-skills