Game Economy Inspection

game-economy-inspection

CRITICAL - This skill orchestrates a multi-step inspection pipeline. Read each step file in references/steps/ before executing. Do not skip steps or fabricate data. CRITICAL - Step 00 and Step 01 are both mandatory gates. All uncertain values (timezone, event names, property names, distinguishing properties, thresholds, scenarios, time window) MUST be explicitly confirmed by the user via numbered text replies — never assume them. Step 00 not confirmed → MUST NOT proceed to Step 01; Step 01 not confirmed → MUST NOT proceed to Steps 02-05. CRITICAL - Use ae-cli for all data operations. Read references/adapters/ae-cli.md for command patterns. Never guess command names, flags, JSON payloads, project_id, event names, property names, or parameter formats. CRITICAL - references/config/project_mapping.md is the sole bridge between business concepts and database fields. {{event.xxx}} and {{prop.xxx}} are business concept placeholders, NOT actual field names. When switching projects, only modify this file. CRITICAL - Treat references/adapters/ae-cli.md as the source of truth for command syntax. Keep methodology and metric definitions tool-agnostic.

When to Use

Use game-economy-inspection for proactive health inspection of game economy ecosystems:

• Check whether cross-domain structures are gradually degrading even though macro economy totals still look normal
• Inspect whether nurturing currency is silently devaluing (evolution stones, spirit fragments, and other nurturing resources)
• Detect equipment recycle anomalies, material accumulation, and other economy-loop issues
• Detect hero/lineup meta imbalance and narrowing consumption outlets
• Run cross-domain correlation inspection on "multi-domain, gradual, single-metric-silent" ecosystem problems

Boundary with game-economy-balance

Use this Skill to answer "Is a gradual cross-domain problem emerging?" Stop after producing verified slow-variable signals, cross-domain confidence, attribution evidence, and investigation urgency.

Do NOT use this Skill when the user already knows that production and consumption are imbalanced, or asks for any of the following; route to game-economy-balance:

• Production/consumption source-point breakdown or user-tier comparison
• Suspicious-user, studio, cheat, exploit, or RMT investigation
• Quantified resource adjustment, intervention parameters, rollback design, or governance actions
• A general-purpose economy alert system, dashboard, or monitoring SOP

If this inspection discovers a confirmed economy impact, preserve the metric evidence and attribution chain, then hand off remediation to game-economy-balance. This Skill may persist only its own §1-§11 inspection queries and configure alerts only for their user-confirmed slow-variable thresholds.

If the user intent is a single-metric ad-hoc query or non-game analysis, do NOT use this Skill — use ae-analysis directly.

Core Philosophy

Traditional BI dashboards alert on single-week thresholds — slow variables (0.3% weekly fluctuation) never trigger, but 30 days of accumulation slides them out of the safe zone. This skill fills exactly that gap:

Do not ask "is there an anomaly this week" — ask "which direction is this heading over the last period".

At the same time, it puts data scattered across combat, economy, backpack, and monetization dashboards into one chain for cross-validation — normal totals ≠ healthy structure.

Global Conventions

Working Directory

All intermediate files written to {{workspace_dir}} (default: /tmp/game-economy-inspection/). Do NOT rely on LLM memory between steps.

Status Codes

Degradation Strategy

• Individual metric query failures do not block the overall flow — mark as "Data Missing" in the final report.
• Step 00 failure → STEP_FATAL.
• Step 01 user termination → STEP_FATAL.

User Confirmation (Mandatory Gate)

Step 00 and Step 01 both have user-confirmation nodes. All confirmations use text replies: list numbered options, the user enters numbers.

• All uncertain values (timezone, event names, property names, distinguishing properties, thresholds) MUST be confirmed by the user — never assume.
• Step 00: project_id, timezone, event/property mapping, distinguishing properties.
• Step 01: scenario, time window, thresholds.
• Fuzzy matching only narrows the candidate range; the final mapping MUST be approved by the user.
• Do NOT fabricate user replies or skip confirmation nodes.

Parallelism

• Step 02: queries across domains and metrics are mutually independent — fire in one parallel batch.
• Step 04: attribution drilldowns per anomaly signal are mutually independent — parallelizable.

Language Convention

• All documentation and user-facing output are in English.
• {{event.xxx}}, {{prop.xxx}} are business concept placeholders.
• Actual field names come from references/config/project_mapping.md.

Metric Reference Convention

Step files reference metric IDs from references/metric_definitions.md (e.g. "Execute §1"). The six-element template (Intent/Semantics/Input/Dimension/Judgment/Output) keeps every metric an independently verifiable formula.

Architecture

game-economy-inspection/
├── SKILL.md                                ← Orchestrator (this file)
├── references/                             ← Platform-visible content
│   ├── adapters/ae-cli.md                  ← ae-cli command patterns (tool adapter)
│   ├── config/                             ← Configuration
│   │   ├── project_mapping.md              ← Project config (sole bridge)
│   │   └── scenarios.json                  ← Preset scenario templates
│   ├── steps/                              ← Step-by-step execution
│   │   ├── 00_preflight.md                 ← Step 00 pre-flight check
│   │   ├── 01_scope.md                     ← Step 01 define scope
│   │   ├── 02_baseline.md                  ← Step 02 baseline query
│   │   ├── 03_anomaly.md                   ← Step 03 anomaly detection
│   │   ├── 04_attribution.md               ← Step 04 attribution
│   │   └── 05_report.md                    ← Step 05 generate report
│   ├── templates/report_template.md        ← Report output template
│   ├── metric_definitions.md               ← 10 inspection metrics (§1-§10)
│   ├── methodology.md                      ← Methodology (slow variable, cross-domain, confidence)
│   ├── attribution_chains.md               ← Attribution chain templates
│   └── scenario_guide.md                   ← Custom scenario guide
└── scripts/                                ← Reserved (no scripts yet)

Step Overview

┌─────────────────────────────────────────┐
│          00 Pre-flight Check            │
└────────────────────┬────────────────────┘
                     ▼
┌─────────────────────────────────────────┐
│          01 Define Scope (Gate)         │
└────────────────────┬────────────────────┘
                     ▼
┌─────────────────────────────────────────┐
│          02 Baseline Query              │
│   (parallel 30-day trend per domain)    │
└────────────────────┬────────────────────┘
                     ▼
┌─────────────────────────────────────────┐
│          03 Anomaly Detection           │
│   (slope calc + cross-domain check)     │
└────────────────────┬────────────────────┘
                     │
              ┌──────┴──────┐
              │ anomaly?    │
              └──────┬──────┘
              no ↓       ↓ yes
            [End]   ┌──────────────┐
                    │ 04 Attribution│
                    └──────┬───────┘
                           ▼
                    ┌──────────────┐
                    │ 05 Report    │
                    └──────────────┘

Core Index

Metric Definitions → metric_definitions.md

Reference Documents

Output Templates

Tool Adapter

Verification

Every step defines explicit acceptance criteria (see each step file's "Acceptance Criteria" section). The final report must pass user-side verification before sign-off.

Data Verification (execution-time)

User-side Verification (report sign-off)

After Step 05 outputs the report, ask the user to verify before signing off:

1. Spot-check key numbers: pick 2-3 metric values and compare against the game's own dashboards. Any mismatch requires re-query.
2. Confirm anomaly judgment: for each warning/attention signal, the user confirms whether the detected direction matches business intuition.
3. Confirm attribution root cause: the user validates whether the traced root cause aligns with known version/operations events.
4. Sign-off criteria: the report is verified when (a) no critical metric is marked "Data Missing", (b) slope values are reproducible from the baseline data, and (c) the user confirms the anomaly and attribution conclusions. Otherwise return to the failed step and re-run.

Start Execution

Read and execute references/steps/00_preflight.md.