agentsclimarketplace
Sign in

Plaintiff complaint

Skill Youchu-lawhub/cn-litigation-toolkit/skills/plaintiff-complaint

生成民商事主诉文书（一审起诉状、二审上诉状、再审申请书、仲裁申请书、仲裁反申请书）。 覆盖诉讼各审级程序与商事仲裁程序的主动攻方文书。 当用户提及：起诉状、上诉状、再审申请书、仲裁申请书、仲裁反申请书、起诉、上诉、再审申请、申请仲裁、仲裁反请求 时触发本技能。From its SKILL.md

Install
npx -y skills add Youchu-lawhub/cn-litigation-toolkit --skill plaintiff-complaint

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

12.9 KB, ~5.0k tokens by cl100k_base, as published. Nobody here has run it

主诉诉状（plaintiff-complaint）

生成民商事主诉文书，覆盖诉讼程序（一审起诉状、二审上诉状、再审申请书）与仲裁程序（仲裁申请书、仲裁反申请书）五种场景。

设计原则

要件攻防分析已对案件进行了大量论证，起诉状的重点在于表达而非重复分析。 本技能的核心价值是将攻防分析结论转化为符合司法文书规范的书面表达。

前置条件

在调用本技能前，必须确保以下材料已经准备完毕：

序号材料说明
1诉请描述用户明确的诉讼请求概述
2案件事实梳理经整理的时间线与关键事实
3要件攻防分析包含请求权基础、构成要件逐项论证

如缺少上述材料，应提示用户先完成相应步骤，不得在缺失关键输入的情况下强行生成。

工作流程

第零步：主体信息自动补充（文书生成前必经）

所有诉讼文书在生成最终稿之前，必须完成主体信息的核实与补充：

  1. 企业主体（公司、合伙企业、非法人组织等）：

    • 调用工商信息能力槽（BIZ.company_info 或同等接口，如企查查MCP get_company_registration_info）查询最新工商登记信息
    • 补充字段：企业全称、统一社会信用代码、住所地、法定代表人/负责人
    • 禁止在诉讼文书主体信息中写入：企业类型、成立日期、注册资本、经营范围等工商登记冗余信息
    • 若能力槽不可用，但用户提供的案件材料中包含相关信息，直接从材料提取并补充
    • 若材料中亦无相关信息，主动向用户询问："请提供[企业名称]的统一社会信用代码、住所地、法定代表人信息"
    • 用户明确拒绝提供时，保留"[待用户补充]"占位符，严禁自行编造或填写虚假信息

  2. 自然人主体：

    • 无MCP可用，仅依赖用户提供的材料或用户补充
    • 从案件材料中提取：姓名、性别、出生日期、身份证号码、住所地/经常居住地
    • 材料中缺失的，主动向用户询问
    • 用户拒绝提供时，保留"[待用户补充]"占位符，严禁编造

  3. 适用文书类型：

    • 起诉状、答辩状、代理词中的当事人信息部分
    • 证据目录中的主体证据组
    • 程序性文书中的申请人/被申请人信息
    • 案件事实梳理中的主体识别部分

Step 1: 接收与校验材料

  1. 接收用户提供的诉请描述、案件事实梳理、要件攻防分析
  2. 检查三项材料的完整性：
    • 诉请描述是否包含明确的请求事项
    • 案件事实梳理是否有时间线和关键事实
    • 要件攻防分析是否包含请求权基础和要件论证
  3. 如材料不完整，列出缺失项并请用户补充

Step 2: 识别程序类型与阶段

根据以下特征判断程序类型与诉讼/仲裁阶段：

一审起诉状（诉讼）：

  • 首次提起诉讼
  • 尚无一审判决
  • 当事人称谓：原告/被告
  • 致送：管辖法院

二审上诉状（诉讼）：

  • 已有一审判决，对判决结果不服
  • 需明确上诉请求（撤销/变更原判）
  • 当事人称谓：上诉人/被上诉人
  • 需注意上诉期限（判决书送达之日起15日内）
  • 致送：原审法院（递交）/ 二审法院

再审申请书（诉讼）：

  • 已有生效判决，申请再审
  • 必须援引《民事诉讼法》第211条规定的法定事由
  • 当事人称谓：再审申请人/被申请人
  • 需注意申请期限（判决生效后6个月内）
  • 致送：上一级法院或原审法院

仲裁申请书（仲裁）：

  • 基于仲裁协议/仲裁条款提起仲裁
  • 当事人称谓：申请人/被申请人
  • 必备板块：仲裁依据（引述合同中仲裁条款原文 + 所有当事人受约束的依据）、仲裁请求、事实和理由
  • 致送：约定的仲裁委员会
  • 无上诉期概念，但注意仲裁时效（一般适用诉讼时效规定）

仲裁反申请书（仲裁）：

  • 被申请人基于同一合同关系对申请人提出反请求
  • 当事人称谓：反申请人（本案被申请人）/ 被反申请人（本案申请人）
  • 结构同仲裁申请书，增加"反请求事项"板块
  • 致送：同一仲裁委员会

Step 3: 整合攻防分析结论

  1. 从要件攻防分析中提取：
    • 请求权基础（法律依据）
    • 各要件的论证结论
    • 证据支撑要点
  2. 将分析结论转化为诉状中"事实与理由"部分的论证框架
  3. 按照"大前提（法律规定）→ 小前提（案件事实）→ 结论（诉请成立）"的三段论组织

Step 4: 撰写诉状

📎 模板单一权威源：references/templates.md（覆盖一审起诉状/二审上诉状/再审申请书/仲裁申请书/仲裁反申请书五种骨架 + 填写指引）。SKILL.md 不再内嵌骨架，仅保留各类型差异化提示与硬性铁律。

4.1 类型 → 模板映射

文书类型templates.md 章节特别要求
一审起诉状（自然人原告）§一当事人称谓：原告/被告
一审起诉状（法人原告）§二加"法定代表人"行、末落款用"盖章"
二审上诉状§三上诉请求首项须为"撤销一审判决"或"变更……"；上诉理由须点原判错误
再审申请书§四须援引《民事诉讼法》第 211 条具体项；申请期限 6 个月
仲裁申请书§五必备"仲裁依据"板块（引述仲裁条款原文 + 各当事人受约束依据）；金钱请求附索赔金额计算说明；致送仲裁委
仲裁反申请书§六称谓"反申请人（本案被申请人）"；须与本请求同一仲裁委员会；"反请求事项"板块区别于本请求

4.2 事实与理由三段论（统一框架）

  • 诉讼类：事实（时间线）→ 法律适用（要件攻防分析结论压缩）→ 结论
  • 二审/再审：先点原判错误 / 再援引法定事由，再展开
  • 仲裁类：合同关系与仲裁条款 → 争议事实 → 逐项请求的法律事实依据

4.3 落款铁律（强制）

⚠ 禁止使用任何 HTML 标签（<div>、&nbsp;、<br>、<p align> 等）。Word 转换脚本（scripts/md2docx_legal.py）会将 HTML 标签当文本输出导致乱码。右对齐效果由 Word 模板段落格式控制，Markdown 侧仅写纯文本。

Step 5: 输出文档（md 优先）

⛔ 交付前必过闸门（见 Expert.md「共享护栏」）：核验对象为诉状全文。

默认交付 Markdown：核验放行后先产出 md 成品（写入输出目录并回链），随后询问用户「是否转 Word（Word 转换后端（DOCX.md_to_docx））」，确认才转 .docx。

🔗 台账自动回写（强制）：在产出 md 成品之前，调用「案件管家」§0.7 自动同步接口：搜索台账 recordId → 追加案件进展（"{日期}起诉状已起草（诉请：{标的额}）"）→ 更新下一步动作 → 写入。搜索无结果跳过回写并标注；回写失败不阻塞输出但标注"⚠️ 台账未自动更新"。

输出文件命名：{案件简称}_起诉状_{日期}.md（二审为 _上诉状_，再审为 _再审申请书_，仲裁为 _仲裁申请书_）。Word 版同名 .docx。

转 Word 排版规范

🔒 Word 排版铁律（强制）：所有诉讼文书转 Word 时，必须使用 scripts/md2docx_legal.py 转换脚本（路径：${SUITE_ROOT}/scripts/md2docx_legal.py），用法：python3 md2docx_legal.py input.md output.docx。该脚本严格按照最高人民法院诉讼文书样式模版执行排版：宋体、标题二号居中不加粗、正文四号首行缩进2字符、行距固定25磅、此致缩进+法院顶格+签名右对齐+附件缩进。禁止使用 pandoc 或其他工具直接转换（格式不达标）。排版铁律全文见 format-spec.md。

排版参数详见 Expert.md「核心参数速查」（源：format-spec.md）。

外部能力调用

预检协议、探测关键词、AskUserQuestion 交互流程详见 Expert.md「MCP 预检协议」。

本技能使用的后端：

后端用途技能特有降级
LAW.*校验诉状中法条引用法条标注 [L4-法条待验证]
BIZ.*核验当事人主体信息（名称/统一社会信用代码/法定代表人及其职务）标注 [L4-主体信息待验证]
COLLAB.*从案件管家台账提取法院名称/案号标注 [L4-法院待确认]——请核实管辖法院

降级策略

通用降级规则详见 profile.md「MCP 预检协议 → 降级规则」。以下为本技能补充规则：

  • 法条引用：保留用户/攻防分析中提供的法条引用，标注 [L4-法条待验证]
  • 主体信息：保留用户提供的当事人信息，标注 [L4-主体信息待验证]
  • 不阻塞生成：后端不可用不阻止诉状生成

质量检查清单

生成诉状后，自查以下要点：

  • 诉讼阶段判断是否正确（一审/二审/再审）
  • 当事人称谓是否与诉讼阶段匹配
  • 诉讼请求是否明确、具体、可执行
  • 事实与理由是否采用三段论结构
  • 法条引用是否完整且格式正确
  • 管辖法院是否正确
  • 落款格式是否规范
  • 二审是否注明上诉范围和原审案号
  • 再审是否援引法定事由
  • 排版是否符合规范要求

注意事项

  1. 不重复分析：诉状应当是攻防分析结论的"表达层"，避免在诉状中展开过于详细的法律论证
  2. 语言风格：正式、精炼、逻辑清晰，避免口语化表达
  3. 事实叙述：客观陈述，不带主观评价，以时间顺序为主线
  4. 请求精确：金额精确到元，行为请求具体到可执行
  5. 留白策略：先尝试通过 MCP 自动填充（工商信息后端查职务、案件管家查法院/案号），仅在后端均不可用时才使用 [待填写] 占位并提示用户补充

下一步建议

诉状完成后，根据案件进展可继续：

  • 举证准备 → /evidence-index 按要件结构编排证据清单
  • 财产保全 → /asset-discovery 调查被告可供执行的财产
  • 程序性文书 → /procedural-documents 起草立案所需的其他程序材料（如保全申请、调查令申请）
  • 文书校验 → /legal-verification 已在闸门阶段自动执行，如需单独复核可手动调用

输出示例（结构参考）

# 民事起诉状

**原告**：[当事人信息]

**被告**：[当事人信息]

## 诉讼请求

1. [请求事项一]
2. [请求事项二]
3. 本案诉讼费用由被告承担。

## 事实与理由

[案件事实叙述]

[法律适用论证]

综上所述，原告的诉讼请求事实清楚、证据充分、于法有据，
恳请贵院依法支持原告的全部诉讼请求。

此致
[法院名称]

具状人：
年 月 日

附：1. 本状副本X份
    2. 证据材料X份

知识库调用（按 profile.md 知识库注册表）

文书生成过程中按案由定向检索知识库，增强法律论证的准确性和专业性。

环节目标知识库调用方式
法律依据检索按 profile.md 注册表KB.retrieve(query="<案由> <条文号>")
程序设计civil-procedureKB.retrieve(query="<程序事项>")
完成后沉淀B区 case-notes推荐"沉淀到办案笔记"

降级：CLI 不可达 → 本地 ${KB_ROOT}/*/knowledge-base/（外部知识库根目录，可在 profile.md 中配置；未配置时套件跳过本地降级） Read/Grep，标注 [KB:降级-本地]。

Verification

生成完成后确认：

  1. 文档结构完整（标题至落款无遗漏）
  2. 诉讼阶段与文书类型匹配
  3. 核心论证来源于要件攻防分析（非凭空发挥）
  4. Word文档成功生成且排版符合规范
  5. MCP校验结果已标注（通过/待校验）

案件管家联动（强制）

本 skill 完成产出后，必须在输出文档之前调用「案件管家」的台账回写协议，六步流程 / 降级 / 不阻塞规则统一由套件 Hub 维护：

协议单一权威源：skills/case-manager/references/downstream-writeback-protocol.md 入口条款：/case-manager SKILL.md §0.7

本 skill 的产出：起诉状 / 上诉状 / 再审申请书 / 仲裁申请书 md + docx

差异化字段回写：阶段进度 → 起诉状提交；下一步动作 → 立案跟进

What ships with it: 1 file

5.8 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most customer support skills give in ~5.0k tokens

Counted across 123 of the 124 authors here whose files we hold, read 2026-08-07

  • Call RUBE_SEARCH_TOOLS first to get current schemasin 12 of 123, across 4 files
  • Confirm connection status is ACTIVE before running workflowsin 12 of 123, across 4 files
  • Stop and ask for clarification if required inputs are missingin 9 of 123, across 2 files
  • Call RUBE_MANAGE_CONNECTIONS with the helpdesk toolkitin 9 of 123, across 2 files
  • Use both timestamp and ID for cursor navigationin 8 of 123, across 1 file
  • Implement backoff on 429 responsesin 8 of 123, across 1 file
  • Parse response data defensively with fallback patternsin 8 of 123, across 1 file
  • Use this skill only when the task clearly matches the scopein 8 of 123, across 1 file
  • Pass a JSON file as the positional argumentin 7 of 123, across 1 file
  • Specify output format with the --format flagin 7 of 123, across 1 file
  • Run health, churn, and expansion scripts togetherin 7 of 123, across 1 file
  • Verify output files contain expected records before continuingin 7 of 123, across 1 file

Said here and by no other author read

  • verify required inputs before generation
  • retrieve corporate party information via registry interface
  • identify procedure type and litigation stage
  • organize facts and reasons using syllogism
  • use template for document skeleton
  • append case progress to case ledger after drafting

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.