Curating Bgs Modpack

Curating BGS Modpack (judgment skill)

A BGS modpack is not a shopping cart of impressive files. It is a declared world-style, built in recoverable increments, with enough naming, attribution, and rollback discipline that future-you can still explain what every layer is doing. Stability is the floor. 风格 is the soul. The curator is co-authoring a systemic world, not proving they can install more mods than a Vault-Tec procurement clerk can misfile requisitions.

The Iron Law

+------------------------------------------------------------------------------------------------+
| Declare the pack's 风格 first, then add mods in named, reversible batches; if you cannot say     |
| what role a batch plays or how to roll it back, you are stockpiling files, not curating a pack. |
+------------------------------------------------------------------------------------------------+

Route gate (one primary skill per intent)

Use this skill when the question is how to build or reshape the whole pack: declared style, batch sizing, rollback boundaries, separators, naming convention, attribution, and devlog discipline.

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

Terminal handoff: after this skill defines the style and next batch boundary, hand each candidate mod to evaluating-bgs-mods. After a batch decision is made, hand the decision to writing-modpack-devlog. Inclusion says "belongs in the next plan"; it does not mean "install loose files however you feel like it."

When to use / When NOT

Use when:

• The user asks to build a modpack, plan the pack, or decide the next batch strategy.
• The pack lacks a declared 风格 and per-mod evaluation has no axis.
• A batch needs a rollback point, separator name, naming convention, or attribution policy.
• The mod list is growing and future debugging would depend on memory rather than structure.
• The user is tempted to call the pack done because it boots or seems stable.
• The pack needs a release/devlog boundary: what changed, what was learned, what future batches must avoid.

Do not use when:

• The only question is whether one mod should be included; use evaluating-bgs-mods.
• The user has already chosen the mod and needs install instructions; use interpreting-mod-author-instructions.
• The question is actual plugin order, master ordering, ESL flagging, or xEdit record state.
• You are about to write FO4/Skyrim/Starfield-specific facts into this skill. Query KB; do not fossilize game lore here.
• You are trying to replace judgment with a checklist of "N mods per batch". BB84's framework is anti-checklist: situational thought over ritual.

Process Flow

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

  start [shape=doublecircle, label="Whole-pack intent"];
  declare_style [label="Declare 风格 first\nWhat world is this pack trying to become?\nWho is it for / not for?"];
  map_roles [label="Map pack roles\nframework, world, gameplay, visuals, translation, optimization, patches"];
  kb_query [label="Query KB for game-specific scale risks\ninstall-planning / engine / archive-precedence / save-file"];
  batch [label="Define next batch\nsmall enough to explain and roll back\nlarge enough to express one coherent role"];
  name_sep [label="Name and separate\nseparator/group name, mod names, patch names, source IDs, attribution"];
  rollback [shape=diamond, label="Rollback boundary real?\nprofile/devlog/save/readback path named?"];
  evaluate [label="Hand each candidate to evaluating-bgs-mods\nthen install-instruction skill"];
  record [label="Record decision and lesson\nwriting-modpack-devlog"];
  stop [shape=doublecircle, label="Batch ready for implementation"];
  shrink [label="Shrink or split batch\nmove risky/script/content-heavy mods later"];
  style_gap [shape=doublecircle, label="STOP\nNo declared 风格 = no fit decisions"];

  start -> declare_style;
  declare_style -> style_gap [label="not declared"];
  declare_style -> map_roles [label="declared"];
  map_roles -> kb_query -> batch -> name_sep -> rollback;
  rollback -> evaluate [label="yes"];
  rollback -> shrink [label="no"];
  shrink -> batch;
  evaluate -> record -> stop;
}

KB query discipline

This skill teaches the whole-pack judgment posture. It does not inline current game-specific operational facts. Query KB before turning scale risk into a batch decision.

Use these query shapes as the default:

bgs_kb_query({
  query: "pack curation incremental batching rollback boundaries",
  domains: ["install-planning", "save-file"],
  games: ["<current game>"]
})

bgs_kb_query({
  query: "<current game> modpack scale risk scripts archives animation precombine LOD",
  domains: ["install-planning", "engine", "archive-precedence", "debugging"],
  games: ["<current game>"]
})

bgs_kb_query({
  query: "load order grouping templates separators modlist naming",
  domains: ["load-order", "install-planning"],
  games: ["<current game>"]
})

[STOP] If you are about to write "FO4 BA2 limit is X", "Skyrim animation stacks should use Y", or "Starfield currently needs Z" into this skill, STOP. Put that in a KB record or query an existing KB record. This skill may say "query game-specific scale risks"; it must not become a stale game-fact scrapbook.

Checklist

1. State the pack 风格 in one or two sentences before evaluating new mods.
2. State who the pack is for and who will probably dislike it. A real style has exclusion power.
3. Split the pack into role lanes: framework, world/content, mechanics, visuals, translation, optimization, compatibility patches, and testing/proof.
4. Define the next batch by one coherent role, not by "everything I felt like adding today."
5. Keep the batch small enough that you can disable/revert it as a unit during diagnosis.
6. Treat script-heavy, quest/content-heavy, animation/behavior, archive-heavy, and engine-touching batches as higher-risk; query KB before sizing them.
7. Create a separator/group name that states the batch's role, not a vague date or mood.
8. Rename mods, patches, archives, and local folders so parent/patch relationships remain obvious two months later.
9. Preserve source attribution: author, original page/source, translator, paid dependency status, and any local edits.
10. Record the batch decision in writing-modpack-devlog: why this batch exists, rollback boundary, known risks, and what must be tested.
11. Hand each candidate mod to evaluating-bgs-mods; whole-pack style does not replace per-mod fit judgment.
12. Do not call the pack done because it boots. Stability is the floor; the pack must still express its declared 风格.

Red Flags (STOP)