L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Productivité · SKILL.md

claim-chart

claim-chart

构建或审查要件分析表——专利权利要求对照表(侵权、无效或审查)或 民事构成要件分析表(任何诉讼请求或抗辩),每个单元格附精确引用, 缺口检测为优先输出。当用户要求要件分析表、权利要求对照表、 证据对照表、侵权或无效主张、逐要件映射,或问"我们证明[主张]还缺什么"时使用。

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: claim-chart description: > 构建或审查要件分析表——专利权利要求对照表(侵权、无效或审查)或 民事构成要件分析表(任何诉讼请求或抗辩),每个单元格附精确引用, 缺口检测为优先输出。当用户要求要件分析表、权利要求对照表、 证据对照表、侵权或无效主张、逐要件映射,或问"我们证明[主张]还缺什么"时使用。 argument-hint: '[--patent | --civil] [--infringement | --invalidity | --review] [--claim ] [--count ] [--target ]'

/claim-chart

  1. 加载 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → 角色、工作成果标头、决策姿态、文件存储。
  2. 如果案件工作空间已启用,确认或选择活跃案件;加载 matter.md(立场、管辖、阶段、案件理论、诉状)。
  3. 遵循以下工作流和参考材料。
  4. 模式选择:
    • --patent → 专利权利要求对照表。需要专利号和至少一项主张的权利要求。子模式:--infringement(侵权)、--invalidity(无效)、--review(审查)。
    • --civil → 民事要件分析表。需要诉讼请求(或抗辩)和立场。
    • 无标记 → 询问用户选择哪种。
  5. 民事模式:参考技能目录中的 references/element-templates.md 获取基准要件列表。在映射前与用户确认控制性法律依据(法条或司法解释)。
  6. 专利模式:将主张的权利要求解析为要件,标记需解释的争议术语,适用任何已有的权利要求解释裁定。
  7. 将要件映射到目标(被控侵权产品/现有技术/证据材料/待审查的对照表)。每个单元格附精确引用。在写入任何以 =、+、-、@、制表符、回车符开头的单元格值之前,应用单引号前缀转义。
  8. 产生缺口列表(民事)或需要证据列表(专利)——优先输出。
  9. 按用户偏好写入 Markdown、CSV 和 Excel 或 Sheets。每个输出附工作成果标头。
  10. 如有活跃案件,写入案件的 claim-charts/ 文件夹;否则写入实务级 claim-charts/ 文件夹。如有活跃案件,追加一行至 history.md。
  11. 返回摘要:主张、目标、管辖、阶段、按状态统计的要件数、缺口列表、文件路径,提醒每个单元格均为调查线索。

要件分析表(Claim Chart)

一份分析表是草案,不是认定或主张

将其放在每个输出的顶部。不得删减。

本分析表是供律师分析和核实的草案,不是递交的主张、代理词、开庭陈述或法律意见。每个映射是律师必须对照来源核实的调查线索。所列要件来自法律条文、司法解释或权利要求的解析——适用管辖地的控制性法律依据可能不同且始终优先。缺口检测是证据收集或诉讼动议的起点;不是对案件事实的法律结论。

少标记一个缺口的风险是单向门——起诉时某个要件缺乏事实支撑、质证时某项主张没有证据、庭审时无法证明损害。多标记一个缺口是双向门——律师在审查中清除标记。默认倾向双向门。


案件上下文

检查实务级 CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗,跳过本段。如果已启用且无活跃案件,询问:"这是哪个案件的?" 加载活跃案件的 matter.md。将输出写入案件文件夹。


模式选择

在一切之前先问:

哪种分析表?

  1. 专利权利要求对照表——权利要求逐要件映射到被控侵权产品(--infringement)、现有技术(--invalidity)或第三方分析表(--review)。
  2. 民事要件分析表——诉讼请求(或抗辩)的构成要件映射到证据。用于起诉前审查、举证规划、庭审准备。

共同信息收集:

  • 立场。 主张方还是抗辩方?
  • 管辖地/法院。 省/直辖市和法院——适用法律和司法解释可能因地域不同。
  • 阶段。 起诉前、举证、庭审、上诉。
  • 既有分析表? 如为 --review,加载之。

模式一 —— 专利权利要求对照表

子模式

  • --infringement —— 权利要求要件 vs 被控侵权产品
  • --invalidity —— 权利要求要件 vs 现有技术(专利法第22条新颖性/创造性 [法条原文])
  • --review —— 审查他人制作的分析表

专利模式工作流

步骤1:解析权利要求

将主张的独立权利要求解析为编号要件。

  • 前序部分。 注明是否具有限定作用。
  • 过渡词。 "包括"(开放式)/ "由……组成"(封闭式)。
  • 要件按逗号/分号分隔,编号 [1a]、[1b]、[1c]。编号保持稳定——它是分析表的骨架。
  • 功能性限定(《专利审查指南》相关规定): 每个"用于[功能]的装置"——范围为说明书公开的结构加等同替代。
  • 从属权利要求——引用父权利要求;仅分析附加技术特征。

向用户展示解析结果。在映射前确认。错误的解析将污染以下每一行。

步骤2:权利要求解释检查

标记争议术语:

  • 说明书中定义或自创的术语
  • 审查历史中有修改、争辩或放弃的术语
  • 功能性语言("配置为""适用于""可操作以")
  • 相对术语("大体上""约")——清楚性风险

对于每个标记的术语,说明在哪种解释下映射成立、在哪种解释下不成立。

步骤3:映射

对于每个要件、每个目标:

  1. 寻找证据。 引证来源并精确定位。

  2. 逐字引用。 字符对字符。不转述。

  3. 表征映射类型:

    映射含义
    字面权利要求语言直接覆盖被控特征/现有技术公开
    等同功能-方式-结果实质相同或非实质性差异(侵权模式)
    部分部分要件存在
    未找到要件不存在
    需要证据现有材料无法判断
    依赖于权利要求解释取决于争议术语的解释
  4. 每个单元格的状态——已映射 / 已映射-等同 / 部分 / 未找到 / 需要证据 / 依赖于权利要求解释。

步骤4:从属权利要求——执行,不口头表示

对于每个主张的从属权利要求,产生实际的分析行。产生行,不产生"应该分析"的占位说明。

步骤5:间接侵权、共同侵权等

标记,不发表意见:

  • 间接侵权(教唆、帮助)
  • 共同侵权(《民法典》第1168条 [法条原文])
  • 故意侵权

步骤6:无效门槛(仅无效模式)

  • 新颖性(《专利法》第22条第2款 [法条原文]):全部技术特征在一份对比文件中公开
  • 创造性(《专利法》第22条第3款 [法条原文]):突出的实质性特点和显著的进步(发明)/ 实质性特点和进步(实用新型)
  • 清楚性(《专利法》第26条第3-4款 [法条原文])
  • 修改超范围(《专利法》第33条 [法条原文])

模式二 —— 民事要件分析表

将诉讼请求(或抗辩)的构成要件映射到证据。核心输出是(a)一张说明什么证据对应什么要件的分析表和(b)一份告诉律师缺什么的缺口清单。

工作流

步骤1:识别诉讼请求

  • 什么诉讼请求?(或抗辩?)如有多个,分别分析。
  • 哪一方?原告的请求权基础、被告的抗辩。
  • 哪个管辖地?省/直辖市和法院。构成要件和法律依据因管辖地而异。
  • 哪份诉状?加载起诉状/答辩状以便分析表追踪实际主张的内容。

步骤2:加载构成要件

  • (a) 从法律依据提取。 确定适用的法律条文或司法解释,解析为编号要件。
  • (b) 自定义。 用户定义要件,或粘贴法条/司法解释/诉状内容供解析。
  • (c) 抗辩事由。 同样支持诉讼时效、免责事由、过错相抵等抗辩要件的映射。

在映射前与用户确认要件列表。如用户管辖地有特定司法口径(例如某省高院的指导意见),主动提出。

步骤3:映射

对于每个要件:

  • 支持证据——什么证明这个要件?精确引用来源。
  • 逐字引用(证言或书面证据)。不转述。
  • 相反证据——什么指向另一方向?引用它。
  • 强度——强 / 中等 / 弱 / 无。
  • 每个单元格的状态——已支撑 / 部分 / 有争议 / 缺口 / 需要举证。

步骤4:缺口检测——核心输出

映射完成后,产生缺口列表。这是分析表的意义。

证据薄弱或无证据的要件: [列表]

  • 如果是主张方:这些缺口可能影响你的诉讼请求能否成立。
  • 如果是抗辩方:这些是你的突破点——请求方有责任证明每个要件;一个缺口就是一项抗辩。
  • 如果是举证阶段:这些是你的优先举证方向。

步骤5:阶段感知框架

  • 起诉前。 是否每个要件都有足够的事实支撑使其具有合理性?
  • 举证阶段。 对于每个 缺口 或 需要举证 要件——需要什么证据?
  • 庭审准备。 举证顺序、何种证据证明哪个要件、谁负责举证。

共用框架(两种模式)

输出

预置 ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md ## Outputs 中的工作成果标头。

Markdown 表格(始终输出)

每个诉讼请求/抗辩/专利权利要求每个目标一张表。

| [#] | 要件(逐字) | 证据支撑(精确引用) | 相反证据 | 强度 | 状态 | 已核实 |
|---|---|---|---|---|---|---|
| 1 | 合同成立 | [证据3, MSA §1] | 无 | 强 | 已支撑 | ☐ |
| 2 | 原告履行 | [声明 ¶ 4-9] | [质证意见] | 中 | 有争议 | ☐ |

后续附:

  • 缺口列表——优先输出
  • 最强要件、最弱要件总结
  • 结论行——"本技能不下结论。" 要件已支撑:[列表]。要件需要证据/处于缺口状态:[列表]。

CSV(始终输出)

每个分析表两个文件:

  • [slug].csv —— 值
  • [slug]_sources.csv —— 逐字引用、精确引用、备注

文件名和位置

  • 专利侵权:claim-chart-infringement-[专利号]-claim[#]-[target]-YYYY-MM-DD.{md,csv,xlsx}
  • 民事:element-chart-[count-slug]-[side]-YYYY-MM-DD.{md,csv,xlsx}

本技能不做什么

  • 它不下结论。 不认定侵权,不认定不侵权,不认定责任。
  • 它不决定权利要求解释(专利)或控制性构成要件(民事)。 它标记争议术语/基准要件并在声明的假设下分析。
  • 它不替代专业分析。 技术专家、损害赔偿专家是独立的工作成果,本分析表引导至它们,不替代。
  • 它不递交、不签署任何东西。 每个输出都是草案。
  • 它不推测。 如果没有证据,单元格就是 需要证据 / 缺口——绝不猜测。
Skills enregistrées