Configures Jahro lifecycle controls for safe production deployment including JAHRO_DISABLE, auto-disable, and build validation. Use when the user mentions production builds, release builds, disabling Jahro, shipping, CI/CD, lifecycle controls, or production safety.
89
88%
Does it follow best practices?
Impact
85%
3.14xAverage score across 3 eval scenarios
Passed
No known issues
Help users configure Jahro for safe production deployment so debugging tools never leak into release builds.
Jahro evaluates these conditions at startup in priority order:
1. JAHRO_DISABLE defined? → Disabled (highest priority)
2. Auto-disable ON + Release build? → Disabled
3. Enable Jahro switch → Uses switch value (lowest priority)What: Compile-time disable. When defined, Jahro exits at initialization regardless of all other settings.
How to set:
JAHRO_DISABLE (semicolon-separated if other defines exist: MY_DEFINE;JAHRO_DISABLE)When to use: CI/CD pipelines, absolute control, platform-specific disabling (set per-platform defines).
Validation: Build logs show "Jahro Console: Disabled in this build".
What: Runtime check. Jahro checks Debug.isDebugBuild at startup. If false (Release build) and this setting is ON, Jahro disables itself.
How to set:
When to use: Recommended default for most projects. Development and Debug builds keep Jahro active; Release builds automatically disable it.
Validation: Same build log message when triggered.
What: The master toggle in Jahro Settings.
How to set: Tools → Jahro Settings → General Settings → Enable Jahro
When to use: Temporarily disable during development (e.g., testing without Jahro interference).
For most projects:
Jahro initializes via [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSplashScreen)]:
Assets/Jahro/Resources/jahro-settings.assetThe BeforeSplashScreen timing ensures Jahro is ready before any game code runs, so it captures logs from the very start.
After initialization (if enabled):
Triggered on app quit, assembly reload, or explicit Jahro.Release():
In your build script or CI/CD pipeline:
// In a custom build script
PlayerSettings.SetScriptingDefineSymbolsForGroup(
BuildTargetGroup.Android,
"JAHRO_DISABLE;OTHER_DEFINES");Or via command line:
unity -batchmode -executeMethod Build.PerformReleaseBuild \
-define "JAHRO_DISABLE"After a Release build, verify Jahro is properly disabled:
// Expected in build log output:
Jahro Console: Disabled in this buildIf this message is absent and Jahro was expected to be disabled, check:
JAHRO_DISABLE is in the correct platform's Scripting Define SymbolsAdd this to verify Jahro's state in a build:
void Start()
{
#if JAHRO_DISABLE
Debug.Log("JAHRO_DISABLE is defined — Jahro stripped at compile time");
#else
Debug.Log($"Jahro.Enabled: {Jahro.Enabled}");
if (Jahro.Enabled)
Debug.LogWarning("Jahro is ENABLED in this build — is this intentional?");
#endif
}Use this checklist before shipping:
Jahro.Enabled returns false at runtime in the Release buildjahro-settings.asset is committed to version control with correct settingsFor teams using the Jahro web console:
| Role | Permissions |
|---|---|
| Owner | Billing, subscription, team settings, role assignment, ownership transfer |
| Admin | Manage members (except Owner), configure integrations, access all content |
| Member | Create/view/edit snapshots, interact with assigned content |
Configure roles at console.jahro.io → Team Settings.
| Pattern | Suggestion |
|---|---|
| User mentions "release build" or "shipping" | Guide through production checklist |
| User mentions CI/CD or build pipeline | Show JAHRO_DISABLE in build scripts |
| User has JAHRO_DISABLE but expects Jahro to work | Explain priority: define overrides everything |
| User asks about performance in production | Reassure: disabled Jahro exits early with near-zero overhead |
Verify: Make a Release build (not Development Build). Run it. Confirm:
- Build log shows "Jahro Console: Disabled in this build"
- Console does NOT open on ~ or triple-tap
Jahro.EnabledreturnsfalseThen make a Development Build and confirm Jahro works normally.
300b45d
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.