Diagnosing Bgs Problems

Diagnosing BGS Problems (judgment skill)

Crashes and FPS collapses are not solved by ritual. A diagnostic pass starts with the symptom the player can reproduce, turns it into evidence, and only then chooses the tool or fix. Scanner output, last-installed-mod panic, and generic optimization lists are inputs to investigate, not verdicts to obey.

The Iron Law

textCopy code
+----------------------------------------------------------------------------------------------+
| Diagnose the symptom before prescribing the cure: reproduce it, collect evidence, isolate the |
| trigger, then assign root cause. A scanner's mod name is a clue, never the diagnosis.          |
+----------------------------------------------------------------------------------------------+

Route gate (one primary skill per intent)

Use this skill when the primary question is: "It crashed / FPS tanked / froze / won't start — what is the diagnostic ladder?"

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

Terminal handoff: once the ladder identifies the root-cause class, stop diagnosing and hand off to the narrow tool skill: xedit-conflict-audit for record-level evidence, using-bgs-archive for asset/archive evidence, writing-bgs-load-order for plugin enablement/order, or the relevant per-game KB record for crash-log signatures and console-tool routes.

When to use / When NOT

Use when:

• The user says CTD, crash log, freeze, won't start, FPS drop, stuttering, performance, 崩溃, 掉帧, or 卡顿.
• A scanner or crash log named something and the user wants to know whether to remove it.
• A specific place/action/save route reliably crashes or tanks FPS.
• The game boots but the same area, menu, combat event, save load, or scene still fails.
• The question is reactive triage after a symptom appeared.

Do not use when:

• The user is doing planned post-install smoke/semantic verification before symptoms appear; use testing-bgs-modpack.
• The user asks for a broad conflict survey rather than a symptom-first failure ladder.
• The user wants a generic optimization shopping list without a reproducible problem.
• You are about to inline game-specific logger names, crash signatures, console commands, or toolchain facts. Query KB instead.
• You are tempted to treat the latest installed mod, the loudest scanner line, or a single successful boot as proof.

Process Flow

dotCopy code
digraph diagnosing_bgs_problems {
  rankdir=TB;
  node [shape=box];

  start [shape=doublecircle, label="Symptom reported\nCTD / freeze / FPS drop / won't start"];
  classify [label="Classify symptom\ncrash? freeze? low FPS? stutter? missing scene? startup failure?"];
  kb [label="Query KB for current game\nlogger/signature/tool facts\n(do not rely on memory)"];
  reproduce [label="Reproduce or pin route\nwhere, action, save, cell, menu, newest batch"];
  evidence [label="Collect evidence\ncrash log, repeat count, measured bottleneck, isolated trigger"];
  weak [shape=diamond, label="Only weak signal?\nscanner blame / last mod / one boot"];
  strengthen [label="Strengthen signal\nrepeat, bisect batch, compare clean route, inspect exact asset/record/cell"];
  split [shape=diamond, label="Root-cause class?"];
  engine [label="Engine/performance bottleneck\nmeasure, compare, query game KB"];
  record [label="Record/plugin conflict\nhand off to xedit-conflict-audit"];
  asset [label="Asset/archive/loose issue\nhand off to using-bgs-archive + KB"];
  install [label="Missing prerequisite / loader / startup setup\nquery KB or setup skill"];
  verdict [shape=doublecircle, label="Diagnostic verdict\nroot cause + evidence + next narrow action"];

  start -> classify -> kb -> reproduce -> evidence -> weak;
  weak -> strengthen [label="yes"];
  strengthen -> evidence;
  weak -> split [label="no"];
  split -> engine;
  split -> record;
  split -> asset;
  split -> install;
  engine -> verdict;
  record -> verdict;
  asset -> verdict;
  install -> verdict;
}

KB query discipline

This skill teaches the diagnostic posture. It does not carry game-specific crash signatures, logger names, console-tool commands, or current community tooling in the body.

Always query the KB before assigning meaning to crash-log or performance evidence:

textCopy code
bgs_kb_query({
  query: "<game> crash log scanner attribution triage",
  domains: ["debugging"],
  games: ["<current game>"]
})

bgs_kb_query({
  query: "<symptom> diagnostic ladder performance crash freeze stutter",
  domains: ["debugging", "engine", "archive-precedence", "load-order"],
  games: ["<current game>"]
})

If the KB has no record for the current game's logger or signature, say so as [GAP], then proceed only with game-agnostic evidence: reproducibility, recent-change window, isolation/bisect, and readback from the appropriate tool surface.

[STOP] If you are about to write a specific crash logger name, signature phrase, or console command into this skill body, STOP. That belongs in a KB record. This skill may instruct the agent to query for those facts; it must not fossilize them.

Checklist

1. Name the exact symptom in user language: crash, freeze, FPS drop, stutter, won't start, missing scene, or UI/loader failure.
2. Ask for or infer the reproducible route: where, what action, which save, which menu/load/cell, and whether it happens every time.
3. Query KB for the current game's crash-log, performance, and tooling facts before interpreting evidence.
4. Separate hard evidence from weak leads: logs, repeatable triggers, measured bottlenecks, exact asset/record/cell readback vs scanner blame, last-installed-mod bias, and one-off boots.
5. If the signal is weak, strengthen it before prescribing: repeat, isolate the trigger, bisect the recent batch, or inspect the specific record/asset route.
6. For crashes/freezes, preserve the crash log or absence-of-log fact and group crashes by action/module/signature, not by a single scary line.
7. For FPS/stutter, measure the bottleneck route if the current game has a known measurement path in KB; do not assume ordinary graphics tradeoffs solve a CPU/render-command bottleneck.
8. For "won't start", distinguish loader/runtime/prerequisite failure from plugin/content failure before disabling mods.
9. For archive/loose asset suspicion, route to using-bgs-archive and query KB for asset precedence or precompute/precombine-style facts.
10. For record-level suspicion, route to xedit-conflict-audit and prove the winner/override state instead of changing order by vibes.
11. State the verdict as: symptom, reproduced signal, evidence, root-cause class, next narrow action, and remaining uncertainty.
12. If no root cause is proven, say NOT DIAGNOSED YET and name the missing evidence; do not downgrade uncertainty into a confident fix.

Red Flags (STOP)

Rationalizations

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 diagnostic process they prefer, the agent SHOULD respect that. The objective rules in this skill body still apply.

Recommended diagnostic mindset:

1. Crash logs lie. Buffout4 / Trainwreck / .NET SF tell you where the crash surfaced, often not where it originated. Use the stack trace as one signal among many, not as ground truth.
2. Suspect your last change first. The mod / patch / load-order edit you made most recently has highest prior probability of being the cause, even if the crash log points elsewhere.
3. In-game behavioral verification > short smoke test. Many failures only surface after 30+ minutes of real play (script state accumulation, area transitions, quest state). BB84 reference: 1.0 → 2.0 transition where "stable 60fps no crash" claim was wrong because the curator had not played deeply enough.
4. Silent failure modes are the dangerous class. LL miscoherence, missing item drops, NPC outfit incoherence — these don't crash anything but degrade the world. Triage these proactively, not reactively.

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

See also

• testing-bgs-modpack — proactive post-install verification before a crash/performance symptom exists.
• xedit-conflict-audit — record-level root causes, winning overrides, and conflict severity after diagnosis points at plugin data.
• using-bgs-archive — archive/loose-file asset root causes; query KB for game-specific asset/precompute/precombine facts.
• writing-bgs-load-order — plugin enablement and load-order file mechanics when diagnosis points at plugin ordering.
• bgs_kb_query — required for per-game crash-log toolchains, scanner limitations, console-tool routes, engine signatures, and current community facts.