Use on first install of this plugin, when MO2 or xEdit is not yet detected, when starting a new modpack project, or when the user says 'set up', 'install', 'bootstrap', 'configure', or 'initialize' the BGS modding environment. Orchestrates: MO2 detection and control-plane install, MO2 visible launch, optional xEdit download from BB-84C/TES5Edit, optional bgs-translator/xtl PyPI install, dev-log and release-changelog initialization, and end-to-end semantic smoke verification.
SkillScore77Maintained
Automatic
◆DevOps & SRE pack
Last verified 8/15/2026
What it changes
Passed 15 of 19 test cases with the skill, and 3 of 19 without it.
Without skill18%
With skill77%
Checks it passed that the model alone missed
Sets MO2_Root = none to enter no-MO2 mode.
Specifies checking that data.responsive is true.
Includes bgs-kb-starfield for Starfield game knowledge.
and 16 more in the full report
14 fixed3 passed either way4 still failing1 broke
Pass-rate lift
+59 pp
Tokens
+248%
Agent turns
0%
Response time
-61%
Model gemini-3.6-flashMeasured 8/15/2026v117 of 22 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 14
Prompt
An old setup snippet recommends installing `xEditHookBridge.dll` into the xEdit directory for IPC automation. Is this bridge required?
What was checked, without and with the skill
Checked
Without skill
With skill
Identifies that xEditHookBridge.dll is retired and should not be deployed.
Passed
Passed
Specifies that xEdit uses native -automation-serve for IPC communication.
Missed
Passed
case-15 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md473 linessingle file
Setting Up the BGS Modding Environment
This is the first-run bootstrap. Use it when:
The user installed bgs-modding-superpowers and this is the first conversation
in their project directory.
A new modpack project is being set up from scratch.
MO2 path is not yet known to the agent.
The user explicitly asks to "set up", "install", "bootstrap", "configure", or
"initialize" the BGS modding environment.
A subsequent skill (e.g., xedit-automation) finds the environment incomplete
and routes back here.
Hard guardrails
Do NOT install MO2 yourself by default. The default path is to detect MO2
and, if absent, guide the human user to install it themselves. Agent-driven
install requires explicit user consent ("yes, install MO2 for me").
Never write into the user's vanilla game install (e.g.,
<Steam>/steamapps/common/<Game>/Data/). All overlays go through MO2.
Treat the user's existing MO2 profile as canonical. Do not silently mutate
profiles/<Profile>/plugins.txt, modlist.txt, INIs, or load order.
Pause and surface state before each install action. The user should always
know which MO2 root, which profile, and which file is about to be touched
before it happens.
MO2 must run visibly. Never start MO2 in any background / hidden mode.
The human owner needs to see and interact with the MO2 GUI. The launch helper
scripts/start-mo2.ps1 enforces this and surfaces "zombie" MO2 processes
(running but no window) so they can be cleaned up before a fresh start.
What the control plane actually is
The "MO2 control plane" we deploy in step 4 is a Python MO2 plugin plus a
PowerShell broker:
tools/mo2-control-plane/live-bridge/mo2_agent_control.py — the actual MO2
plugin. When MO2 loads it, the plugin opens a named pipe and starts publishing
bootstrap runtime files. This is what the agent harness talks to.
tools/mo2-control-plane/broker/ — PowerShell IPC client used by
xedit-client.ps1. Runs from the plugin checkout; no install step.