Skyrim Forge 6.0 是随 senjuwoo/ultimate-ai-starter-bundle 捆绑分发的《上古卷轴5：天际》模组开发与验证工具，定位为类型化自动化代理。它同时提供命令行接口（forge）与 MCP 服务器两种使用形态，并通过一系列能力标志和就绪状态约束自动化操作。以下按已知资料整理其用途、主要能力、使用方式和限制。
一、安装与环境解析 资料要求在使用 Forge 前先读取技能旁的 INSTALLATION.json，其中包含本机权威的根目录、共享 Python 可执行文件、CLI argv 和 MCP argv，应优先采用这些精确数组，而不是猜测安装路径、直接使用 python 或设置特定提供方的 PYTHONPATH。若描述文件不可用，则依次按 SKYRIM_FORGE_ROOT 环境变量、PATH 中的 forge、用户显式提供的路径来解析。资料明确要求不要假定盘符，也不要将 Documents\SkyrimForge 或 Documents\Skyrim Forge 视为实际产品；受管安装是无版本号的 Skyrim-Forge 目录，由 SKYRIM_FORGE_ROOT 指向，升级会原地替换应用源码并保留受管工作区/运行时状态，不应重建带版本号的安装路径。在工作区中若从捆绑方式运行，可执行 TOOLS/Install-SkyrimForge.ps1，不应自行发明手动解压路径。
二、健康检查与 MCP 运行 Forge 6 与本捆绑包位于同一仓库，因此没有跨产品版本握手。资料建议在大规模工作前运行 forge doctor（或描述文件中的 CLI argv 加 doctor），并要求 result: PASS 与 read_only_ready: true。MCP 服务器通过 <root>/.venv/Scripts/python.exe -m skyrim_forge mcp 启动。资料特别指出 Windows 下 venv 的一个陷阱：若 venv 由提供方运行时缓存中的 python 创建，缓存被删除或该提供方被卸载后，MCP 客户端会在启动时挂起；可通过检查 <root>/.venv/pyvenv.cfg 中的 home 是否指向缓存目录来判断，修复方式是使用稳定解释器重建 venv 并重新安装。资料还给出了用 JSON-RPC initialize 探测服务器是否返回 JSON 的方法，随后重启 MCP 客户端。
三、主要能力与使用原则 资料要求优先使用 Forge 的检查能力和类型化任务，而不是临时编写一次性脚本；不得启动 xEdit、Creation Kit、LOOT 或 Wrye Bash 后让用户手动点击，应使用 Automation Fabric 任务，或报告所需适配器不可用。承诺某个子系统前要先查询 forge capabilities，区分仅适配器能力、工作器契约能力与已捆绑实现。Papyrus 方面，必须先 papyrus-analyze 再 papyrus-compile，编译需要哈希固定的 Bethesda 编译器、标志、导入、新的 PEX 输出和生成的构建清单，静态优化警告不得作为改变语义的依据。不得通过 Forge 发送任意 shell 命令。不得写入实际 Skyrim Data、Vortex 暂存、MO2 mods、Overwrite、配置文件或存档。read_only_ready 视为健康的检查状态；类型化插件输出需要 plugin_write_ready；xEdit 任务需要 xedit_automation_ready。
四、记录与标识规范 资料要求严格使用 raw_form_id_hex、local_form_id_hex、origin_plugin 和 form_key，不得把原始文件 FormID 标注为运行时加载顺序 FormID。自动化任务应先 automation-validate 再 automation-run；只有在审查操作、输入、输出归属、工具哈希和预期证据后才设置 approval；缺少完成标记不等于成功；工具之间出现分歧时应停止并分类。xEdit 证据不等于 Skyrim 运行时证据，Creation Kit 输出不等于视觉验证。当框架运行时日志能证明具体行被解析并分发时，应视其为比静态 lint 规则更强的证据，遇到分歧停止并分类，而不是静默改写可工作的语法。SPID 的 actor 级表达式与技能表达式不同，资料给出 25/255,0(55/255) 是有效的 actor 范围加技能范围，而 0(25) 不是有效的 min/max 技能表达式。
五、FOMOD 安装器 FOMOD 工作应使用 fomod-scaffold、fomod-plan-validate、fomod-simulate、fomod-build 和 fomod-validate；当类型化计划能表达安装器时，不要手写 ModuleConfig XML。打包前要求严格的 FOMOD 负载覆盖和分支模拟，除非移除已记录并获批，否则保留此前所有安装器选择。资料禁止生成或执行任意 C# FOMOD 脚本，标准类型化 XML 支持是安全边界。
六、发布与质量检查 发布时资料建议的链条为：框架 lint、插件/头部与记录检查、配置时的 xEdit 固定脚本检查、Papyrus 新鲜度验证、资产/发布树验证、适用时的 FOMOD 计划验证/分支模拟/生成树验证、语义 diff、打包到新版本、报告剩余的进游戏测试。涉及菜单、HUD、预览、视觉资产或交互流程的模组，应加载 skyrim-mod-development（或 skyrim-mod-reworking）加 visual-verification，要求带最终视觉系统的真实纵向切片，检查渲染像素并测试支持的输入、UI 缩放、长列表和空/错误状态；Forge 的结构验证器无法证明界面可读、美观、响应式或易用。
七、Nexus Mods 公开发布 任何含 shareable、public release、publish、Nexus、upload、release page 等意图的请求都按发布流程处理，而不是普通 ZIP 创建。资料规定的顺序包括：运行 forge nexus-policy-status 并审阅当前官方 Nexus Mods 政策页面（不得抓取或从缓存推断权限设置）；无发布计划时运行 forge nexus-scaffold；清点每个捆绑文件，用准确的权利记录替换笼统归属；获取第三方许可证据（署名不是许可，不得编造作者同意）；记录必需但不分发的依赖；核实游戏条款、项目/资产许可、协作者署名、Donation Points 兼容性、可执行文件/网络行为、成人内容分类、主张证据和 AI 协助。上传者必须审阅并接受 attestation，AI 不得代签或未经用户明确确认就设置 responsibility_accepted=true。还需加载 skyrim-nexus-publishing 与 visual-verification，基于确切发布版生成最终 BBCode、安全裁切的主视觉、以证据为导向的图库/视频、说明、替代文本和媒体权利清单，不得用概念/生成艺术替代游戏证据。运行 forge nexus-audit 并要求 share_ready: true；普通 ZIP、成功构建、lint 通过或 xEdit 通过都不足以公开发布。随后运行 forge nexus-build 生成最终树、公开权利文档、私有审计和 ZIP，发布前仍需一次真实的 Vortex 和 MO2 安装测试。公开分享时普通 release-build 不够，应使用 release-build --target nexus --publication-plan ... 或 nexus-build。不得仅因文件能编译或 lint 就称模组符合 Nexus 规定。
八、外部工具选择 在自行实现归档、网格、Papyrus、Synthesis、LOD、动画或资产处理之前，应调用 forge tool-resolve <capability>，只使用选中的已配置可执行文件，且 SHA-256 哈希匹配并与目录能力一致。可用 forge tool-scan 扫描嵌套工具文件夹和 ZIP；通过 forge tool-import 导入允许的本地工具库副本，或通过 forge tool-configure 配置仅配置型合法安装，且必须显式批准。不得把本地工具库或第三方可执行文件打包进 Forge、GitHub、FOMOD 或 Nexus 输出；本地持有不等于再分发许可。不得用 GUI 替代 CLI，Synthesis.exe 不是 Synthesis.Bethesda.CLI.exe。当 archive.bsa.* 能力可解析时用 BSArch 处理 .bsa/.ba2；发布构建在 papyrus.compile.official 可解析时使用官方 Bethesda Papyrus 编译器；Champollion 仅用于恢复/分析，不作为原始源码归属的证明。无合格真实工具可用时，应停止并报告缺失适配器，而不是生成未经核实的替代品。
九、限制说明 资料未提供 Forge 的具体收费、价格、支持平台（仅提及 Windows venv 相关注意事项）、性能指标或完整功能清单，这些事实暂未提供。资料中的各项规则属于该技能作者的使用约束，实际能力应以运行 forge capabilities 和 doctor 的结果为准。