Add some Liquid Enchantment recipes and fix crashing 添加液态魔咒配方并修复崩溃

[QiuShui1012]

• resolved [TODO] 液态魔咒配方增加 #4340
• fixed [Bug] 装有液态魔咒的储罐无法被Jade显示 #4346
• 重构了 HasCauldron 的部分逻辑
• 修改了液态魔咒的渲染颜色

[Gugle2308]

分析完成。所有关键文件已审查，CI（build + checkstyle）均通过。以下为审查意见：

---

代码审查摘要 — PR #4353

操作: opened
范围: 100 个文件（37 Java, 21 新增, 0 删除）/ 5643 行 diff
CI: build ✅ / checkstyle ✅（GitHub Actions 均通过，编译与数据生成已验证）

📋 声称验证表

声称	状态	对应文件
resolved #4340 液态魔咒配方	✅	SolidLiquidRecipeLoader.liquidEnchantment() + 9 个新 recipe JSON + 9 个新 advancement JSON（channeling / disintegration / felling_and_harvest_and_beheading / fire_protection / fortune_and_looting / frost_walker / mending / silk_touch / smelting）
fixed #4346 崩溃	✅	ModComponents.LIQUID_ENCHANTMENT Holder→ResourceKey；LiquidEnchantmentUtil.getEnchantment 改用 CommonHooks.resolveLookup 解析；TranscendenceGrindstoneMenu/LiquidEnchantmentJeiRecipeUtil 同步迁移。另附带 preview 路径 level == null 守卫、BucketPickupHandlerWrapper DataFlowIssue 标注等崩溃防护
重构 HasCauldron	✅	HasCauldron + HasCauldronSimple 全面重构：fluid → FluidStackPredicate、transform/produce → List<FluidStack> transforms（支持多输出）、移除 fluidTag、codec/stream codec 重写、EMPTY/NULL 哨兵值移除

🔴 关键

未发现阻断性问题（编译、checkstyle、生成数据一致性均通过）。

⚠️ 警告

• ConcreteRecipeLoader.initCementStaining + exp_fluid_cauldron — 部分填充大锅的行为回归。 旧代码在 applyFluidPredicate 中有 consume==0 && produce==0 的"纯流体类型交换"分支（注释明确写着"水泥染色例外，允许通过"），重构后该分支被删除，datagen 改为 consume(1000) + transform(xxx, 1000)。结果：大锅中液体 < 1000mb 时染色/转换配方不再匹配（test() 中 afterConsume != 0 且流体类型不同 → 否决）。旧行为是任意液量同量交换（500mb 灰水泥 + 染料 → 500mb 白水泥）。影响 16 个 cement_staining/* + exp_fluid_cauldron。请确认是否故意要求满锅；若非本意，建议保留"同量交换"语义（如 transforms 带 0 数量标记或加回交换分支）。
• HasCauldron.Builder 与 HasCauldronSimple.Builder 的 transform() 行为不对称。 Simple 版在 requiresEmptyCauldron() 时会把 fluid 从 EMPTY_PREDICATE 升为 ANY（保留旧语义：向空锅产液），而 HasCauldron.Builder.transform() 没有这个转换 → HasCauldron.builder().empty().transform(...) 会构造"要求空锅 + 产出流体"的矛盾谓词：大锅路径 findSourceTank 因 requiresEmptyCauldron() 返回 -1、hasCheck() 为 true → 永不匹配。当前仓库内无此调用组合，但两个 API 语义不一致容易踩坑，建议统一。
• 旧格式 datapack 配方不兼容（破坏性格式变更）。 transform 从字符串 ID 变为 {id, amount} 对象/数组，produce、fluidTag 字段被移除，"fluid": "minecraft:null" 哨兵值不再解析。玩家/第三方 datapack 中的旧格式 solid_liquid / squeezing / super_heating / time_warp 配方会加载失败。预期中的变更，但建议在 PR 描述和更新日志中明确声明。
• 液体附魔配方在块级炼药锅上执行会静默丢失附魔（边角路径）。 accept() 的块级路径（无 IFluidHandler）只 setBlock（applyFluid else 分支），transform 的 LIQUID_ENCHANTMENT 组件无处存储。若 IIgnitableCauldron 类锅块中恰好装有 amount == consume 的空白液态魔咒（如 1mb 空白 LE + 绿宝石），配方会通过 test 并消耗物品，但产物只是普通 LE 锅块——mending 等附魔不会出现。仅大锅（8 罐）路径正确。建议对携带组件的 transform 配方在 test() 中要求 ICauldron.supportsMultipleFluidOutputs() 或直接排除非 ICauldron 目标。
• LargeCauldronBlock.isLadder 移除了 entity != null 守卫。 新代码直接 entity.getBoundingBox()，若任何调用方（含第三方 mod）以 null 实体调用会 NPE。旧代码有显式守卫，建议保留。

💡 建议

• SolidLiquidRecipeLoader.liquidEnchantment() — amount / enchantments.length 在不能整除时静默损失余数；each == 0 时 transform 为空列表（被 record 构造器过滤），配方会"吞物品零产出"。当前 9 个配方数值均可整除，无实际问题，但建议在 each <= 0 时抛异常防未来踩坑。
• MDBaseAnvilRecipeComponent.getDisplayedElement — elements.size() 无空列表保护（除零/越界）。当前三个调用方均已判空，建议方法内加守卫。
• AbstractProcessRecipe.getPriority — hasAnvil != HasAnvil.DEFAULT 对 null 也计 1（旧逻辑 null 计 0）。由于所有配方统一 +1，相对排序不变，但建议确认 hasAnvil 为 null 时语义是否应为 0。
• RecipePass.accepts→rejects、applyPreviewPredicate→rejectsPreviewPredicate 等"改名+取反"重构已逐一核对等价（含 HasAnvil 双重取反、isFluidOnlyRecipe→isNotFluidOnlyRecipe），逻辑正确，但此类重构易在后续维护中出错，建议后续补测试覆盖。

🟢 看起来不错

• [Bug] 装有液态魔咒的储罐无法被Jade显示 #4346 修复方案正确：数据组件存 ResourceKey 而非 Holder，规避了注册表重载/跨上下文序列化时 Holder 绑定失效的崩溃；使用处通过 resolveLookup 解析并 Optional 回退（附魔被移除的存档 → 视为空白 LE，安全降级）。
• FluidStackPredicate / DataComponentPredicate 设计清晰：negate 语义实现正确（逐条件短路返回 isNegate），CODEC 兼容单流体/列表/标签三种形态（either(INLINE, FULL)），"fluid": [] ↔ ANY、{"amount": 0} ↔ EMPTY_PREDICATE 往返一致（已在生成的 supercapacitor.json、squeezing/* 中验证）。
• 多流体输出全链路贯通：applyFluidPredicate 逐 transform 分配罐（findTank 按 isSameFluidSameComponents 区分附魔变体）、JEI 网格布局（addOutputSlots + 槽位命名去重 name/index）、MD 文档轮播（getDisplayedElement）、预览绘制（drawFluidOutputSlots(size)）一致。
• 生成 JSON 与 loader 完全同步（9 新配方 + 9 advancement + 全部旧配方迁移）；LiquidEnchantmentUtil 的 isBlank/isEnchanted/isCursed/getColor 在组件类型变更后语义保持。
• preview 的 level == null 守卫修复潜在 NPE；Math.clamp 替代手写 clamp；死代码清理干净（findEmptyTankAfterRemoving、getCurFluid(BlockCache, BlockPos) 公共重载等）。

🧪 测试建议

被测目标	推荐测试场景	优先级
HasCauldron / HasCauldronSimple codec	JSON + stream codec 往返：单 transform、多 transform、tag 流体、component 谓词、negate、ANY/EMPTY	🔴
applyFluidPredicate	多输出配方：空罐不足、目标罐已有同附魔流体（合并）、consume 后剩余	🔴
水泥染色 / exp_fluid_cauldron	部分填充（<1000mb）大锅行为——回归验证点	🔴
LIQUID_ENCHANTMENT 组件	序列化往返、未知附魔 key 回退为空白	🟡
LiquidEnchantmentUtil.getEnchantment	客户端/服务端 resolveLookup null 安全性	🟡

结论: COMMENT — 核心重构质量高，#4346 崩溃修复方案正确，#4340 配方完整落地，CI 全绿。主要需作者确认两点：① 染色/转换配方"部分填充不再工作"是否为有意行为变化；② 附魔配方在块级炼药锅上丢失附魔的边角路径是否需要防护。无阻断性缺陷，确认后可合并。

---

由 Hermes Agent 审查

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'minecraft-modding' (1 replacement).

[Gugle2308]

分析完成。所有关键路径(谓词语义、多重否定反转、编译一致性、JSON 格式迁移)都已核对。以下是审查意见:

---

代码审查摘要 — PR #4353

操作: synchronize/edited (webhook)
范围: 102 个文件 (38 Java, 62 JSON, 2 gradle) / 5739 行 diff
新增: 22 (3 Java: FluidStackPredicate、DataComponentPredicate、ICauldron;9 液态魔咒配方 + 9 对应 advancement JSON + 若干其他)
删除: 0

概览

这是 HasCauldron 谓词的大重构:ResourceLocation fluid/transform + produce + fluidTag 四个字段合并为 FluidStackPredicate fluid + List<FluidStack> transforms,支持多流体输出(液态魔咒配方需要一进多出);同时把 LIQUID_ENCHANTMENT 组件从 Holder<Enchantment> 改为 ResourceKey<Enchantment>(修复 #4346 Jade 显示崩溃),并重写了液态魔咒的渲染混色。已拉取 PR 头分支 pr4353 做了全量跨文件一致性核对,旧的 HasCauldron.EMPTY/NULL/isNotEmpty/fluidTag/produce() API 无残留,生成 JSON 与新旧 codec 往返一致。

🔴 关键

未发现编译错误或明确的逻辑错误。FluidStack.is(HolderSet) 在 NeoForge 21.1 存在(编译通过),SizedFluidIngredient.getFluids() 返回 FluidStack[](List.of(...) 展开正确),BuiltInRegistries.FLUID.get("minecraft:empty") 解析到 Fluids.EMPTY(非 null,空锅路径不崩)。RecipePass.accepts→rejects、isFluidOnlyRecipe→isNotFluidOnlyRecipe、applyPreviewPredicate→rejectsPreviewPredicate 三处布尔反转逐一验证均为正确对偶。

⚠️ 警告

1. 水泥染色 / 经验液配方行为变化:现在要求满锅 — ConcreteRecipeLoader.initCementStaining 与 exp_fluid_cauldron 新增了 consume(1000)。旧配方是 consume=0/produce=0 的"保量换液"语义(1/3、2/3 满的锅也能染色,数量不变),新语义要求锅 ≥1000mb,不满即拒绝(test() 中 consume > cur → return false)。若是刻意简化语义请忽略,否则属隐性玩法回归。

2. getCurFluidStack 对未知方块有 NPE 隐患 — HasCauldron.java:300-306:非 IIgnitableCauldron 的方块走 BuiltInRegistries.FLUID.get(WrapUtils.cauldron2Fluid(block)),若第三方模组的 cauldron 标签方块名字解析不到流体 → new FluidStack(null, amount)(amount>0 时 isEmpty() 为 false)→ 后续 stack.is(HolderSet) → getFluidHolder() → null.builtInRegistryHolder() NPE。旧代码只做 ResourceLocation 字符串比较,不会崩。建议在解析处加 Fluids.EMPTY 兜底。

3. 配方格式为破坏性变更,旧数据包会静默失效 — 旧 JSON 的 "fluid": "minecraft:null"、裸字符串 "transform": "anvilcraft:oil"、"produce": 250 在新 codec 下全部解码失败(配方直接不加载)。内置 JSON 已全部重新生成 ✓,但建议在更新日志中注明"需重新生成/更新数据包"。

4. HasCauldron codec 默认值语义变化 — optionalFieldOf("fluid", EMPTY) → FluidStackPredicate.ANY:缺省从"必须空锅"变成"不检查流体"。仓库内 in-world 配方 JSON(item_compress、neutron_irradiation、time_warp)已显式写出 "fluid": {"amount": 0} 保持空锅语义 ✓,但旧数据包中省略 fluid 字段的配方行为会变。

5. 液态魔咒配方数量取整是隐式假设 — SolidLiquidRecipeLoader.liquidEnchantment:int each = amount / enchantments.length,当前 9 条配方全部整除(12/3、128/2、8/1…),但若未来改动数量导致不整除,产出会少于消耗且无任何校验。建议改为显式断言或余数处理。

💡 建议

• getDefaultCauldron(Fluid) 对 Fluids.EMPTY 会落到 Blocks.WATER_CAULDRON(旧代码对 empty 标记返回 Blocks.CAULDRON)。当前调用方都做了非空守卫,但 "fluid": "minecraft:empty" 旧数据包会导致 tooltip/MD 渲染成水锅,建议补上 EMPTY 特判。
• HasCauldronSimple.Builder.transform() 的 EMPTY→ANY 重置(HasCauldronSimple.java:180)与 HasCauldron.Builder.transform() 行为不对称,且该重置是"空锅+转换"矛盾时静默放弃空锅校验——建议加注释说明依赖 swap 规则兜底,防止后人误删。
• getDisplayedElement 对空列表会 % 0 除零,当前调用方均先判空,建议内部防御。
• LiquidEnchantmentUtil.getEnchantment 中 Objects.requireNonNull(CommonHooks.resolveLookup(...)) 在客户端早期调用可能 NPE,目前只在渲染期调用,建议改为兜底 Optional.empty()。
• PR 描述声称 resolved #4340,但该 issue 状态仍是 open,建议顺手关闭或修正描述。

🟢 看起来不错

• [Bug] 装有液态魔咒的储罐无法被Jade显示 #4346 修复方向正确:组件改存 ResourceKey + CommonHooks.resolveLookup 动态解析,规避了 Holder 跨 registry 失效导致的 Jade 崩溃;旧存档里以 ID 字符串形式保存的数据仍可解码,兼容性良好。
• 多流体输出设计严谨:ICauldron.supportsMultipleFluidOutputs() 门控 + hasMultipleFluidOutputs 前置否决,普通炼药锅不会误触多输出路径;applyFluidPredicate 的模拟/快照/提交(snapshot/rollback/commit)链完整。
• 液态魔咒配方数值自洽:每条 consume = 各 transform 之和,且 blank(expectNull 组件谓词)匹配逻辑正确。
• 渲染混色的 soft-light/overlay 公式是标准合成算法,参数交换(blend/base)有注释说明。
• Jade 15.3.4→15.10.5、Gradle 8.13→8.14.5 升级无异常;重构后 @SuppressWarnings 标注克制。

📋 声称验证表

声称	状态	对应文件
新增液态魔咒配方 (resolved #4340)	✅	SolidLiquidRecipeLoader, 9 个新 solid_liquid JSON + 9 个 advancement
修复崩溃 (fixed #4346)	✅	ModComponents(LIQUID_ENCHANTMENT→ResourceKey), LiquidEnchantmentUtil, TranscendenceGrindstoneMenu, Jade 版本升级
重构 HasCauldron 逻辑	✅	HasCauldron, HasCauldronSimple, FluidStackPredicate, DataComponentPredicate, ICauldron
修改液态魔咒渲染颜色	✅	LiquidEnchantmentClientFluidTypeExtension (soft-light/overlay 混色)

🧪 测试建议

被测目标	推荐测试场景	优先级
HasCauldron.test()	满/半/空锅 × 消耗/转换组合;空锅谓词({"amount":0});多输出配方落在普通锅上被否决	🔴
LargeCauldronBlockEntity.applyFluidPredicate	多输出配方在已有同种流体罐上的合并、容量溢出拒绝	🔴
FluidStackPredicate.test()	negate 与 fluids/components/amount 各组合的真值表	🟡
SolidLiquidRecipeLoader 生成配方	每种液态魔咒 consume==Σtransform、整除性	🟡
序列化往返	HasCauldronSimple/HasCauldron codec ↔ stream codec 一致;旧存档 liquid_enchantment 组件解码	🟡
LiquidEnchantmentClientFluidTypeExtension	普通/附魔/诅咒三类流体的混色输出值	🟢

结论: COMMENT(有条件通过) — 核心重构质量高、一致性强,未发现阻断性问题。建议处理 ⚠️2(未知方块 NPE 兜底)与 ⚠️1/3(行为变更与数据包兼容性确认)后合并。

---

由 Hermes Agent 审查(webhook 自动发布)

[Gugle2308]

分析完成。所有 38 个 Java 文件与 62 个生成资源已审查，并与 merge-base 4733c6dd3、PR head 7f866b00e 及目标分支交叉验证。以下为审查意见：

---

代码审查摘要 — PR #4353

操作: synchronize
范围: 102 个文件（38 Java，21 新增，0 删除）/ 5739 行 diff
提交: 4 个（HasCauldron Fluid 化迁移 → 新增液态魔咒配方 → 崩溃修复 #4346 → 魔咒液色调变更）

变更概览

• [TODO] 液态魔咒配方增加 #4340（已解决）：新增 10 个液态魔咒配方（silk_touch / disintegration / smelting / fortune_and_looting / mending / fire_protection / frost_walker / channeling / felling_and_harvest_and_beheading）+ 对应解锁 advancement。输入=空白液态魔咒（组件谓词 !anvilcraft:liquid_enchantment）+ 材料，输出=带魔咒组件的液态魔咒；多魔咒配方（如 transcendium→fortune+looting）输出多个流体栈
• [Bug] 装有液态魔咒的储罐无法被Jade显示 #4346（已修复）：LIQUID_ENCHANTMENT 组件类型从 Holder<Enchantment>（配 Enchantment.CODEC）改为 ResourceKey<Enchantment>（配 ResourceKey.codec(Registries.ENCHANTMENT)）
• HasCauldron 重构：fluid 从 ResourceLocation → FluidStackPredicate（支持 tag/组件/数量/取反），transform+produce 合并为 List<FluidStack> transforms（多输出），删除 fluidTag；新增 ICauldron 接口 + HasCauldronSimple 同步迁移 + 全部 37 个调用文件更新

🔴 关键问题

无阻断性问题。所有逻辑反转（RecipePass.accepts→rejects、isFluidOnlyRecipe→isNotFluidOnlyRecipe、applyPreviewPredicate→rejectsPreviewPredicate）均逐一验证语义等价；applyFluidPredicate 多输出循环正确（同流体合并、异流体需空槽）；旧 API（getFluidCauldron/HasCauldron.EMPTY/isNotEmpty/fluidTag/hasCauldron(ResourceLocation)）在 PR head 上已无残留调用。

⚠️ 警告

1. ConcreteRecipeLoader.initCementStaining — 水泥染色行为回归：染色配方从"移动锅内全部水泥量"改为硬编码 consume(1000) + transform(水泥色, 1000)。

   • 旧逻辑（consume==0 && produce==0 特殊分支）会把任意量的水泥整体转换（500mb 水泥 → 500mb 染色水泥）；
   • 新逻辑要求锅内 ≥1000mb 才能执行（部分填充的水泥锅无法再染色），且 >1000mb 时只转换 1000mb 留下残余。
   • 若这是有意的（消费显式化），建议在 PR 描述中注明；否则建议改为按当前量转换。

2. LiquidEnchantmentUtil.getEnchantment — 新增 NPE 点：Objects.requireNonNull(CommonHooks.resolveLookup(Registries.ENCHANTMENT))。旧实现直接返回组件内的 Holder，无需注册表解析。新实现若在无 level/registry 上下文时调用（如主菜单阶段的 JEI 渲染早期路径）会抛 NPE。当前调用点（流体 tint 渲染、LiquidEnchantmentCauldronRecipe.match、TranscendenceGrindstoneMenu）均有 level 上下文，风险低，但建议加 Optional.ofNullable 防御。

3. 存档格式变更注意：组件 codec 从 Enchantment.CODEC 改为 ResourceKey.codec。旧 codec 与 Holder<Enchantment> 值类型不匹配（这很可能正是 [Bug] 装有液态魔咒的储罐无法被Jade显示 #4346 崩溃根因——Enchantment.CODEC 无法编码裸 ID 字符串，也无法从字符串解码），所以旧数据大概率本就无法持久化；新格式（字符串 ID）与 JSON/FluidStack.CODEC 存储一致。修复方向正确，但若 1.6 有早期测试存档，含液态魔咒的槽位可能无法加载——确认无需迁移即可。

💡 建议

4. HasCauldron.test() 多输出仅校验 transforms().getFirst()（!isSameFluidSameComponents(curFluid, transforms[0])）：第二个及后续输出与锅内容的关系未检查。当前多输出配方在 vanilla 锅路径已被 supportsMultipleFluidOutputs 门控拦截、仅 LargeCauldron 可达（走 testFluidRecipe），所以不会出错，但建议加注释说明该检查仅对单输出有效。

5. HasCauldronSimple.Builder.transform() 的 EMPTY→ANY 翻转：构建器语义（加 transform 后不再要求空锅）依赖生成的 "fluid": [] 显式序列化才能保持运行时一致。已确认生成的 squeezing/super_heating/time_warp JSON 均含 "fluid": []（=ANY），且旧版同样用 "minecraft:null" 显式编码——行为等价 ✅。但任何手写/第三方配方省略 fluid 字段会落到 CODEC 默认 EMPTY_PREDICATE（"必须空锅"），与旧版默认 EMPTY 一致，无回归，仅提醒文档化。

6. MDBaseAnvilRecipeComponent.getDisplayedElement：% elements.size() 在空列表时除零。当前 4 个调用点均已先判 isEmpty()，安全；作为 protected 公共方法建议内部防御。

7. 无关依赖升级混入：jade 15.3.4→15.10.5、gradle wrapper 8.13→8.14.5 与配方主题无关，若为 rebase 带入可忽略，否则建议单独 PR。

8. 生成 JSON 无尾换行（63 处 \ No newline at end of file）：数据生成器输出风格，与旧文件一致，非异常。

🟢 看起来不错

• 崩溃修复正确且彻底：组件类型 + SolidLiquidRecipeLoader + TranscendenceGrindstoneMenu（data.enchantment().getKey()）+ LiquidEnchantmentUtil + 两处 JEI 工具类全部同步为 ResourceKey，无遗漏
• FluidStackPredicate 设计完整：inline（字符串/tag/list）/full（fluids+components+amount+negate）双 codec 形态，test() 的 NAND 式取反语义一致；"fluid": [] 与 {"amount": 0} 均正确往返
• 多输出架构门控合理：ICauldron.supportsMultipleFluidOutputs() 默认 false，仅 LargeCauldron（Block + BE 双向实现）支持多输出；vanilla 锅被 test() 提前拦截，accept() 只应用第一个 transform 的路径实际不可达
• 防御性改进：getRecipePreviews/targetsThisCauldron/HasBlockBase 增加 level null 检查；WrapUtils.getItem 增加 @Nullable 守卫；interactWithFluid 用 Math.clamp 等价替换
• 数据一致性：生成的配方 JSON 与 codec 格式逐项核对一致（transform 单对象/列表、patch 的 ! 移除格式、ResourceKey 字符串编码）

📋 声称验证表

声称	状态	对应文件
resolved #4340（液态魔咒配方）	✅	10 个新 solid_liquid/*.json + advancements + SolidLiquidRecipeLoader.liquidEnchantment()
fixed #4346（崩溃）	✅	ModComponents.LIQUID_ENCHANTMENT（Holder→ResourceKey）、LiquidEnchantmentUtil、TranscendenceGrindstoneMenu、JEI 工具
重构 HasCauldron	✅	HasCauldron、HasCauldronSimple、FluidStackPredicate、DataComponentPredicate、ICauldron + 34 个调用方同步

结论: APPROVE（附警告 1、2 请确认）

🧪 测试建议

被测目标	推荐测试场景	优先级
HasCauldron.applyFluidPredicate	多输出（fortune_and_looting）：空槽不足、同流体合并、部分填充水泥染色（<1000mb 应拒绝）	🔴
SolidLiquidRecipeLoader.liquidEnchantment	生成 JSON 与 codec 往返解析；空白 LE 输入谓词（! patch）匹配/不匹配	🔴
LiquidEnchantmentUtil.getEnchantment	无注册表上下文（null lookup）时行为	🟡
LargeCauldronBlockEntity RecipePass 反转	压缩/非压缩配方在 ALL/NON_COMPRESSION/COMPRESSION_ONLY 三态下的过滤等价性	🟡
TranscendenceGrindstoneMenu	data.enchantment().getKey() 为 null（未注册魔咒）时组件处理	🟢

---

由 Hermes Agent 审查（未运行 gradle 编译验证，基于 diff 静态分析 + merge-base/PR head/目标分支三方交叉核对）

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'minecraft-mod-pr-review' (1 replacement).

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'minecraft-mod-pr-review' (1 replacement).