testing-bgs-modpack

name

testing-bgs-modpack

description

Use when proactively verifying an installed BGS modpack batch before declaring it good. Triggers - "test the pack", "verification", "post-install check", "is it stable", "what should I test", "测试整合包", "验证安装". NOT for reactive crash/performance diagnosis after failure (use diagnosing-bgs-problems), pre-install mod evaluation (evaluating-bgs-mods), or defining batch boundaries/style (curating-bgs-modpack).

Testing BGS Modpack Batches (judgment skill)

This skill answers one question: "It's installed -- how do I PROACTIVELY verify this batch before declaring the batch good?"

BB84's source material is thin here. That is part of the skill's operating doctrine: do not manufacture a giant universal QA checklist. Test the batch's intended in-game impact, preserve save hygiene, query KB for game-specific commands/routes, and mark [GAP — needs user input] when the substrate is silent.

The Iron Law

+------------------------------------------------------------------------------------------------+
| A batch is not accepted because the game reached the main menu. It is accepted only after the   |
| batch's intended in-game effect is observed in its target context, with no immediate local       |
| breakage, and without baking unverified state into the user's main save.                         |
+------------------------------------------------------------------------------------------------+

Route gate (one primary skill per intent)

Use this skill when the user has already installed a batch and wants a proactive post-install verification pass: what to inspect, what commands/routes to use, what counts as enough evidence to move to the next batch.

Do not use this skill as the primary skill for adjacent intents:

User intent	Primary skill
"It crashed", "FPS tanked", missing meshes, broken quests, bad logs, or any failure already observed	diagnosing-bgs-problems
"Should this mod go in the pack?" before install	evaluating-bgs-mods
Define pack style, batch size, rollback boundaries, naming/separator discipline	curating-bgs-modpack
Enable/disable/reorder plugins or edit plugins.txt	writing-bgs-load-order
Inspect records, conflicts, or override winners	xedit-conflict-audit / xedit-automation

Terminal handoff: if proactive testing finds a failure signal, stop calling it "testing" and hand off to diagnosing-bgs-problems. A failed verification pass is not an invitation to improvise a fix inside this skill.

When to use / When NOT

Use when:

• A small batch was installed and the user asks "what should I test before moving on?"
• The user asks "is it stable?", "post-install check", "验证安装", or "测试整合包".
• You need to verify visible new content, expected local mechanics, or immediate CTD/performance risk in the batch's target context.
• You need a save-hygiene reminder before the user commits playthrough state.
• You need to query KB for per-game console commands or test routes without fossilizing those facts in the skill.

Do not use when:

• A crash/perf/quest/mesh/script failure already exists. Escalate to diagnosing-bgs-problems.
• The question is whether to include the mod at all. Use evaluating-bgs-mods.
• The batch boundary is unknown and the user wants to plan the pack architecture. Use curating-bgs-modpack.
• You are about to write game-specific console command catalogs into this file. Those belong in KB.
• You are tempted to invent generic QA filler like "verify all systems work". Mark [GAP — needs user input] instead.

Process Flow

digraph testing_bgs_modpack {
  rankdir=TB;
  node [shape=box];

  start [shape=doublecircle, label="Installed batch"];
  boundary [label="Name the batch boundary\nWhich mods were just added?\nWhat impact did they promise?"];
  kb [label="Query KB\n(game + mod type + console/test routes + save hygiene)"];
  gap [shape=diamond, label="KB / user intent enough\nto define target checks?"];
  ask [label="Mark [GAP] and ask one focused question\nwith a recommended minimal route"];
  save [label="Protect save state\nUse disposable/pre-batch test save\nDo not overwrite main progression"];
  route [label="Run batch-bounded in-game checks\nGo only where this batch should matter\nUse per-game commands from KB"];
  observe [label="Observe semantic readback\nvisible effect present? expected mechanic works?\nno immediate CTD/error/major local breakage?"];
  fail [shape=doublecircle, label="FAIL / FAILURE SIGNAL\nStop and hand off to diagnosing-bgs-problems"];
  more [shape=doublecircle, label="NEEDS MORE INFO\nName exact missing proof / KB gap"];
  pass [shape=doublecircle, label="PASS FOR THIS BATCH\nRecord evidence, then next batch may proceed"];

  start -> boundary -> kb -> gap;
  gap -> ask [label="no"];
  gap -> save [label="yes"];
  ask -> kb [label="after answer or KB backfill"];
  save -> route -> observe;
  observe -> pass [label="intended effect observed + no local breakage"];
  observe -> fail [label="CTD, severe perf, missing content, broken mechanic"];
  observe -> more [label="impact unknown or route not grounded"];
}

KB query discipline

This skill teaches the testing posture. It does not inline game-specific commands, cells, routes, log tools, or benchmark thresholds.

Before recommending a console command or test route, query KB for the current game and the batch's mod-impact type:

bgs_kb_query({
  query: "post-install verification console commands test routes <mod type>",
  domains: ["install-planning", "debugging", "engine"],
  games: ["<current game>"]
})

bgs_kb_query({
  query: "save hygiene script initialization batch testing",
  domains: ["install-planning", "debugging", "engine"],
  games: ["<current game>"]
})

[STOP] If KB is silent on a command or route, do not invent one from memory. Mark [GAP — needs user input] and ask for the user's preferred test cell / route / save boundary, or recommend the smallest non-saving visual/mechanic check that follows from the mod author's stated impact.

[STOP] Per-game console commands and travel/debug shortcuts are KB facts. They belong in KB records, not in this game-agnostic skill body.

Checklist

1. Name the batch: list only the mods just installed and the intended impact of each. If the batch boundary is unclear, mark [GAP — needs user input] and ask for it.
2. Read / reuse the author-stated impact: what should visibly or mechanically change if the install is correct?
3. Query KB for the current game's test routes, console commands, save-hygiene notes, and mod-type-specific verification signals.
4. If KB lacks routes or commands, mark [GAP — needs user input]; do not write a universal route from memory.
5. Protect save state before testing. Use a disposable/pre-batch test save or another user-approved save boundary. [GAP — needs user input]: exact safe-save procedure is game/profile-specific and not in the mined corpus.
6. Do not save over the user's main progression until the batch has a PASS verdict.
7. Visit the target context where the batch should matter: the cell, worldspace, UI screen, NPC, item, quest stage, mechanic trigger, or performance hotspot named by the batch/KB. [GAP — needs user input]: if no target context is known, the batch is not verifiable yet.
8. Look for positive evidence: visible new content present, expected local mechanic works once, expected patch/fix changes the previously relevant local behavior, and no immediate CTD or severe local breakage.
9. Treat silent absence as a failure signal: if the mod is enabled but the expected thing is visibly absent, stop and hand off to diagnosis instead of declaring success.
10. Treat error overlays / missing assets / broken UI / severe local FPS collapse as failure signals. [GAP — needs user input]: exact overlay strings and visual markers are per-game/per-mod facts for KB.
11. Do not expand into a whole-pack investigation. If the batch fails, route to diagnosing-bgs-problems; if it passes, record "PASS for this batch" and move to the next batch.
12. Record the evidence in plain terms: batch name, game/profile, save boundary, route used, positive observations, failure signals absent/present, remaining [GAP] items.

Red Flags (STOP)

Thought	Reality
"The main menu loaded, so the batch is stable."	Menu load is not the batch's in-game impact. Test where the batch should matter.
"MO2 says enabled; no need to enter the game."	Manager enablement is not semantic readback. Some failures only appear in-game or in xEdit.
"I'll save normally first so the mod initializes."	Do not bake unverified batch state into the main progression save. Use a save boundary.
"No CTD for five minutes means accepted."	No CTD is one support signal. Acceptance also needs the intended effect to appear/work.
"Something broke; keep using this checklist until fixed."	A failure signal exits this skill. Hand off to diagnosing-bgs-problems.
"Console commands are obvious across Bethesda games."	Per-game commands and safe cells belong in KB. Query first; mark [GAP] if absent.
"The source is thin; fill in normal QA advice."	This judgment layer is anti-checklist. Thin substrate means honest [GAP], not filler.

Rationalizations

Excuse	Reality
"Testing the whole pack every time is safer."	Proactive verification is batch-bounded. Whole-pack diagnosis begins after a failure signal.
"I can test after a few more batches; this one is small."	Delayed testing destroys the recent-batch boundary that makes failures attributable.
"The mod is visual only; no need for a save boundary."	Maybe, but the skill cannot know that without the author's stated impact and KB facts. Mark uncertainty instead of guessing.
"If the expected content is absent, maybe it appears later."	Maybe. It is still not verified. Mark NEEDS MORE INFO or hand off to diagnosis.
"A generic route through a few popular cells is good enough."	Routes must match the batch's intended impact and current game. Generic tourism is not proof.
"The user wants confidence, not gaps."	False confidence is worse than a marked gap. Honest [GAP] is the correct deliverable when the corpus is silent.

Recommended Approach: Senior Curator's Lens

This section reflects an experienced curator's perspective, distilled from BB84's BGS modpack curation work. It is RECOMMENDED guidance, not enforced rule. If the user has a working testing process they prefer, the agent SHOULD respect that.

Recommended testing rhythm:

1. Stage-test after each batch, not after each mod. Single-mod testing has infinite time cost (KB record pack-curation.testing-cost-economics). Batch together additive low-risk mods, then enter a staged-test phase.
2. Test the silent failure surface, not just the crash surface. Walk through areas known to be touched by recent mods; check NPC outfit logic; check inventory drops; sample dialog flow; observe save file size growth pattern.
3. Commit save before risky batches. Saves are the rollback substrate.
4. Long-session discovery is part of the testing rhythm. Many defects only emerge after 10+ hours of real play. Don't claim "stable" from 30 minutes of smoke test.

See KB record mod-evaluation.bb84-curator-perspective-reference for the full curator essay.

See also

• diagnosing-bgs-problems — use after any crash, severe FPS drop, missing content, broken mechanic, log error, or failed verification signal.
• curating-bgs-modpack — owns batch boundaries, rollback rhythm, pack style, and naming/separator discipline.
• evaluating-bgs-mods — decides whether a mod should be included before install.
• interpreting-mod-author-instructions — reads author instructions and installer choices before the testable batch exists.
• writing-bgs-load-order — plugin enable/disable/order mechanics.
• xedit-conflict-audit / xedit-automation — record-level readback when a failed verification points to override/conflict semantics.
• bgs_kb_query — required source for per-game console commands, safe test cells/routes, save-hygiene specifics, and mod-category verification facts.