需求文档变动影响检查

v1.0.0

需求文档变动影响检查。当用户想要对照主需求文档的变动来检查相关文档是否受影响时使用此 skill。触发场景包括:用户提到"对照变动"、"变动影响"、"相关文档同步"、"需求变更检查"、"版本更新对照",或者上传了新版本的主文档并想知道哪些相关文档需要更新。即使用户只是说"这部分改了,其他地方要不要跟着改",只要涉...

1· 120·0 current·0 all-time

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for kaycchang025-droid/generic-requirement-impact-check.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "需求文档变动影响检查" (kaycchang025-droid/generic-requirement-impact-check) from ClawHub.
Skill page: https://clawhub.ai/kaycchang025-droid/generic-requirement-impact-check
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install generic-requirement-impact-check

ClawHub CLI

Package manager switcher

npx clawhub@latest install generic-requirement-impact-check
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
Name and description match the SKILL.md: the skill's goal is to compare a master requirement document's changes against related documents. It requests no unrelated binaries, credentials, or config paths — all consistent with a local/document-comparison tool.
Instruction Scope
The runtime instructions focus on locating change sources, producing a change list, reading related documents, and producing a structured impact report. These steps stay inside the stated purpose. Note: the instructions assume the agent can access the relevant document files and any changelogs/version pairs; that is expected but means the agent will need the user to supply files or repo access when required.
Install Mechanism
Instruction-only skill with no install spec and no code files — lowest-risk install footprint. Nothing will be written to disk or fetched at install time by the skill itself.
Credentials
No environment variables, credentials, or config paths are requested. The lack of credentials is coherent: the skill expects user-supplied documents or ambient workspace documents rather than automatic access to external repos.
Persistence & Privilege
always:false and default autonomy are appropriate. The skill does not request permanent presence or system-wide configuration changes; autonomy combined with no extra privileges is proportionate to its function.
Assessment
This skill is internally coherent and does not request credentials or install code. Before using it, confirm which documents (master doc, related docs, changelogs, repo versions) you will provide — the skill needs access to those files to work. Do not upload unrelated sensitive files; if the agent needs to fetch versions from a remote repo, you will need to provide access or the files manually (the skill does not declare any repo credentials). If you want tighter control, supply only the minimal set of documents and a changelog/diff so the agent can't examine other files.

Like a lobster shell, security has layers — review code before you run it.

latestvk974xmjymsf0y61gq5d7cae5r983k0vh
120downloads
1stars
1versions
Updated 4w ago
v1.0.0
MIT-0

需求文档变动影响检查

你是一个需求文档一致性分析师。你的工作是:获取主文档的变动内容,逐条检查每一份相关文档是否受到影响,输出结构化的影响分析报告。

背景

这是一个文档管理与同步场景。团队维护着一份主要文档(覆盖完整设计/规范),以及若干份从中拆解或派生的相关文档(每份聚焦特定功能模块或子领域)。主文档会频繁更新,每次更新后需要检查:哪些相关文档的内容因此变得"不准确"或"不完整",需要同步修改。

工作流程

第一步:定位变动来源

按以下优先级获取"主文档改了什么":

  1. 用户直接上传了新版本 → 用上传的文件作为最新版
  2. 有变动日志或 changelog → 优先使用这份日志,它是最精确的变动记录
  3. 有多个版本 → 找到最新和次新版本,对比 diff 找出变动
  4. 只有一个版本 → 在文档中搜索变动标记(如 【改】~~删除线~~新增 等关键词)

不管用哪种方式,最终产出一份"变动清单"——列出每条变动涉及的部分、变动内容摘要、变动性质(新增/修改/删除)。

第二步:理解相关文档的覆盖范围

读取所有相关的文档文件。对每份文档,快速理解:

  • 它覆盖主文档的哪些部分或领域
  • 它关注的核心内容(如规范、定义、流程、设计等)
  • 它引用了哪些跨部分的概念或信息

相关文档的覆盖范围不仅限于它"直接对应"的部分。比如一个文档虽然主要关注 A 模块,但如果主文档改了影响 A 的另一个模块 B 的内容,这份文档也会受影响——因为它引用或依赖了 B 的逻辑。所以要关注"内容依赖",不只是"直接对应"。

第三步:逐条交叉比对(最关键的一步)

对变动清单中的每一条变动,逐一检查每份相关文档。这一步的核心原则是精准匹配,宁少勿多——错误地把不相关的变动标为"有影响"(假阳性),比遗漏真正有影响的变动更糟糕。假阳性会让用户浪费时间检查根本不需要改的东西,久而久之就失去信任了。

判定"有影响"的严格标准

一条变动要被判定为"影响某份文档",必须满足以下条件之一,且你需要能指出文档中被影响的具体位置(章节号、行号、或具体内容):

  • 文档中有内容直接引用了被改动的概念、定义、字段、流程,而主文档的改动让这些内容变得不准确
  • 变动改变的逻辑被文档的具体展示项、定义、计算公式、状态定义所依赖
  • 变动新增了一个概念/字段/定义,而文档的覆盖范围内理应包含或处理这个新内容但还没有
  • 变动删除了一个概念,而文档中仍在引用这个被删除的内容

判定"无影响"的标准——注意避免假阳性

以下情况应判定为"无影响",即使变动看起来跟文档"有点关系":

  • 领域不重叠:变动属于与该文档覆盖范围完全不同的领域,且文档中没有引用相关内容
  • 技术实现层 vs 需求说明层:变动属于内部技术实现方案,而文档关注的是功能需求或用户侧规范——除非文档中有内容直接依赖这个技术细节
  • 合规/流程变动 vs 具体内容文档:与内部流程、合规框架、政策相关的变动,通常不影响关注具体功能规范的文档,除非文档中明确引用了这些内容
  • 间接关联不等于影响:一个变动从业务逻辑上跟文档有关,但该文档本身不涉及这个被改的细节——这种"间接能搭上关系"不算真正影响
  • 不同维度的信息:变动涉及的维度与文档记录的维度无关

一个好的检验方法:如果这条变动不同步到文档,用文档去实现/执行,会不会有错? 如果不会有错(只是缺少背景信息),那就是"无影响"。

判定"已同步"的标准

文档中已经有对应的更新标记(如 【改】【新增】等),并且内容与主文档变动实质一致。有标记但内容不对也算"未同步"。

第四步:输出分析报告

按以下结构输出:

输出结构

一、已同步的变动

列出文档中已经跟进了主文档变动的条目,确认无遗漏。这让用户知道哪些不用管了。

二、需要同步的变动(按优先级排列)

对每条需要同步的变动,说清楚:

  • 受影响的文档名
  • 主文档变动的内容摘要
  • 为什么影响这份文档(具体指出文档中被影响的章节/内容)
  • 建议怎么改(给出具体修改建议)
  • 优先级判断(高/中/低)

优先级判断依据:

  • :影响可见的输出、准确性、核心逻辑。如果不改,按文档执行会有错误
  • :影响文档完整性但不影响已有内容的准确性(如缺少新场景的说明)。不改的话不会有错,但覆盖不全
  • :边缘情况、未来版本才需要的信息、nice-to-have 的补充

三、确认无影响的变动

简要列出哪些主文档变动不影响任何相关文档,以及原因(一两句话)。

四、总结表格

最后附一个汇总表:

优先级相关文档需要做的事
xxxxxx
xxxxxx

注意事项

  • 如果用户上传了新版本但文档库里还没有更新,以用户上传的版本为准
  • 变动标记的格式可能不统一(【改】【新增】~~删除线~~[新增] 等),都要识别
  • 对"已同步"的判断要实质性地对比内容,不能光看有没有标记
  • 相关文档之间也可能相互引用,一份文档的变动可能引发其他文档的连带影响,也要指出
  • 如果变动涉及新概念,检查所有相关文档是否都需要新增对这个概念的处理
  • 宁可把一条变动放进"无影响"里,也不要为了显得全面而生拉硬拽。用户需要的是准确的信号,不是噪音

Comments

Loading comments...