setup-ox

设置 ox

编写 ox 技能运行时读取的两个文件：

• ~/.config/ox/models.md（A 部分）：每种子 Agent 角色使用的模型和推理级别。该文件属于用户及其工具环境，因此存放在用户主目录中，绝不会提交到版本库。
• .ox/config.md（B 部分）：此服务运行的内容：它的位置、使用的 ox 资源及版本、框架和语言。该文件属于项目，位于服务根目录。

先运行 A 部分，再运行 B 部分。如果用户将 models 或 project 作为参数传入，则只运行对应部分。

A 部分：模型和预算

A1. 检测可用模型

读取工具环境用于启动子 Agent 的工具参数。它列出的模型和推理力度级别是唯一有效的选项。在 Claude Code 中，这些参数是 Agent 工具的 model 和 effort。绝不要填写该工具未列出的模型或推理力度。条目格式为 <model>；如果工具接受推理力度，则还要加上 (<effort>)。

如果工具环境没有子 Agent 工具，或者该工具不接受模型，则说明这一点，并为每种角色填写 inherit。inherit 始终有效：该角色将使用父会话的模型和推理级别。

在 T3 Code 中，子 Agent 工具是 delegate_task，而 orchestrator_capabilities 会列出所有 canRunChildTask 为 true 的提供方所支持的模型。条目格式为 <providerInstanceId>/<model> (<effort>)，其中推理力度选项必须是该工具为此模型列出的选项，这样面板就可以跨提供方运行。

按名称记录工具环境（claude-code、codex、t3-code、cursor 等）：条目只在列出它们的工具环境中有效。

A2. 加载当前状态

如果 ~/.config/ox/models.md 已存在，则读取它。将其中的 # budget 行和角色对应的值视为当前选择。如果其 # harness 行指定的工具环境与当前环境不同，则其中的条目不适用于当前环境：使用默认值，并说明这一点。删除 A5 中未列出的角色所对应的任何行。

A3. 设定预算、映射并确认

(a) 询问预算。 在对话线程中直接询问。提供以下四个选项，标签必须完全一致；如果文件中记录了当前预算，也要说明。

• unlimited - max reasoning
• large - xhigh reasoning
• medium - high reasoning
• small - medium reasoning

(b) 应用预算。 根据默认值建立工作表；重新运行时，保留用户手动更改过的角色。默认值如下：

角色	运行的任务	默认模型
explore	在资源和 ox 源码中进行只读搜索：查找导出项、事件、调用方、控制台变量	检测到的最快模型
verify api	在代码使用导出项、函数签名或回调结构前，根据资源当前源码进行核验	检测到的最快强力编码模型
implement	编写或修改资源代码：客户端、服务端、共享部分、NUI	检测到的最快强力编码模型
review	检查变更中的错误、误用 ox API 的情况，以及服务端信任问题（客户端触发的事件、未经验证的输入、漏洞利用）	检测到的能力最强模型
hardest tasks	设计资源、调试跨资源或跨客户端／服务端边界的问题，或根据多个探索者的发现解释子系统	检测到的能力最强模型
panel	在多个模型上并行运行一项任务：候选模型竞技场、架构师草案、审查者交叉审问。使用列表，每个条目占一个席位	检测到的每个提供方中能力最强的模型，最多三个。如果只有一个提供方，则使用其能力最强的模型，最多三个

unlimited、large、medium 和 small 分别将每个条目的推理力度设为 max、xhigh、high 或 medium，对应的等级依次为 max > xhigh > high > medium > low。如果模型未列出目标等级，则使用该模型列出的、低于目标等级的最高选项；如果没有，则标记为需要选择角色。绝不要选择等级之外的选项。没有推理力度选项的模型不附加 (<effort>)。inherit 不会更改设置。对于 panel，推理力度应用于每个条目。

(c) 显示角色并确认。 显示每个角色及其条目，并将检测结果中不存在的条目标记为需要选择。询问用户是接受当前设置，还是更改特定角色；提供检测到的模型以及 inherit 作为选项。对于 panel，用户选择一个列表；列表长度决定运行的席位数。在对话线程中直接询问。

A4. 验证

写入的每个条目，包括每个 panel 条目，都必须出现在 A1 的结果中：模型必须是子代理工具列出的模型；如果该工具列出了推理力度，则条目的推理力度也必须是其列出的选项。inherit 始终有效。如果所选条目不可用，则停止并再次询问。

A5. 写入文件

写入 ~/.config/ox/models.md（如果 ~/.config/ox/ 不存在，则创建它）。覆盖整个文件，确保重复运行具有幂等性。格式：

# ox skills model configuration. Written by /setup-ox. One line per role.
# Delete a line, or write `inherit`, to run that role on the parent session's model and reasoning level.
# harness: <harness>
# budget: <label> (<effort>)
explore: <model> (<effort>)
verify api: <entry>
implement: <entry>
review: <entry>
hardest tasks: <entry>
panel: <entry>, <entry>, <entry>

B 部分：项目

B1. 查找服务端根目录

从当前目录开始向上遍历，直到找到 server.cfg，或找到同时包含 resources/ 和 server.cfg 的目录。该目录即为服务端根目录。如果当前目录是单个资源（包含 fxmanifest.lua），则继续向上遍历。

• 找到一个服务端根目录：使用它。
• 找到多个（例如，仓库中包含多个服务端）：列出这些目录并询问用户选择哪一个。
• 未找到：这是一个独立资源仓库。询问资源运行所用服务端的路径。如果用户没有服务端，则使用当前目录作为根目录，并记录 server root: none。

B2. 检测

读取服务端文件；不要想当然。以下每个值都必须来自你读取的文件，而不是凭记忆得出。服务端较大时，将此任务交给 explore 子 Agent，并使用 ~/.config/ox/models.md 中对应的行。

• 资源。 查找服务端根目录下 resources/ 中的所有 fxmanifest.lua，包括 [ox] 之类的方括号文件夹。资源名称就是其文件夹名称。读取每个资源的 version 字段。
• ox 资源。 从列表中保留所有名称以 ox_ 开头的资源，以及 oxmysql。记录每个资源的名称和版本。
• 框架。 在资源列表中查找 ox_core、qbx_core、es_extended、qb-core 和 ND_Core。记录存在的框架及其版本。
• 已启动的资源。 读取 server.cfg 中的 ensure / start 行，并跟进其中的 exec，读取其他 .cfg 文件。资源存在但从未启动时，应标记为存在但未启动。
• 区域设置。 如果 cfg 文件设置了 ox:locale convar，则读取其值。
• 语言。 对用户拥有的每个资源（不包括 ox 资源和框架），记录其使用的是 Lua（清单中有 .lua 脚本）还是 TypeScript/JavaScript（有 package.json、构建步骤或指向 dist/ 的脚本）。
• 资源目录。 找出用户自有资源所在的文件夹，通常是 resources/[local] 或类似目录。选择包含最多用户自有资源的方括号文件夹。

cfg 文件包含机密（mysql_connection_string、sv_licenseKey、steam_webApiKey、带令牌的 set 行）。切勿将机密复制到配置文件或回复中，也不要回显包含机密的完整 cfg 行。

切勿读取 secrets.cfg 或 tokens.cfg 等用于存放私密信息的文件。

B3. 加载当前状态

如果服务端根目录中已存在 .ox/config.md，请读取该文件。将其中的值视为当前选项，并标记检测结果与之不符的每一行（自上次运行后资源已更新、移除或新增）。删除键不属于 B6 的任何行。

B4. 展示并确认

向用户展示一张表格，其中包含 B6 中的每项设置及其检测到的值，并标记与当前文件不符的项目，以及检测无法确定的项目为 需要选择。然后在同一条消息中询问用户是接受当前结果，还是要更改特定行。

对于需要选择的行，请使用以下准确标签提供选项：

• framework：ox_core、qbx_core、es_extended、qb-core、ND_Core、standalone。如果启动了多个框架，请询问新代码应针对哪个框架。
• language：lua、typescript、javascript。默认选择用户资源中使用最多的语言；否则选择 lua。
• resources dir：检测到的文件夹，或用户提供的路径。

检测结果已明确无误的项目无需提问；表格中已显示答案。

B5. 验证

• framework 必须是 standalone，或是服务端中存在的资源。如果资源存在但未启动，请说明这一点。
• resources dir 必须存在于服务端根目录下。
• 如果不存在 ox_lib，请提醒用户大多数 ox 技能都依赖它，并询问是否继续。
• 写入的每个版本都必须是从对应资源的 fxmanifest.lua 中读取的版本。

如果某项值未通过验证，请停止并再次询问。

B6. 写入文件

在服务端根目录下写入 .ox/config.md（如果 .ox/ 不存在，则创建该目录）。覆盖整个文件，以确保重复运行保持幂等。格式：

# ox setup. Written by /setup-ox. Re-run it after adding, removing or updating resources.
# Delete a line to make skills detect that value themselves.
server root: <path from this file to the server root, "." when they are the same, or "none">
resources dir: <path relative to the server root>
framework: <name> <version>, or standalone
language: lua | typescript | javascript
locale: <value of ox:locale>, or en (ox_lib's default when it is unset)
ox resources: <name> <version>, <name> <version>, ...
not started: <name>, <name>, ... or none

如果项目是 git 仓库，请询问是否要提交 .ox/（让项目中的所有人共用），或将其添加到 .gitignore。建议提交。

确认

告知用户写入了哪些文件。ox 技能下次运行时会读取这些文件。重新运行 /setup-ox 可更新配置：更改计划或运行环境后运行 /setup-ox models；资源更新后运行 /setup-ox project，因为技能会讲解 .ox/config.md 中记录版本对应的 API。