Production Skill — AI-Configured Build Safety
Shipping debug tools in a release build exposes internal commands, leaks device data, and adds unnecessary overhead. The production skill teaches your AI assistant Jahro's three-tier disable mechanism, CI/CD validation patterns, and build verification scripts.
What the skill does
When you ask your AI about production configuration, it:
- Recommends the appropriate disable tier for your build pipeline
- Generates scripting define setup for
JAHRO_DISABLE - Creates CI/CD validation scripts that verify Jahro is excluded from release builds
- Explains the priority order: preprocessor define → auto-disable → master switch
Example prompts
"Set up Jahro so it's excluded from release builds"
"Add a CI step to verify JAHRO_DISABLE is set in our production builds"
"What's the safest way to ship without Jahro on Android?"
"Configure Jahro for our build pipeline — dev builds should have it, release should not"
Three-tier disable mechanism
The skill knows Jahro's evaluation order at startup:
| Priority | Mechanism | Behavior |
|---|---|---|
| 1 (highest) | JAHRO_DISABLE preprocessor define | Jahro excluded unconditionally. Nothing else checked. |
| 2 | Auto-disable in Release Builds | If Debug.isDebugBuild is false, Jahro disables itself. On by default. |
| 3 (lowest) | Enable Jahro master switch | Global on/off in Tools → Jahro Settings. Affects all builds including editor. |
For most teams, tier 2 (auto-disable) is sufficient. The skill recommends tier 1 (JAHRO_DISABLE) when you need absolute guarantees — e.g., for console certification or enterprise compliance.
What the AI generates
Scripting define setup:
Player Settings → Scripting Define Symbols:
JAHRO_DISABLE;YOUR_OTHER_DEFINES
CI/CD validation example (Unity build script):
#if !UNITY_EDITOR
public static class BuildValidator
{
[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
static void ValidateProduction()
{
#if !JAHRO_DISABLE
if (!Debug.isDebugBuild)
Debug.LogError("[Build] JAHRO_DISABLE not set in release build");
#endif
}
}
#endifBuild pipeline check:
The AI can generate a pre-build script that verifies JAHRO_DISABLE is present in the platform's scripting defines before starting a release build, failing the build early if it's missing.
When to use each tier
| Scenario | Recommended approach |
|---|---|
| Standard dev/release cycle | Auto-disable (default). No action needed. |
| Console certification, strict compliance | JAHRO_DISABLE define on release platform |
| Temporary removal without uninstalling | Master switch off in Jahro Settings |
| CI/CD with automated builds | JAHRO_DISABLE + build validation script |
Verification
After configuring production safety:
- Create a non-development build (uncheck Development Build in Build Settings)
- Run the build — look for
"Jahro Console: Disabled in this build"in the startup log - Verify the Jahro console does not appear when pressing
~or triple-tapping - If using
JAHRO_DISABLE: check that Jahro-related code is stripped from the build
Frequently Asked Questions
What happens if I forget to set JAHRO_DISABLE?
Auto-disable (tier 2) catches it — Jahro disables itself in non-development builds by default. JAHRO_DISABLE is a belt-and-suspenders safeguard for teams that need explicit guarantees.
Does JAHRO_DISABLE affect editor play mode? Yes. The preprocessor define applies everywhere, including editor. If you want Jahro active in editor but disabled in builds, rely on auto-disable (tier 2) instead.
Can the AI set up different configurations per platform?
Yes. Unity's scripting defines are per-platform. The AI can add JAHRO_DISABLE to your Android and iOS release configurations while keeping it absent from Standalone development builds.
Related
- Lifecycle Documentation — full production lifecycle reference
- Jahro Settings — master switch and configuration options
- Troubleshooting Skill — diagnose issues with builds
- Agent Skills Overview — all 8 skills
- Install Agent Skills — setup instructions