gamealgo-cli 0.3.2 → 0.3.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gamealgo-cli",
-  "version": "0.3.2",
+  "version": "0.3.4",
   "description": "GameAlgo command-line client for AI agents and game developers",
   "repository": {
     "type": "git",

package/skills/gamealgo/SKILL.md

@@ -65,6 +65,25 @@ Inspect the existing project before editing. Reuse existing SDK wrappers, user i
 
 Reuse events with the same business meaning, register new fields with their real JSON types, and verify non-debug context and business events with real runtime traffic.
 
+For every game, prefer stable, human-readable Chinese values for business dimensions that will appear directly in report legends, axes, selectors, or tables. This includes values such as level or stage type, game mode, placement, item name, and business outcome or failure reason. Keep event names, field names, IDs, SQL aliases, and protocol-defined enums in their required technical format. Do not rename values already used by a live game solely to translate them, because that would split one historical dimension into multiple report values.
+
+## Keep Experiment Identity Out Of Game Logic
+
+When client code implements an experiment or remote Strategy, define a stable, typed parameter contract first, including each parameter's meaning, type, valid values or unit, and local fallback. Drive game behavior only from those config parameters or from a validated script payload. Variants provide different parameter values; they are not feature flags.
+
+- A Strategy key may select the executor or parameter namespace, but its name must not choose the behavior inside that namespace.
+- Experiment display names, Run IDs, Variant IDs, and `assignment.variant` / `Variant()` results are attribution metadata. Never compare them or use them as switch cases, lookup keys, feature flags, or gameplay modes.
+- Read behavior through `Value` or the platform's typed config accessors. Use Variant identity only for logging, diagnostics, debug UI, telemetry, and report attribution.
+- Keep the local fallback in the same parameter domain as the remote value so missing, ineligible, stale, or failed configuration has explicit behavior.
+
+Before delivery, inspect changed client code for Variant or assignment-identity access and verify none of it reaches business conditionals. Test active control and treatment configs, missing configuration, and the post-promotion shape where the Variant becomes `default` while the promoted config remains active; unchanged parameters must produce unchanged game behavior regardless of the Variant name.
+
+## Protect D0 Monetization In Maker Experiments
+
+For TapTap Maker and other Maker games, do not autonomously design, create, or start an experiment that removes all ads from a user's first local day, delays the first ad until D1 or later, or otherwise moves the game's core D0 ad inventory to a later day. Many Maker games lose a large share of users before D1, so this is a direct D0 revenue-risk decision rather than an ordinary ad-timing adjustment. A broad request to optimize ads is not approval for this design.
+
+The agent may still propose conservative within-session or within-D0 tests, such as changing the first eligible level, cooldown, placement, or frequency while retaining D0 monetization. Continue with a D1-or-later first-ad design only when the developer explicitly requests that exact delay. Before any external mutation, show the developer the baseline D0 ad revenue at risk, D1 retention and reachable treatment population, traffic and duration, stop-loss threshold, and rollback plan, then obtain approval for the concrete experiment.
+
 ## Changes And Verification
 
 - Make repository changes when the selected task requires them; keep unrelated files unchanged.