菜单
在 SlimefunHelper 中新增或改造模块配置屏幕时，统一复用 `WidgetUtils` 的配置屏幕组装链，而不是在模块里重复手写 `DynamicListWidget + RefKeyValueInputWidget`。用于把 `BaseModule` 的 `editableConfig`、显示条件、模块标题、主题色和自定义 widget 接到同一条打开链路上。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Analyze server-side block interaction flow around ServerPlayerInteractionManager.interactBlock, BlockState.onUseWithItem/onUse, ItemStack.useOnBlock, and BlockItem.useOnBlock in this merged Yarn Minecraft tree. Use when tracing whether right-clicking a block can fall through into item use or block placement, when classifying PASS vs PASS_TO_DEFAULT_BLOCK_ACTION behavior, or when summarizing special interactable block families.
理解并维护 SlimefunHelper 中 `ElytraExtra.applyAxisLimit2` 的 Elytra 烟花容错盒、两帧 look 叠加、目标逼近与爬升策略选择。用于分析 `currentMotion = currentRotation * 1.7` 一类上推方案，判断斜向追点、竖直拉升、前后折返等 rotation 序列的收益与约束。
Grim 中 Elytra 预测、烟花容错、offset 判定与 setback 回滚的结果逻辑。用于直接回答滑翔检测、fireworksBox、1.7 来源与拉回后高速原因。
在 SlimefunHelper 中兼容多个 Baritone 发行形态，尤其是“全混淆”版本。用于区分无混淆、仅方法混淆、类与方法全混淆三种形态，并决定 MixinPlugin、目标类定位、成员定位、反射桥接和 hooks 访问层该如何拆分。
理解并维护 SlimefunHelper 中 `NBTType`、`NBTParsable`、`NBTRef`、`AttrKeyValue` 的自动配置链。用于分析或新增 NBT 配置类型时，追踪它如何在字符串、原始对象、NBT、Ref、可编辑 GUI 之间自动转换，并据此实现新的 `NBTParsable` / 组合型配置结构。
为 SlimefunHelper 新模块补全 BaseModule 基础注册骨架。用于创建或改造模块时，统一完成模块名、ModulePath、Flag 绑定、不同类别 Ref、监听器、常用监听器、热键和命令注册。
| name | gui-optimization |
| description | 在 SlimefunHelper 中新增或改造模块配置屏幕时，统一复用 `WidgetUtils` 的配置屏幕组装链，而不是在模块里重复手写 `DynamicListWidget + RefKeyValueInputWidget`。用于把 `BaseModule` 的 `editableConfig`、显示条件、模块标题、主题色和自定义 widget 接到同一条打开链路上。 |
| disable-model-invocation | true |
把模块配置屏幕的职责收口成一条稳定链路：
BaseModule.getEditableConfig()WrapperConfigRef.showPredicate()BaseModule.addCustomWidgets(...)me.matl114.gui.WidgetUtilsClickGui.openConfigurateScreen(...) / MainTasks.openModuleScreen(...)结果要求：
WidgetUtils 统一组装DynamicListWidget、SubScreenWidget、RefKeyValueInputWidget优先阅读这些文件：
src/main/java/me/matl114/gui/WidgetUtils.javasrc/main/java/me/matl114/hacks/modules/task/ClickGui.javasrc/main/java/me/matl114/hacks/MainTasks.javasrc/main/java/me/matl114/hacks/api/BaseModule.javasrc/main/java/me/matl114/gui/complex/config/RefKeyValueInputWidget.javasrc/main/java/me/matl114/gui/basic/DynamicListWidget.javasrc/main/java/me/matl114/gui/basic/DynamicContentWidget.javasrc/main/java/me/matl114/gui/basic/SubScreenWidget.javasrc/main/java/me/matl114/gui/elements/ColorLabelTextElement.java模块配置屏幕不是自己扫描配置树，而是直接消费 BaseModule 已注册好的可编辑项：
registeredConfigEditableRefsgetEditableConfig()addCustomWidgets(...)这意味着：
show(...) / hideConfig() 等方式挂在 WrapperConfigRef.showPredicate() 上统一由 WidgetUtils.createConfigScreen(...) 负责把这些数据拼成界面。
默认结构是：
每个配置行的宽度固定遵循：
totalWidth = indexWidth + blankWidth + buttonWidth
默认布局：
indexWidth = 140blankWidth = 10buttonWidth = 180buttonHeight = 18buttonBlank = 2每个配置行都维持同一模型：
SubScreenWidgetDisplayWidget 占位，保证整行 hover / click 区域稳定RefKeyValueInputWidget 负责 value 编辑DynamicContentWidget 负责根据 showPredicate 决定整行是否出现不要把显隐逻辑塞进子控件内部；行级显隐统一放在 DynamicContentWidget。
WidgetUtils 里把样式拆成两块：
ConfigScreenLayoutConfigScreenPalette其中 ConfigScreenPalette 只负责四个颜色来源：
这样 ClickGui 只需要提供主题色，不需要自己拼具体 widget。
统一入口顺序：
ClickGui.openConfigurateScreen(BaseModule)WidgetUtils.openModuleConfigScreen(...)WidgetUtils.createModuleConfigScreen(...)WidgetUtils.createConfigScreen(...)CenterScreen如果未来有别的地方需要直接打开模块配置，优先走 MainTasks.openModuleScreen(...)，不要重新造入口。
满足以下条件时，优先复用这条链：
BaseModule 的注册配置showPredicate 表达只有在以下场景，才考虑另开专门屏幕：
RefKeyValueInputWidget 的输入协议模块类应该只提供：
getEditableConfig()addCustomWidgets(...)不要在模块类里直接 new 一整套配置屏幕组件。
WidgetUtils如果只是一个模块配置屏幕：
WidgetUtils.openModuleConfigScreen(...)createModuleConfigScreen(...)，再由调用方决定何时打开如果是通用配置列表但不是模块，也优先走 createConfigScreen(...) 这一层，把：
作为参数传进去。
addCustomWidgets(...)模块自己的额外按钮、说明块、状态块，不要插到 WidgetUtils 内部做特判。
统一模式是：
WidgetUtils 先铺标题和配置行customWidgets.accept(listWidget::addDrawableChild)这样通用层不需要知道模块差异。
如果一个配置项是否显示依赖别的开关：
show(...)showPredicate不要在屏幕里根据 path、key 名、模块名再写一套 if/else。
在某个模块里再次复制一份：
DynamicListWidgetRefKeyValueInputWidgetColorLabelTextElementCenterScreen这会把主题、布局、行显隐和扩展位重新分叉。
把模块特定逻辑写进 WidgetUtils
WidgetUtils 只接受数据和样式，不应该知道：
模块差异应通过参数和 addCustomWidgets(...) 注入。
把“是否显示”写到 value widget 里面
这会导致：
正确做法是整行由 DynamicContentWidget 控制是否返回内容。
为同一主题差异重新写一个新屏幕类
如果差异只有颜色或尺寸：
ConfigScreenPaletteConfigScreenLayout不要新建第二套模块配置屏幕。
BaseModule
WidgetUtils
ClickGui
MainTasks
这个边界不要再混回去。