Read AEM runmodes from Sightly

logic.js

var SlingSettingsService = Packages.org.apache.sling.settings.SlingSettingsService;
 
use(function () {
    // Get runmodes and transform them into an object that is easier to read for Sightly
    var runmodesObj = {};
    var runmodesSet = sling.getService(SlingSettingsService).getRunModes();
    var iterator = runmodesSet.iterator();
    
    while (iterator.hasNext()) {
        runmodesObj[iterator.next()] = true;
    }
    
    return {
        runmodes: runmodesObj
    }
});

template.html

<div data-sly-use.logic="logic.js">
    <p>Current runmodes: ${logic.runmodes}</p>
    <p data-sly-test="${logic.runmodes.samplecontent}">samplecontent runmode</p>
</div>

Important note: runmodes cannot change after install and are meant to trigger OSGi configs and bundles, code should not act on them! This means that the above example should be used wisely.
thanks @alexkli for the comment

Custom run-modes -can- change after install, but not some of the baked in AEM run-modes: author/publish/crx2/crx3tar/etc

But as you precisely mentioned, it is very common to append custom runmodes to specify a logical instance e.g. publish,dev vs publish,prod1 etc then target sling:OsgiConfig nodes for OSGi service configurations as part of a build artifact. After one upacks the jar, they can easily adds custom run modes to their start shell/batch script, the custom run-modes and confirm these felix (/system/console/status-slingsettings)

@gabrielwalt If code should not act on the run mode, what's your suggestion for handling a scenario where different code is needed between a stage and prod environment? Adding an OSGi config just to distinguish the two and then using that in Sightly seems a bit overkill.