EDGErepo: a base repo for the EDGE tools

Status: might do, later. Proposed by the user on 2026-10-25. Not scheduled. Nothing is built.

The problem

Each EDGE repo was started by copying the files of an older one, and each copy has since changed on its own. On 2026-10-25, across the 14 EDGE repos checked out on the dev PC:

Some of the differences are on purpose, like each tool’s name and colours. Others are fixes made in one repo and never carried over. The Nexus scripts showed the cost on 2026-10-25: the fix for the upload signature had to be made in REDnode and in REDagent.

The idea

One repo, EDGErepo (Edgemodders/EDGErepo), with two halves that are used in different ways:

Scaffolding

• EDGErepo is marked as a template repository. A new tool starts from it, then fills its placeholders: the name (EDGE… or RED…), the accent colour, the one-line description, the docs site’s nav.
• The CLAUDE.md skeleton holds the conventions every repo repeats today: commits straight to main, the git identity per repo, the changelog rule, the release gate, the writing style, never committing game files, the docs site rules. Each repo then adds its own status and next steps.
• The template holds the best current copy of each file, gathered from the newest repos first. Existing repos are not rebuilt from it.

Shared release machinery

• A reusable workflow, for example .github/workflows/nexus.yml, that a repo’s own release workflow calls after it has built its zip:

  nexus:
    needs: build
    uses: Edgemodders/EDGErepo/.github/workflows/nexus.yml@v1
    with:
      version: $
      zip-artifact: release-zip
    secrets: inherit
  

• Each repo keeps its own build steps and its own nexus/nexus.json and nexus/description.bbcode. Only the steps every tool shares move.
• Repos call a tag (@v1), so a change in EDGErepo reaches them only when the tag moves: one place to fix, and no surprise in a release.
• On the dev PC, nexus pull and nexus status run from the EDGErepo checkout and are pointed at the repo’s nexus/ folder.

Game mods and extensions

The EDGE tools ship in two kinds, and Nexus treats them differently:

The Nexus step is the same for both kinds. What differs is a setting, so it lives in each repo’s nexus/nexus.json:

• "kind": "game-mod" or "kind": "extension" (or "app"), with no default: a nexus.json without it stops the release, so a missing setting can never put an extension on Vortex’s button.
• The kind sets the Nexus upload: game-mod turns Mod Manager Download on, the others turn it off. Today the scripts read upload.modManager directly; kind replaces it.
• Each repo still builds its own zip, since its contents differ by kind.

Publishing to the marketplaces is a second reusable workflow, extension.yml, for the extension repos only: package the VSIX once, publish it to the VS Code Marketplace and Open VSX, and hand the same VSIX to the Nexus step. Today each extension repo has its own copy of those steps (REDcode, EDGEdeck, EDGEmat and EDGEwave all run vsce publish and ovsx publish). A game mod’s release calls only the Nexus workflow; an extension’s calls both.

Open questions

Phases, if taken up