Interpreting Mod Author Instructions

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 explicit alternative intent (different install policy, different risk tolerance, or pack-specific convention), the agent SHOULD adapt rather than push these defaults. The objective rules in this skill body still apply.

Recommended author-instruction lens:

1. Honest detailed instructions = green flag. Author who lists prerequisites, conflicts, version compatibility, FOMOD option meanings, and known issues earns trust. Curt or evasive instructions earn skepticism.
2. Patreon-locked main version or essential patches = red flag. Walls critical content behind paywall while expecting community patches; structurally breaks the community patch ecosystem.

See KB record mod-evaluation.author-signals (KB) and mod-evaluation.bb84-curator-perspective-reference for full curator essay.

Investigating Nexus mods marked not_published / hidden / removed

When the agent or a MO2 refresh reports a mod as status=not_published, status=hidden, or status=removed, do NOT default to "disable + find replacement". The priority investigation order:

1. Author republish check (highest yield) — fetch original mod's author + user.member_id; search Nexus for the same mod name; visit author's profile; confirm candidate new modid has the same user.member_id. Modders sometimes restart with a fresh modid instead of updating in place. The "dead" listing is just abandoned.
2. Author continuation off-Nexus — GitHub source, Patreon, Discord.
3. Third-party maintenance fork — Nexus search for "<mod name>" continued / updated / patched. Beware permission ambiguity.
4. Alternative implementation — different author, possibly different approach (e.g., perk-based instead of SFSE-plugin-based).

After finding the answer:

• If author republished: update MO2 mod folder's meta.ini modid= and installationFile= to the new listing. Otherwise Option B refresh forever reports not_published.
• If switched to alternative: backup old mod folder, disable in modlist.txt with [弃用] separator convention.
• ALWAYS record the investigation in docs/dev-log.md so half-year-later "why did we switch X to Y?" is answerable.

Cross-link: KB record mod-evaluation.investigating-pulled-mods.v1 for the full pattern with example cases.

Comprehensive file enumeration and cross-reference (rigor discipline)

Authors organize files into categories to communicate intent. Reading only the Main file's description is the most common shallow-investigation pattern, and it skips the half of the curator's work that actually matters.

For every mod install or update, enumerate the FULL file listing under all visible Nexus file categories:

• Main — current canonical builds. Often more than one. The variants encode game-runtime support (SFSE vs GamePass ASI), feature flags (with/without module X), color/size choices, fork lineages, and required-vs-optional prerequisites. Surface every variant to the curator with the differentiator named.
• Optional — compatibility patches and add-ons. Each carries a description identifying which other mod it patches and what game systems it touches. Walk this list one file at a time.
• Update — incremental patches against an earlier Main file. Usually require the Main file as prerequisite; do not install Update files standalone without verifying.
• Archived / Old — superseded versions. Do not install from this category by default; it exists for historical fallback, not as the recommended target.

For each Optional file the author lists:

1. Read the file description fully — what mod does it patch? What feature does it enable? Are there prerequisites listed?
2. Cross-reference the patched-mod claim against the curator's installed environment:
   • <MO2Root>/profiles/<profile>/modlist.txt — enabled (+) AND disabled (-) mods both count; the curator may re-enable a disabled CC mod and then need the patch installed.
   • <MO2Root>/profiles/<profile>/plugins.txt — active (*) plugins.
   • The actual <MO2Root>/mods/<modname>/ folder list — sometimes a mod is present but not yet active.
3. Classify the patch as install (curator has the patched mod), skip (curator does not have the patched mod and is unlikely to install it), or surface-to-curator (ambiguous case where curator should decide).

When variants exist within a single category (e.g. Main has a 1k texture build and a 2k texture build), do not auto-pick. Surface the variant set to the curator with the differentiator named, the trade-off summarized, and the recommended default highlighted. The curator decides.

Concrete illustrations:

• Stroud Premium Edition (Nexus #12330) main 2.5.3 file ships with four Optional files: AddOn - SPE x TerranArmada, Patch SPE x Useful MessHalls, Patch SPE x Useful Infirmaries, AddOn - SPE x Deimog. For a curator who has Terran Armada DLC and Useful Infirmaries CC mod, the first two of those four are install-relevant. The other two are skips because the curator does not have MessHalls or Deimog. Recommending all four wastes the curator's time; recommending only the main without enumerating the four wastes compatibility benefit.
• Starfield Shader Injector (Nexus #5562) main category lists two simultaneously-uploaded files: SSI-1_10 (GamePassASI-1_16_236) and SSI-1_10 (SFSE-1_16_236). Same version, different runtime. Curator-pick on Steam vs Game Pass; never auto-install both.

The corresponding KB record install-planning.audit-workflow-rigor.v1 defines this as one of six audit-grade rigor disciplines.

See also

• evaluating-bgs-mods — upstream judgment: decides whether the mod belongs in the pack before this skill interprets installation.
• writing-bgs-load-order — plugin enablement, plugins.txt, load-order, and sorting mechanics after install planning.
• xedit-conflict-audit — record-level conflict and winning-override inspection.
• using-bgs-archive — BA2/BSA inspection, extraction, and overlay-safe archive work when the author's instructions require asset operations.
• using-bgs-papyrus — PSC/PEX compile/decompile when author instructions require script work.
• using-bgs-translator — plugin text translation and SST/XML export when author instructions require localization work.
• bgs_kb_query — required source for game-specific install facts, runtime hazards, and operational conventions.