Civilization VI Modding

Use this skill only for Civilization VI. Keep Civilization VII separate even when a request mentions both games.

First Pass

1. Identify whether the user is creating a new mod, editing an existing mod, or debugging a load/runtime problem.
2. Inspect the mod folder before editing. Look for .modinfo, Data/, Text/, Lua/, UI/, Art/, and any existing naming conventions.
3. Preserve the mod's current style: XML vs SQL, folder layout, id prefixes, file names, and load-order strategy.
4. If the request affects database tables, inspect existing schema usage in the project and nearby game/mod examples instead of inventing table names.
5. If the user reports a game error, ask for or inspect Database.log, Modding.log, and Lua logs before changing broad areas.

Common Files

• .modinfo: declares actions, files, dependencies, properties, and compatibility.
• XML/SQL: inserts or updates gameplay database rows.
• Text XML/SQL: updates localized strings.
• Lua: gameplay events, UI panels, scripts, and hooks.
• Logs: usually under the user's Documents\My Games\Sid Meier's Civilization VI\Logs.
• Local mods: usually under Documents\My Games\Sid Meier's Civilization VI\Mods.

Safe Workflow

For a new mod:

1. Create a clear mod id/name and a stable internal prefix, for example TAN_.
2. Create a .modinfo with UpdateDatabase actions for gameplay data, UpdateText actions for localization, and Lua/UI actions only when needed.
3. Add one feature at a time. Prefer a minimal loading mod before adding complex modifiers or Lua.
4. Use stable identifiers everywhere: LOC_... keys for text, uppercase IDs for database types, and consistent prefixes for custom rows.
5. Document any required DLC/ruleset dependency in .modinfo.

For an existing mod:

1. Read the .modinfo first to understand what files actually load.
2. Trace the requested feature from loaded file to database table or Lua entry point.
3. Make the smallest change that fits the existing structure.
4. Avoid rewriting working XML/SQL into another format unless the user asks.

For debugging:

1. Check whether the file is included in .modinfo.
2. Check load order and action type: gameplay data should be UpdateDatabase; text should be UpdateText.
3. Check SQL/XML syntax first, then missing references, then duplicate IDs.
4. Use logs to identify the exact failing file/line where possible.

Implementation Guidance

• Prefer SQL for concise bulk changes and XML for mods already organized around XML.
• Avoid changing base-game rows destructively unless the user explicitly wants an overhaul. Add new rows or narrowly update existing rows.
• Keep localization separate from gameplay data when the mod already does that.
• For modifiers, verify every chain: owner table -> modifier id -> modifier type -> arguments -> requirement sets.
• For Lua/UI work, identify whether the script runs in gameplay context, UI context, or as a replacement/addition to an existing UI file.
• Treat DLC differences carefully. Gathering Storm and Rise and Fall add systems and tables; don't assume all players have every expansion unless the mod requires it.

Mod Structure and Review Checklist

Civilization VI Modding Checklist

New Mod Structure

Use a simple, inspectable layout unless the existing project already uses something else:

MyCiv6Mod/
  MyCiv6Mod.modinfo
  Data/
    MyCiv6Mod_Gameplay.sql
  Text/
    MyCiv6Mod_Text.sql
  Lua/
  UI/
  Art/

.modinfo Checks

• The mod id is stable and unique.
• Every gameplay SQL/XML file is listed in an UpdateDatabase action.
• Every localization file is listed in an UpdateText action.
• Lua/UI files are declared using the action type expected by the existing mod pattern.
• Required DLC, expansion, or ruleset dependencies are explicit when the content relies on them.
• File paths use the actual casing and relative paths present on disk.

Database Checks

• Custom IDs use a consistent prefix.
• LOC_ keys referenced by gameplay rows exist in text files.
• Referenced types exist before use.
• Modifier IDs, modifier types, arguments, requirement sets, and subjects line up.
• Updates are narrow and include a WHERE clause unless intentionally broad.
• SQL statements end with semicolons.

Lua/UI Checks

• Confirm whether the file runs in UI or gameplay context.
• Search for existing events/hooks before adding a parallel system.
• Keep replacement UI files minimal; full UI replacement can break compatibility.
• Add defensive nil checks for game objects and context lookups.

Debugging Logs

Ask the user for relevant log excerpts if they are not in the workspace:

• Database.log for SQL/XML schema and constraint failures.
• Modding.log for action loading and file inclusion problems.
• Lua logs for runtime script errors.

When logs identify a failing file, fix that file first before broad refactors.

<!-- OB-S:Wae__6ss0J2Vw4K0ckAh4Q -->