인터페이스는 현지화되어 있으며, Skill 소개와 설명 문서는 선택한 언어로 AI가 자동 번역합니다. 코드·명령어·경로·전문 용어는 원문을 유지하며 원작자 문서가 우선합니다.
Skills 둘러보기
생산성 및 협업 · SKILL.md

claim-chart

claim-chart

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

Independent GitHub snapshot · Automated classification · Original documentation governs

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