[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JTFP1CDA6974NMCCNFQMAT":3,"skill-same:01M6JTFP1CDA6974NMCCNFQMAT":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6JTFP1CDA6974NMCCNFQMAT","setting-up-bgs-modding-environment",null,"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\u002FTES5Edit, optional bgs-translator\u002Fxtl PyPI install, dev-log and release-changelog initialization, and end-to-end semantic smoke verification.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1554,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FBB-84C\u002Fbgs-modding-superpowers\u002Fskills\u002Fsetting-up-bgs-modding-environment\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"setting up bgs modding environment","up","environment","install","new","when","initialization","plane","end","project","log","smoke","release","initialize","translator","configure","control-plane","SET","pypi","changelog","verification","dev","2026-11-10 10:12:30",false,"---\nname: setting-up-bgs-modding-environment\ndescription: \"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\u002FTES5Edit, optional bgs-translator\u002Fxtl PyPI install, dev-log and release-changelog initialization, and end-to-end semantic smoke verification.\"\n---\n\n# Setting Up the BGS Modding Environment\n\nThis is the first-run bootstrap. Use it when:\n\n- The user installed `bgs-modding-superpowers` and this is the first conversation\n  in their project directory.\n- A new modpack project is being set up from scratch.\n- MO2 path is not yet known to the agent.\n- The user explicitly asks to \"set up\", \"install\", \"bootstrap\", \"configure\", or\n  \"initialize\" the BGS modding environment.\n- A subsequent skill (e.g., `xedit-automation`) finds the environment incomplete\n  and routes back here.\n\n## Hard guardrails\n\n- **Do NOT install MO2 yourself by default.** The default path is to detect MO2\n  and, if absent, guide the human user to install it themselves. Agent-driven\n  install requires explicit user consent (\"yes, install MO2 for me\").\n- **Never write into the user's vanilla game install** (e.g.,\n  `\u003CSteam>\u002Fsteamapps\u002Fcommon\u002F\u003CGame>\u002FData\u002F`). All overlays go through MO2.\n- **Treat the user's existing MO2 profile as canonical.** Do not silently mutate\n  `profiles\u002F\u003CProfile>\u002Fplugins.txt`, `modlist.txt`, INIs, or load order.\n- **Pause and surface state before each install action.** The user should always\n  know which MO2 root, which profile, and which file is about to be touched\n  before it happens.\n- **MO2 must run visibly.** Never start MO2 in any background \u002F hidden mode.\n  The human owner needs to see and interact with the MO2 GUI. The launch helper\n  `scripts\u002Fstart-mo2.ps1` enforces this and surfaces \"zombie\" MO2 processes\n  (running but no window) so they can be cleaned up before a fresh start.\n\n## What the control plane actually is\n\nThe \"MO2 control plane\" we deploy in step 4 is a **Python MO2 plugin** plus a\n**PowerShell broker**:\n\n- `tools\u002Fmo2-control-plane\u002Flive-bridge\u002Fmo2_agent_control.py` — the actual MO2\n  plugin. When MO2 loads it, the plugin opens a named pipe and starts publishing\n  bootstrap runtime files. This is what the agent harness talks to.\n- `tools\u002Fmo2-control-plane\u002Fbroker\u002F` — PowerShell IPC client used by\n  `xedit-client.ps1`. Runs from the plugin checkout; no install step.\n\nThere is **no C++ DLL to build or deploy** at v0.1. A C++ kernel skeleton lives\nunder `docs\u002Finternal\u002Ffuture-c-kernel\u002F` as a design note for later perf-critical\npaths; it is intentionally unbuilt. If a previous agent told you to \"build\nMo2AgentControl.dll first\" — that was wrong. The Python plugin is the\nintegration.\n\n## Workflow\n\n### Step 1 - Detect MO2 install\n\nSearch for `ModOrganizer.exe` in common locations:\n\n- `$env:LOCALAPPDATA\\ModOrganizer*\\ModOrganizer.exe`\n- `D:\\ModOrganizer*\\ModOrganizer.exe`, `E:\\ModOrganizer*\\ModOrganizer.exe`,\n  `C:\\ModOrganizer*\\ModOrganizer.exe`\n- The user's Documents folder.\n- The user's Desktop \u002F common steam-library siblings.\n\nIf exactly one MO2 install is found, propose it to the user for confirmation.\nIf multiple, list them with paths and ask which is the target. If none, go to\nstep 2.\n\nPersist the confirmed install root in conversation context as `MO2_Root`. All\nsubsequent steps reference this variable.\n\n**Also surface the `BGS_MO2_ROOT` env-var requirement.** The `xedit` MCP server\nneeds to know `MO2_Root` so it can resolve `\u003CMO2_Root>\u002Ftools\u002FxEdit\u002FxEdit.exe`\nand `\u003CMO2_Root>\u002Fprofiles\u002F\u003Cprofile>\u002Fplugins.txt`. Without it, the MCP either\nfalls back to a stale dev-sandbox path (silent wrong-answer on dev clones) or\nerrors with a \"MO2 sandbox root is not configured\" message (on end-user\ninstalls). Tell the user where to set it for their harness:\n\n- **OpenCode**: add to the `xedit` MCP entry's env block in `opencode.json`:\n  ```json\n  { \"mcp\": { \"xedit\": { \"env\": { \"BGS_MO2_ROOT\": \"\u003CMO2_Root>\" } } } }\n  ```\n- **Codex**: append to `~\u002F.codex\u002Fconfig.toml`:\n  ```toml\n  [mcp_servers.xedit.env]\n  BGS_MO2_ROOT = \"\u003CMO2_Root>\"\n  ```\n- **Claude Code**: set the env var in the shell that launches Claude Code, or\n  edit `\u003Cplugin-root>\u002F.mcp.json` to add an `env` block on the `xedit` entry.\n\nAfter the user sets it, the user must restart their harness session so the\nMCP server picks up the new env. Confirm by calling `xedit_status({})` and\nchecking that the returned hint no longer mentions BGS_MO2_ROOT.\n\nPer-call override is also available: `xedit_start({ moRoot: \"\u003CMO2_Root>\", ... })`.\nUseful for one-off testing, but the env-var path is what makes restarts and\nsubsequent sessions work without re-passing it.\n\n### Step 2 - If MO2 absent: branch the user\n\nSurface a `[BLOCKED]` notice and offer THREE paths, in order of preference:\n\n**(a) Default - human install.** Provide the official MO2 release URL:\nhttps:\u002F\u002Fgithub.com\u002FModOrganizer2\u002Fmodorganizer\u002Freleases\u002Flatest. Give the user\na brief setup outline (download installer, pick an install root outside Program\nFiles, launch once to initialize). Wait for the user to install and come back\nwith the path.\n\n**(b) Agent-handled install (explicit user consent required).** Only if the\nuser says something like \"yes, install MO2 for me, go ahead\": download the\nofficial MO2 installer to a temp location, run it (silent install where\nsupported), register the resulting path as `MO2_Root`. Surface every step\n(\"downloading from ...\", \"installing to ...\", \"MO2 ready at ...\"). Never\nproceed without the explicit verbal consent.\n\n**(c) No-MO2 mode.** If the user says \"I do not need MO2 for this project\"\n(e.g., they are writing modpack docs \u002F planning without a runtime), record\n`MO2_Root = none`, continue through step 3 for KB target selection, then skip to\nstep 9 (dev-log \u002F changelog init). Mark that any MO2-bound or xEdit-bound work\nwill be unavailable until they revisit this skill.\n\n### Step 3 - First-run KB target selection and pack acquisition\n\nAsk which target games the modpack should support. Use the exact game codes\nwhen talking to KB tools where possible: `SkyrimLE`, `SkyrimSE`, `SkyrimAE`,\n`SkyrimVR`, `Fallout4`, `Fallout4VR`, `Fallout3`, `FalloutNV`, `Starfield`.\n\nThe bundled `bgs-kb-core` pack is materialized inside the plugin tree at\n`plugins\u002Fbgs-modding-superpowers\u002Fknowledge\u002Fbgs-kb\u002Fpacks\u002Fcore\u002F`. No action is\nneeded for it; it appears in `bgs_kb_status` even before MO2 or xEdit are\nconfigured.\n\nPer-game packs (`bgs-kb-skyrim`, `bgs-kb-fallout4`, `bgs-kb-fallout3-fnv`,\n`bgs-kb-starfield`) are published as GitHub Release artifacts on the\n`BB-84C\u002Fbgs-modding-superpowers` repo. The KB MCP wraps the entire fetch +\nsha256 verify + cache install in two tools — do **not** download zips by hand:\n\n1. Map the chosen games to pack IDs:\n   - `SkyrimLE` \u002F `SkyrimSE` \u002F `SkyrimAE` \u002F `SkyrimVR` -> `bgs-kb-skyrim`\n   - `Fallout4` \u002F `Fallout4VR` -> `bgs-kb-fallout4`\n   - `Fallout3` \u002F `FalloutNV` -> `bgs-kb-fallout3-fnv`\n   - `Starfield` -> `bgs-kb-starfield`\n\n   Additionally, if the user has indicated a translation\u002Flocalization workflow\n   for any of these games (intent to run `xtl batch` against the game), add the\n   corresponding localization pack. Today's released localization packs:\n   - `Starfield` + Simplified Chinese -> `bgs-l10n-starfield-zhhans`\n     (151k Bethesda-official terminology entries; RAG retrieval inside `xtl`\n     depends on this pack — see `using-bgs-translator`.)\n\n   These follow the same install path (`bgs_kb_check_updates` ->\n   `bgs_kb_install_pack`) and the same on-disk cache layout as the per-game\n   packs. Do not assume a localization pack is present just because the\n   per-game pack is installed; check `bgs_kb_status` after install.\n\n2. List what is available from the live release manifest:\n   ```\n   bgs_kb_check_updates({})\n   ```\n   This reads the published `manifest-index.json` and returns the latest\n   `{ packId, version, sha256, url, breakingChange }` for every official pack.\n   Surface the per-game-pack rows that match the chosen games before doing\n   anything else.\n\n3. Get **explicit** user consent before installing each pack (\"yes, install\n   `bgs-kb-skyrim`\"). Pack install mutates `~\u002F.bgs-modding-superpowers\u002Fkb\u002Fpacks\u002F\u003CpackId>\u002F\u003Cversion>\u002F`\n   (legacy `%LOCALAPPDATA%\u002Fbgs-modding-superpowers\u002Fkb\u002Fpacks` is no longer used; the cache\n   root is unified with `xtl`).\n\n4. For each consented pack:\n   ```\n   bgs_kb_install_pack({ packId: \"bgs-kb-skyrim\", version: \"\u003Cfrom check_updates>\", dryRun: true })\n   ```\n   Verify the dry-run reports the expected version + sha256, then re-run\n   without `dryRun` to actually install. The MCP downloads from the official\n   release URL, verifies sha256, and lays the pack out in the versioned cache.\n\n5. If `bgs_kb_check_updates` returns an empty or partial list for a game the\n   user wanted (network failure, release not yet published), say so and\n   continue with the bundled core pack. Do not improvise a download URL or\n   `iwr` into the cache by hand.\n\nSmoke test after selection \u002F install:\n\n```text\nbgs_kb_status({})\nbgs_kb_query({ query: \"plugins\", games: [\"\u003Cchosen-game>\"], maxResults: 3 })\n```\n\nSuccess criterion: `bgs_kb_status` lists every pack that was just installed\nplus `bgs-kb-core`, and `bgs_kb_query` returns at least one hit. If only the\ncore pack is available, a core-pack hit is enough for first-run.\n\nFor routine update \u002F prune \u002F version-pinning work after first-run, route to\n`maintaining-modding-environments` — it documents the full ongoing-care flow\non top of the same two MCP tools.\n\n### Step 3A - Install or verify `xtl` for AI translation workflows\n\nIf the user plans to translate mods, or a downstream workflow routes into\n`using-bgs-translator`, make sure the standalone translator CLI is available.\n`xtl` is distributed on PyPI as the `bgs-translator` package; do not assume it\nis present in a fresh machine just because this plugin is installed.\n\nStart with a readback:\n\n```powershell\n# Check whether the translator CLI is already installed and can report capabilities.\nxtl version\n```\n\nIf `xtl` is missing, choose one install path:\n\n```powershell\n# Preferred user-level CLI install when pipx is available.\npipx install bgs-translator==0.9.0rc1\n\n# Fallback when pipx is unavailable, or when the user wants xtl inside the active Python environment.\npy -3.12 -m pip install bgs-translator==0.9.0rc1\n```\n\nFor a future stable release, the same commands can omit the exact prerelease\npin, for example `pipx install bgs-translator` or\n`py -3.12 -m pip install bgs-translator`. Do **not** use broad\n`pip install --pre bgs-translator` as routine setup; it can opt unrelated\ndependencies into prerelease builds. Pin an exact release candidate only when\nthat exact version is the intended runtime.\n\nVerify after install:\n\n```powershell\n# Confirm xtl is on PATH and exposes the expected command surface.\nxtl version\n\n# Inspect the top-level help before choosing subcommands or options.\nxtl --help\n\n# Inspect provider-profile options instead of assuming a single SDK kind.\nxtl profile add --help\n\n# Inspect GUI launch options if the user wants the web translator.\nxtl gui --help\n```\n\nIf `xtl version` fails after a pipx install, surface the pipx PATH warning and\nask the user to reopen the shell\u002Fsession, then retry. Once it passes, route\nactual translation work to `using-bgs-translator`; this setup skill only\ninstalls and smoke-checks the CLI.\n\n### Step 4 - Install the MO2 control plane (Python + broker)\n\nOnce `MO2_Root` is known (path a or b), deploy the Python plugin:\n\n```powershell\n& \"\u003Cplugin-root>\u002Fscripts\u002Finstall-mo2-control-plane.ps1\" -MO2Root \"\u003CMO2_Root>\"\n```\n\nThis deploys:\n\n- `tools\u002Fmo2-control-plane\u002Flive-bridge\u002Fmo2_agent_control.py` -> `\u003CMO2_Root>\u002Fplugins\u002F`\n- The `Mo2AgentControl\u002F` support tree -> `\u003CMO2_Root>\u002Fplugins\u002F`\n- `ModOrganizer.ini lock_gui=false` normalization.\n\nAfter the script returns, list `\u003CMO2_Root>\u002Fplugins\u002F` and confirm\n`mo2_agent_control.py` is present. The script will NOT install a `.dll` — that\nis intentional (see \"What the control plane actually is\" above). If the script\nerrors, stop and surface it; do not continue.\n\n### Step 5 - Start MO2 visibly\n\n```powershell\n& \"\u003Cplugin-root>\u002Fscripts\u002Fstart-mo2.ps1\" -MO2Root \"\u003CMO2_Root>\" -Profile \"\u003CProfile>\"\n```\n\nThe launcher script:\n\n- Refuses to start if a visible MO2 is already running (use that one).\n- If a zombie MO2 (running but no window) is detected, surfaces it and asks\n  before killing — use `-KillStale` to skip the prompt.\n- Starts MO2 with `-WindowStyle Normal` so the GUI is visible.\n- Waits up to 30s for the main window to appear and reports its title.\n\nVerify after launch: the user should see the MO2 GUI on their desktop. The\nplugin's bootstrap runtime files should appear at\n`\u003CMO2_Root>\u002Fplugins\u002FMo2AgentControl\u002Fbootstrap\u002Fruntime\u002F` within a few seconds:\n\n- `status.json` -> `{ schemaVersion, state: \"ok\", mo2Pid }`\n- `endpoint.json` -> `{ transport: \"named-pipe\", endpoint: \"mo2-control-plane-\u003Cpid>\" }`\n- `capabilities.json` -> lists `launch.*`, `system.*` methods.\n\nIf those don't appear, the Python plugin didn't load. Check MO2's plugin\nsettings to confirm `mo2_agent_control` is enabled.\n\n### Step 6 - Ask the user whether they want xEdit\n\nxEdit is optional but high-value. Describe what it does so the user can make\nan informed choice:\n\n> \"xEdit is the canonical editor for Bethesda plugin files (.esp \u002F .esm \u002F .esl).\n> Modpack curators use it to resolve conflicts between mods, generate\n> compatibility patches, flag plugins as ESL (light) to free up load-order\n> slots, clean stray edits (ITM \u002F UDR), and run Pascal-based bulk edits.\n> With this plugin's bundled `xedit` MCP, your agent can drive xEdit\n> programmatically - no GUI clicks required.\"\n\nThen ask: \"Would you like me to install xEdit?\" - explicit consent gate.\n\nIf the user declines, skip to step 9.\n\n### Step 7 - If yes: fetch xEdit from BB-84C\u002FTES5Edit\n\nThe forked, agent-friendly xEdit lives at https:\u002F\u002Fgithub.com\u002FBB-84C\u002FTES5Edit.\nFetch its latest release into the MO2 tools tree:\n\n```powershell\n& \"\u003Cplugin-root>\u002Fscripts\u002Ffetch-xedit-release.ps1\" -MO2Root \"\u003CMO2_Root>\"\n```\n\nThis downloads the latest release zip, extracts into\n`\u003CMO2_Root>\u002Ftools\u002FxEdit\u002F`, and verifies `xEdit.exe` exists post-extract. For\nongoing version pinning after first install, route to\n`maintaining-modding-environments`.\n\n### Step 8 - Native xEdit automation\n\nThe xEdit hook bridge is retired and must not be deployed. The installed\n`xEdit.exe` is launched through `xedit-client.ps1`, which uses native\n`-automation-serve` and a run-scoped `plugins.txt` when needed.\n\n### Step 9 - Initialize dev-log and release-changelog\n\nAsk the user for their **modpack project root**. This is usually one of:\n\n- `\u003CMO2_Root>\u002Fprofiles\u002F\u003CProfileName>\u002F` (if the profile is the unit of work).\n- A separate Git-tracked source directory the user maintains (more common for\n  released modpacks).\n\nOnce `\u003Cproject_root>` is known, route to:\n\n- `writing-modpack-devlog` skill - creates `\u003Cproject_root>\u002Fdocs\u002Fdev-log.md` with\n  the project name and start date as the first entry.\n- `writing-modpack-changelog` skill - creates\n  `\u003Cproject_root>\u002Fdocs\u002Frelease-changelog.md` skeleton.\n\nFrom here on, those two skills maintain the files at runtime; do not template\nor pre-fill them in this skill.\n\n### Step 10 - Verify with a semantic smoke test (NON-BLOCKING)\n\nThe xEdit MCP is fully non-blocking. Do NOT call a single blocking tool and\nwait — that will time out. Instead:\n\n**0. Read MO2's managed gamePath before launching xEdit.** xEdit's default\n   game discovery uses the Windows registry, which points at the Steam install\n   — NOT MO2's Stock Game. To force xEdit to see MO2's projected game tree,\n   read `\u003CMO2_Root>\\ModOrganizer.ini` and extract the `gamePath` value:\n\n   ```\n   gameName=\u003CTarget Game>\n   gamePath=@ByteArray(\u003CMO2 managed game root>)\n   ```\n\n   Strip the `@ByteArray(...)` wrapper; the Data dir is `\u003CgamePath>\\Data`.\n   Pass this to `xedit_start` as `dataPath` in the next step. See\n   `writing-bgs-load-order` for the full reasoning + alternative load-order\n   workflows.\n\n1. **Kick off the daemon launch.**\n   ```\n   xedit_start({\n     dataPath: \"\u003CgamePath>\\\\Data\",   \u002F\u002F from step 0 above\n   })\n   ```\n   Without an explicit `dataPath`, xEdit will discover the game via registry\n   and may open the wrong Data directory.\n\n   Expect `{ ok: true, data: { status: \"starting\" } }` (or `\"ready\"` if it was\n   already up). If you want to use a custom subset of plugins (load-order\n   experimentation), also pass `pluginsFile`:\n   ```\n   xedit_start({\n     dataPath: \"\u003CgamePath>\\\\Data\",\n     pluginsFile: \"\u003Cagent-owned-artifacts-path>\u002Fplugins.txt\",\n   })\n   ```\n   The `writing-bgs-load-order` skill explains how to author the file.\n\n2. **Poll `xedit_status` until ready.** The first launch takes 60-240s because\n   xEdit must parse the active load order. Sleep 5-15s between polls.\n   ```\n   xedit_status({})  -> { status: \"starting\", elapsedSeconds: N }\n   xedit_status({})  -> { status: \"starting\", elapsedSeconds: N+5 }\n   ...\n   xedit_status({})  -> { status: \"ready\", pid: N, readySince: timestamp }\n   ```\n\n   If `status: \"failed\"`, surface `data.error` exactly and STOP. Do not declare\n   success. Common reasons: MO2 not running, MO2 not loading the Python plugin,\n   xEdit binary missing, xEdit's automation-serve mode tripping on the active\n   load order.\n\n3. **Confirm with `xedit_health`** — sends a real `system.ping` to the daemon\n   to catch zombies. Expect `{ status: \"ready\", responsive: true }`.\n\n4. **Confirm domain tools work.**\n   ```\n   xedit_list_capabilities({})  -> ~49 commands, empty drift.onlyInDigest\n   xedit_session({})            -> { gameMode: \"Fallout4\", loadOrderSize: N, daemonPid: N }\n   ```\n\nIf all four pass: surface `[OK] BGS modding environment ready` with the recorded\n`MO2_Root`, xEdit path (if installed), and project root.\n\n## Acceptance (semantic, not surface)\n\nThe setup is complete only when ALL of the following hold. Do not declare\nsuccess otherwise:\n\n- `\u003CMO2_Root>` is known and `\u003CMO2_Root>\u002FModOrganizer.exe` exists.\n- Target games are recorded; `bgs_kb_status` sees the bundled core pack; and at\n  least one `bgs_kb_query` smoke for the chosen game returns a hit.\n- If AI translation workflows were requested: `xtl version` succeeds from the\n  user's shell, and `xtl --help` lists the translator command surface.\n- `\u003CMO2_Root>\u002Fplugins\u002Fmo2_agent_control.py` exists (skipped only in no-MO2 mode).\n- MO2 is visibly running (process has `MainWindowHandle != 0`) and\n  `\u003CMO2_Root>\u002Fplugins\u002FMo2AgentControl\u002Fbootstrap\u002Fruntime\u002Fstatus.json` reports\n  `state: \"ok\"` with a current `mo2Pid` (skipped only in no-MO2 mode).\n- If xEdit was chosen: `\u003CMO2_Root>\u002Ftools\u002FxEdit\u002FxEdit.exe` exists. The retired\n  `xEditHookBridge.dll` is not required.\n- `\u003Cproject_root>\u002Fdocs\u002Fdev-log.md` and\n  `\u003Cproject_root>\u002Fdocs\u002Frelease-changelog.md` both exist (or user explicitly\n  declined - record the decline in conversation context).\n- `xedit_status` eventually reports `status: \"ready\"`, and\n  `xedit_health.data.responsive` is `true`, and\n  `xedit_list_capabilities` returns a non-empty digest. (Skipped only if xEdit\n  was declined or no-MO2 mode.)\n\nIn no-MO2 mode, only the KB target selection \u002F smoke and the dev-log \u002F changelog\nsteps need to pass.\n\n## Common mistakes\n\n- Skipping the consent gate on step 2(b) or step 6. Both REQUIRE explicit user\n  agreement; silent install or silent install-decision is forbidden.\n- Silently choosing one MO2 install when multiple are detected. Always ask.\n- **Trying to build `Mo2AgentControl.dll` from `docs\u002Finternal\u002Ffuture-c-kernel\u002F`.**\n  That is a skeleton, not a real MO2 plugin. The Python plugin IS the\n  integration. Build the C++ kernel only if you are deliberately moving\n  perf-critical paths out of Python in a future release.\n- **Calling `xedit_session` or any domain tool and blocking on the response.**\n  Every tool returns immediately. If you see `status: \"starting\"`, poll\n  `xedit_status`; do not call the same tool again in a tight loop.\n- **Using `\u002Fmcp reconnect` as the normal way to relaunch xEdit.**\n  Prefer `xedit_dirty`, `xedit_stop`, and `xedit_restart` so the agent can\n  decide whether to save or abandon unsaved edits before clearing state.\n- **Starting MO2 with `Start-Process -WindowStyle Hidden`** (or any other\n  invisible\u002Fbackground mode). Always use the `start-mo2.ps1` helper, which\n  forces a visible window.\n- Writing into the user's vanilla game install directly instead of via MO2\n  overlay. NEVER do this. See `using-bgs-modding-superpowers` rule 1.\n- Declaring success on a green script return without the semantic readback\n  (the file existence checks and the four MCP smoke calls).\n- Using broad `pip install --pre bgs-translator` during setup. Prefer an exact\n  package version such as `bgs-translator==0.9.0rc1`, or use the stable package\n  name once a stable release is published.\n\n## See also\n\nFor ongoing care after first-run, see `maintaining-modding-environments`.\n\n- `using-bgs-modding-superpowers` - the per-session bootstrap; lists the full\n  skill inventory and hard rules.\n- `xedit-automation` - hub skill for all xEdit work; load after this skill\n  succeeds.\n- `writing-modpack-devlog`, `writing-modpack-changelog` - runtime asset skills\n  invoked from step 9.\n- The active installer scripts under `scripts\u002F`: `install-mo2-control-plane.ps1`,\n  `start-mo2.ps1`, `fetch-xedit-release.ps1`.\n","# Setting Up the BGS Modding Environment\n\nThis is the first-run bootstrap. Use it when:\n\n- The user installed `bgs-modding-superpowers` and this is the first conversation\n  in their project directory.\n- A new modpack project is being set up from scratch.\n- MO2 path is not yet known to the agent.\n- The user explicitly asks to \"set up\", \"install\", \"bootstrap\", \"configure\", or\n  \"initialize\" the BGS modding environment.\n- A subsequent skill (e.g., `xedit-automation`) finds the environment incomplete\n  and routes back here.\n\n## Hard guardrails\n\n- **Do NOT install MO2 yourself by default.** The default path is to detect MO2\n  and, if absent, guide the human user to install it themselves. Agent-driven\n  install requires explicit user consent (\"yes, install MO2 for me\").\n- **Never write into the user's vanilla game install** (e.g.,\n  `\u003CSteam>\u002Fsteamapps\u002Fcommon\u002F\u003CGame>\u002FData\u002F`). All overlays go through MO2.\n- **Treat the user's existing MO2 profile as canonical.** Do not silently mutate\n  `profiles\u002F\u003CProfile>\u002Fplugins.txt`, `modlist.txt`, INIs, or load order.\n- **Pause and surface state before each install action.** The user should always\n  know which MO2 root, which profile, and which file is about to be touched\n  before it happens.\n- **MO2 must run visibly.** Never start MO2 in any background \u002F hidden mode.\n  The human owner needs to see and interact with the MO2 GUI. The launch helper\n  `scripts\u002Fstart-mo2.ps1` enforces this and surfaces \"zombie\" MO2 processes\n  (running but no window) so they can be cleaned up before a fresh start.\n\n## What the control plane actually is\n\nThe \"MO2 control plane\" we deploy in step 4 is a **Python MO2 plugin** plus a\n**PowerShell broker**:\n\n- `tools\u002Fmo2-control-plane\u002Flive-bridge\u002Fmo2_agent_control.py` — the actual MO2\n  plugin. When MO2 loads it, the plugin opens a named pipe and starts publishing\n  bootstrap runtime files. This is what the agent harness talks to.\n- `tools\u002Fmo2-control-plane\u002Fbroker\u002F` — PowerShell IPC client used by\n  `xedit-client.ps1`. Runs from the plugin checkout; no install step.\n\nThere is **no C++ DLL to build or deploy** at v0.1. A C++ kernel skeleton lives\nunder `docs\u002Finternal\u002Ffuture-c-kernel\u002F` as a design note for later perf-critical\npaths; it is intentionally unbuilt. If a previous agent told you to \"build\nMo2AgentControl.dll first\" — that was wrong. The Python plugin is the\nintegration.\n\n## Workflow\n\n### Step 1 - Detect MO2 install\n\nSearch for `ModOrganizer.exe` in common locations:\n\n- `$env:LOCALAPPDATA\\ModOrganizer*\\ModOrganizer.exe`\n- `D:\\ModOrganizer*\\ModOrganizer.exe`, `E:\\ModOrganizer*\\ModOrganizer.exe`,\n  `C:\\ModOrganizer*\\ModOrganizer.exe`\n- The user's Documents folder.\n- The user's Desktop \u002F common steam-library siblings.\n\nIf exactly one MO2 install is found, propose it to the user for confirmation.\nIf multiple, list them with paths and ask which is the target. If none, go to\nstep 2.\n\nPersist the confirmed install root in conversation context as `MO2_Root`. All\nsubsequent steps reference this variable.\n\n**Also surface the `BGS_MO2_ROOT` env-var requirement.** The `xedit` MCP server\nneeds to know `MO2_Root` so it can resolve `\u003CMO2_Root>\u002Ftools\u002FxEdit\u002FxEdit.exe`\nand `\u003CMO2_Root>\u002Fprofiles\u002F\u003Cprofile>\u002Fplugins.txt`. Without it, the MCP either\nfalls back to a stale dev-sandbox path (silent wrong-answer on dev clones) or\nerrors with a \"MO2 sandbox root is not configured\" message (on end-user\ninstalls). Tell the user where to set it for their harness:\n\n- **OpenCode**: add to the `xedit` MCP entry's env block in `opencode.json`:\n  ```json\n  { \"mcp\": { \"xedit\": { \"env\": { \"BGS_MO2_ROOT\": \"\u003CMO2_Root>\" } } } }\n  ```\n- **Codex**: append to `~\u002F.codex\u002Fconfig.toml`:\n  ```toml\n  [mcp_servers.xedit.env]\n  BGS_MO2_ROOT = \"\u003CMO2_Root>\"\n  ```\n- **Claude Code**: set the env var in the shell that launches Claude Code, or\n  edit `\u003Cplugin-root>\u002F.mcp.json` to add an `env` block on the `xedit` entry.\n\nAfter the user sets it, the user must restart their harness session so the\nMCP server picks up the new env. Confirm by calling `xedit_status({})` and\nchecking that the returned hint no longer mentions BGS_MO2_ROOT.\n\nPer-call override is also available: `xedit_start({ moRoot: \"\u003CMO2_Root>\", ... })`.\nUseful for one-off testing, but the env-var path is what makes restarts and\nsubsequent sessions work without re-passing it.\n\n### Step 2 - If MO2 absent: branch the user\n\nSurface a `[BLOCKED]` notice and offer THREE paths, in order of preference:\n\n**(a) Default - human install.** Provide the official MO2 release URL:\nhttps:\u002F\u002Fgithub.com\u002FModOrganizer2\u002Fmodorganizer\u002Freleases\u002Flatest. Give the user\na brief setup outline (download installer, pick an install root outside Program\nFiles, launch once to initialize). Wait for the user to install and come back\nwith the path.\n\n**(b) Agent-handled install (explicit user consent required).** Only if the\nuser says something like \"yes, install MO2 for me, go ahead\": download the\nofficial MO2 installer to a temp location, run it (silent install where\nsupported), register the resulting path as `MO2_Root`. Surface every step\n(\"downloading from ...\", \"installing to ...\", \"MO2 ready at ...\"). Never\nproceed without the explicit verbal consent.\n\n**(c) No-MO2 mode.** If the user says \"I do not need MO2 for this project\"\n(e.g., they are writing modpack docs \u002F planning without a runtime), record\n`MO2_Root = none`, continue through step 3 for KB target selection, then skip to\nstep 9 (dev-log \u002F changelog init). Mark that any MO2-bound or xEdit-bound work\nwill be unavailable until they revisit this skill.\n\n### Step 3 - First-run KB target selection and pack acquisition\n\nAsk which target games the modpack should support. Use the exact game codes\nwhen talking to KB tools where possible: `SkyrimLE`, `SkyrimSE`, `SkyrimAE`,\n`SkyrimVR`, `Fallout4`, `Fallout4VR`, `Fallout3`, `FalloutNV`, `Starfield`.\n\nThe bundled `bgs-kb-core` pack is materialized inside the plugin tree at\n`plugins\u002Fbgs-modding-superpowers\u002Fknowledge\u002Fbgs-kb\u002Fpacks\u002Fcore\u002F`. No action is\nneeded for it; it appears in `bgs_kb_status` even before MO2 or xEdit are\nconfigured.\n\nPer-game packs (`bgs-kb-skyrim`, `bgs-kb-fallout4`, `bgs-kb-fallout3-fnv`,\n`bgs-kb-starfield`) are published as GitHub Release artifacts on the\n`BB-84C\u002Fbgs-modding-superpowers` repo. The KB MCP wraps the entire fetch +\nsha256 verify + cache install in two tools — do **not** download zips by hand:\n\n1. Map the chosen games to pack IDs:\n   - `SkyrimLE` \u002F `SkyrimSE` \u002F `SkyrimAE` \u002F `SkyrimVR` -> `bgs-kb-skyrim`\n   - `Fallout4` \u002F `Fallout4VR` -> `bgs-kb-fallout4`\n   - `Fallout3` \u002F `FalloutNV` -> `bgs-kb-fallout3-fnv`\n   - `Starfield` -> `bgs-kb-starfield`\n\n   Additionally, if the user has indicated a translation\u002Flocalization workflow\n   for any of these games (intent to run `xtl batch` against the game), add the\n   corresponding localization pack. Today's released localization packs:\n   - `Starfield` + Simplified Chinese -> `bgs-l10n-starfield-zhhans`\n     (151k Bethesda-official terminology entries; RAG retrieval inside `xtl`\n     depends on this pack — see `using-bgs-translator`.)\n\n   These follow the same install path (`bgs_kb_check_updates` ->\n   `bgs_kb_install_pack`) and the same on-disk cache layout as the per-game\n   packs. Do not assume a localization pack is present just because the\n   per-game pack is installed; check `bgs_kb_status` after install.\n\n2. List what is available from the live release manifest:\n   ```\n   bgs_kb_check_updates({})\n   ```\n   This reads the published `manifest-index.json` and returns the latest\n   `{ packId, version, sha256, url, breakingChange }` for every official pack.\n   Surface the per-game-pack rows that match the chosen games before doing\n   anything else.\n\n3. Get **explicit** user consent before installing each pack (\"yes, install\n   `bgs-kb-skyrim`\"). Pack install mutates `~\u002F.bgs-modding-superpowers\u002Fkb\u002Fpacks\u002F\u003CpackId>\u002F\u003Cversion>\u002F`\n   (legacy `%LOCALAPPDATA%\u002Fbgs-modding-superpowers\u002Fkb\u002Fpacks` is no longer used; the cache\n   root is unified with `xtl`).\n\n4. For each consented pack:\n   ```\n   bgs_kb_install_pack({ packId: \"bgs-kb-skyrim\", version: \"\u003Cfrom check_updates>\", dryRun: true })\n   ```\n   Verify the dry-run reports the expected version + sha256, then re-run\n   without `dryRun` to actually install. The MCP downloads from the official\n   release URL, verifies sha256, and lays the pack out in the versioned cache.\n\n5. If `bgs_kb_check_updates` returns an empty or partial list for a game the\n   user wanted (network failure, release not yet published), say so and\n   continue with the bundled core pack. Do not improvise a download URL or\n   `iwr` into the cache by hand.\n\nSmoke test after selection \u002F install:\n\n```text\nbgs_kb_status({})\nbgs_kb_query({ query: \"plugins\", games: [\"\u003Cchosen-game>\"], maxResults: 3 })\n```\n\nSuccess criterion: `bgs_kb_status` lists every pack that was just installed\nplus `bgs-kb-core`, and `bgs_kb_query` returns at least one hit. If only the\ncore pack is available, a core-pack hit is enough for first-run.\n\nFor routine update \u002F prune \u002F version-pinning work after first-run, route to\n`maintaining-modding-environments` — it documents the full ongoing-care flow\non top of the same two MCP tools.\n\n### Step 3A - Install or verify `xtl` for AI translation workflows\n\nIf the user plans to translate mods, or a downstream workflow routes into\n`using-bgs-translator`, make sure the standalone translator CLI is available.\n`xtl` is distributed on PyPI as the `bgs-translator` package; do not assume it\nis present in a fresh machine just because this plugin is installed.\n\nStart with a readback:\n\n```powershell\n# Check whether the translator CLI is already installed and can report capabilities.\nxtl version\n```\n\nIf `xtl` is missing, choose one install path:\n\n```powershell\n# Preferred user-level CLI install when pipx is available.\npipx install bgs-translator==0.9.0rc1\n\n# Fallback when pipx is unavailable, or when the user wants xtl inside the active Python environment.\npy -3.12 -m pip install bgs-translator==0.9.0rc1\n```\n\nFor a future stable release, the same commands can omit the exact prerelease\npin, for example `pipx install bgs-translator` or\n`py -3.12 -m pip install bgs-translator`. Do **not** use broad\n`pip install --pre bgs-translator` as routine setup; it can opt unrelated\ndependencies into prerelease builds. Pin an exact release candidate only when\nthat exact version is the intended runtime.\n\nVerify after install:\n\n```powershell\n# Confirm xtl is on PATH and exposes the expected command surface.\nxtl version\n\n# Inspect the top-level help before choosing subcommands or options.\nxtl --help\n\n# Inspect provider-profile options instead of assuming a single SDK kind.\nxtl profile add --help\n\n# Inspect GUI launch options if the user wants the web translator.\nxtl gui --help\n```\n\nIf `xtl version` fails after a pipx install, surface the pipx PATH warning and\nask the user to reopen the shell\u002Fsession, then retry. Once it passes, route\nactual translation work to `using-bgs-translator`; this setup skill only\ninstalls and smoke-checks the CLI.\n\n### Step 4 - Install the MO2 control plane (Python + broker)\n\nOnce `MO2_Root` is known (path a or b), deploy the Python plugin:\n\n```powershell\n& \"\u003Cplugin-root>\u002Fscripts\u002Finstall-mo2-control-plane.ps1\" -MO2Root \"\u003CMO2_Root>\"\n```\n\nThis deploys:\n\n- `tools\u002Fmo2-control-plane\u002Flive-bridge\u002Fmo2_agent_control.py` -> `\u003CMO2_Root>\u002Fplugins\u002F`\n- The `Mo2AgentControl\u002F` support tree -> `\u003CMO2_Root>\u002Fplugins\u002F`\n- `ModOrganizer.ini lock_gui=false` normalization.\n\nAfter the script returns, list `\u003CMO2_Root>\u002Fplugins\u002F` and confirm\n`mo2_agent_control.py` is present. The script will NOT install a `.dll` — that\nis intentional (see \"What the control plane actually is\" above). If the script\nerrors, stop and surface it; do not continue.\n\n### Step 5 - Start MO2 visibly\n\n```powershell\n& \"\u003Cplugin-root>\u002Fscripts\u002Fstart-mo2.ps1\" -MO2Root \"\u003CMO2_Root>\" -Profile \"\u003CProfile>\"\n```\n\nThe launcher script:\n\n- Refuses to start if a visible MO2 is already running (use that one).\n- If a zombie MO2 (running but no window) is detected, surfaces it and asks\n  before killing — use `-KillStale` to skip the prompt.\n- Starts MO2 with `-WindowStyle Normal` so the GUI is visible.\n- Waits up to 30s for the main window to appear and reports its title.\n\nVerify after launch: the user should see the MO2 GUI on their desktop. The\nplugin's bootstrap runtime files should appear at\n`\u003CMO2_Root>\u002Fplugins\u002FMo2AgentControl\u002Fbootstrap\u002Fruntime\u002F` within a few seconds:\n\n- `status.json` -> `{ schemaVersion, state: \"ok\", mo2Pid }`\n- `endpoint.json` -> `{ transport: \"named-pipe\", endpoint: \"mo2-control-plane-\u003Cpid>\" }`\n- `capabilities.json` -> lists `launch.*`, `system.*` methods.\n\nIf those don't appear, the Python plugin didn't load. Check MO2's plugin\nsettings to confirm `mo2_agent_control` is enabled.\n\n### Step 6 - Ask the user whether they want xEdit\n\nxEdit is optional but high-value. Describe what it does so the user can make\nan informed choice:\n\n> \"xEdit is the canonical editor for Bethesda plugin files (.esp \u002F .esm \u002F .esl).\n> Modpack curators use it to resolve conflicts between mods, generate\n> compatibility patches, flag plugins as ESL (light) to free up load-order\n> slots, clean stray edits (ITM \u002F UDR), and run Pascal-based bulk edits.\n> With this plugin's bundled `xedit` MCP, your agent can drive xEdit\n> programmatically - no GUI clicks required.\"\n\nThen ask: \"Would you like me to install xEdit?\" - explicit consent gate.\n\nIf the user declines, skip to step 9.\n\n### Step 7 - If yes: fetch xEdit from BB-84C\u002FTES5Edit\n\nThe forked, agent-friendly xEdit lives at https:\u002F\u002Fgithub.com\u002FBB-84C\u002FTES5Edit.\nFetch its latest release into the MO2 tools tree:\n\n```powershell\n& \"\u003Cplugin-root>\u002Fscripts\u002Ffetch-xedit-release.ps1\" -MO2Root \"\u003CMO2_Root>\"\n```\n\nThis downloads the latest release zip, extracts into\n`\u003CMO2_Root>\u002Ftools\u002FxEdit\u002F`, and verifies `xEdit.exe` exists post-extract. For\nongoing version pinning after first install, route to\n`maintaining-modding-environments`.\n\n### Step 8 - Native xEdit automation\n\nThe xEdit hook bridge is retired and must not be deployed. The installed\n`xEdit.exe` is launched through `xedit-client.ps1`, which uses native\n`-automation-serve` and a run-scoped `plugins.txt` when needed.\n\n### Step 9 - Initialize dev-log and release-changelog\n\nAsk the user for their **modpack project root**. This is usually one of:\n\n- `\u003CMO2_Root>\u002Fprofiles\u002F\u003CProfileName>\u002F` (if the profile is the unit of work).\n- A separate Git-tracked source directory the user maintains (more common for\n  released modpacks).\n\nOnce `\u003Cproject_root>` is known, route to:\n\n- `writing-modpack-devlog` skill - creates `\u003Cproject_root>\u002Fdocs\u002Fdev-log.md` with\n  the project name and start date as the first entry.\n- `writing-modpack-changelog` skill - creates\n  `\u003Cproject_root>\u002Fdocs\u002Frelease-changelog.md` skeleton.\n\nFrom here on, those two skills maintain the files at runtime; do not template\nor pre-fill them in this skill.\n\n### Step 10 - Verify with a semantic smoke test (NON-BLOCKING)\n\nThe xEdit MCP is fully non-blocking. Do NOT call a single blocking tool and\nwait — that will time out. Instead:\n\n**0. Read MO2's managed gamePath before launching xEdit.** xEdit's default\n   game discovery uses the Windows registry, which points at the Steam install\n   — NOT MO2's Stock Game. To force xEdit to see MO2's projected game tree,\n   read `\u003CMO2_Root>\\ModOrganizer.ini` and extract the `gamePath` value:\n\n   ```\n   gameName=\u003CTarget Game>\n   gamePath=@ByteArray(\u003CMO2 managed game root>)\n   ```\n\n   Strip the `@ByteArray(...)` wrapper; the Data dir is `\u003CgamePath>\\Data`.\n   Pass this to `xedit_start` as `dataPath` in the next step. See\n   `writing-bgs-load-order` for the full reasoning + alternative load-order\n   workflows.\n\n1. **Kick off the daemon launch.**\n   ```\n   xedit_start({\n     dataPath: \"\u003CgamePath>\\\\Data\",   \u002F\u002F from step 0 above\n   })\n   ```\n   Without an explicit `dataPath`, xEdit will discover the game via registry\n   and may open the wrong Data directory.\n\n   Expect `{ ok: true, data: { status: \"starting\" } }` (or `\"ready\"` if it was\n   already up). If you want to use a custom subset of plugins (load-order\n   experimentation), also pass `pluginsFile`:\n   ```\n   xedit_start({\n     dataPath: \"\u003CgamePath>\\\\Data\",\n     pluginsFile: \"\u003Cagent-owned-artifacts-path>\u002Fplugins.txt\",\n   })\n   ```\n   The `writing-bgs-load-order` skill explains how to author the file.\n\n2. **Poll `xedit_status` until ready.** The first launch takes 60-240s because\n   xEdit must parse the active load order. Sleep 5-15s between polls.\n   ```\n   xedit_status({})  -> { status: \"starting\", elapsedSeconds: N }\n   xedit_status({})  -> { status: \"starting\", elapsedSeconds: N+5 }\n   ...\n   xedit_status({})  -> { status: \"ready\", pid: N, readySince: timestamp }\n   ```\n\n   If `status: \"failed\"`, surface `data.error` exactly and STOP. Do not declare\n   success. Common reasons: MO2 not running, MO2 not loading the Python plugin,\n   xEdit binary missing, xEdit's automation-serve mode tripping on the active\n   load order.\n\n3. **Confirm with `xedit_health`** — sends a real `system.ping` to the daemon\n   to catch zombies. Expect `{ status: \"ready\", responsive: true }`.\n\n4. **Confirm domain tools work.**\n   ```\n   xedit_list_capabilities({})  -> ~49 commands, empty drift.onlyInDigest\n   xedit_session({})            -> { gameMode: \"Fallout4\", loadOrderSize: N, daemonPid: N }\n   ```\n\nIf all four pass: surface `[OK] BGS modding environment ready` with the recorded\n`MO2_Root`, xEdit path (if installed), and project root.\n\n## Acceptance (semantic, not surface)\n\nThe setup is complete only when ALL of the following hold. Do not declare\nsuccess otherwise:\n\n- `\u003CMO2_Root>` is known and `\u003CMO2_Root>\u002FModOrganizer.exe` exists.\n- Target games are recorded; `bgs_kb_status` sees the bundled core pack; and at\n  least one `bgs_kb_query` smoke for the chosen game returns a hit.\n- If AI translation workflows were requested: `xtl version` succeeds from the\n  user's shell, and `xtl --help` lists the translator command surface.\n- `\u003CMO2_Root>\u002Fplugins\u002Fmo2_agent_control.py` exists (skipped only in no-MO2 mode).\n- MO2 is visibly running (process has `MainWindowHandle != 0`) and\n  `\u003CMO2_Root>\u002Fplugins\u002FMo2AgentControl\u002Fbootstrap\u002Fruntime\u002Fstatus.json` reports\n  `state: \"ok\"` with a current `mo2Pid` (skipped only in no-MO2 mode).\n- If xEdit was chosen: `\u003CMO2_Root>\u002Ftools\u002FxEdit\u002FxEdit.exe` exists. The retired\n  `xEditHookBridge.dll` is not required.\n- `\u003Cproject_root>\u002Fdocs\u002Fdev-log.md` and\n  `\u003Cproject_root>\u002Fdocs\u002Frelease-changelog.md` both exist (or user explicitly\n  declined - record the decline in conversation context).\n- `xedit_status` eventually reports `status: \"ready\"`, and\n  `xedit_health.data.responsive` is `true`, and\n  `xedit_list_capabilities` returns a non-empty digest. (Skipped only if xEdit\n  was declined or no-MO2 mode.)\n\nIn no-MO2 mode, only the KB target selection \u002F smoke and the dev-log \u002F changelog\nsteps need to pass.\n\n## Common mistakes\n\n- Skipping the consent gate on step 2(b) or step 6. Both REQUIRE explicit user\n  agreement; silent install or silent install-decision is forbidden.\n- Silently choosing one MO2 install when multiple are detected. Always ask.\n- **Trying to build `Mo2AgentControl.dll` from `docs\u002Finternal\u002Ffuture-c-kernel\u002F`.**\n  That is a skeleton, not a real MO2 plugin. The Python plugin IS the\n  integration. Build the C++ kernel only if you are deliberately moving\n  perf-critical paths out of Python in a future release.\n- **Calling `xedit_session` or any domain tool and blocking on the response.**\n  Every tool returns immediately. If you see `status: \"starting\"`, poll\n  `xedit_status`; do not call the same tool again in a tight loop.\n- **Using `\u002Fmcp reconnect` as the normal way to relaunch xEdit.**\n  Prefer `xedit_dirty`, `xedit_stop`, and `xedit_restart` so the agent can\n  decide whether to save or abandon unsaved edits before clearing state.\n- **Starting MO2 with `Start-Process -WindowStyle Hidden`** (or any other\n  invisible\u002Fbackground mode). Always use the `start-mo2.ps1` helper, which\n  forces a visible window.\n- Writing into the user's vanilla game install directly instead of via MO2\n  overlay. NEVER do this. See `using-bgs-modding-superpowers` rule 1.\n- Declaring success on a green script return without the semantic readback\n  (the file existence checks and the four MCP smoke calls).\n- Using broad `pip install --pre bgs-translator` during setup. Prefer an exact\n  package version such as `bgs-translator==0.9.0rc1`, or use the stable package\n  name once a stable release is published.\n\n## See also\n\nFor ongoing care after first-run, see `maintaining-modding-environments`.\n\n- `using-bgs-modding-superpowers` - the per-session bootstrap; lists the full\n  skill inventory and hard rules.\n- `xedit-automation` - hub skill for all xEdit work; load after this skill\n  succeeds.\n- `writing-modpack-devlog`, `writing-modpack-changelog` - runtime asset skills\n  invoked from step 9.\n- The active installer scripts under `scripts\u002F`: `install-mo2-control-plane.ps1`,\n  `start-mo2.ps1`, `fetch-xedit-release.ps1`.\n",{"name":5,"description":7},"main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FBB-84C\u002Fbgs-modding-superpowers\u002Fskills\u002Fsetting-up-bgs-modding-environment",468,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-11 02:22:54",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill setting-up-bgs-modding-environment",{"tool":62,"command":63},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill setting-up-bgs-modding-environment",{"tool":65,"command":66},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill setting-up-bgs-modding-environment","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FBB-84C\u002Fbgs-modding-superpowers\u002Fskills\u002Fsetting-up-bgs-modding-environment\u002FSKILL.md",true,[],[71,97,120,154,175,189],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":41},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,88,24,89,90,91,92,93,94,95,96],"search","deja search","error","ready","never","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":41},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[104,105,106,107,83,108,28,109,27,110,111,112,113,92,114,115,116,117,118,119],"reflect","deja reflect","brew","remember","project rules","session","reflection","Rules","decisions","review","with","record","github","next","https","node",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":137,"publishedAt":41},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[126,131,134],{"categoryNo":127,"categoryName":128,"taxonomyType":129,"taxonomyTypeDesc":130},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":132,"categoryName":133,"taxonomyType":129,"taxonomyTypeDesc":130},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":135,"categoryName":136,"taxonomyType":129,"taxonomyTypeDesc":130},"01JBSEEDCAT000000000000023","Skill与智能体开发",[122,138,139,140,141,142,28,143,84,144,145,146,147,24,148,149,150,151,152,153],"Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","URL","image","mcp server","schedule","api","publish",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":41},"01M71569ZM2X3H5RBFK8PVKMK2","review-study","Review a QuestionPunk survey before launch for wording, answer choices, branching, and missing settings. Use for check my survey or review this draft before publishing.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Freview-study\u002FSKILL.md",[],[161,162,113,163,164,165,166,167,168,169,170,171,172,173,174],"study","review study","for","answer","missing","survey","publishing","use","check","draft","settings","launch","my","branching",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":41},"01M71567GV0C35YQBY0DPGR86B","manage-study","Find QuestionPunk studies, check status, publish an explicitly requested draft, or retrieve its participant link. Use for find my survey, publish this study, or how many people responded.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Fmanage-study\u002FSKILL.md",[],[182,161,183,163,166,168,184,169,170,153,185,186,187,188,173],"manage study","manage","people","how","find","link","status",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":41},"01M71565A8TCA01AZQZRGRYMFZ","create-study","Create a saved QuestionPunk survey draft from a research brief or edit specified questions. Use for requests such as make a customer feedback survey or shorten my onboarding study.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Fcreate-study\u002FSKILL.md",[],[196,161,197,198,199,200,163,201,166,202,168,203,204,170,205,206,207,208,209,173],"create study","create","brief","as","feedback","customer feedback","research brief","shorten","saved","research","requests","customer","questions","edit"]