Conversation language: This skill document is in English, but all output to the user MUST be in the user's input language. English input → English reply; Chinese input → Chinese reply; Japanese input → Japanese reply. If uncertain, default to English. This applies to all output: section titles, phase names, template prompts, example text, option lists, etc. ⚠️ CRITICAL: Template localization is CLI-owned. Do NOT manually translate imported template content with the model. Use the

src/tracking/i18n

module as the source of truth by setting

AE_LANG=<user_lang>

, writing

draft.meta.lang

, and regenerating through

ae-cli tracking code import-template

/

ae-cli tracking plan draft

. Before changing any template-owned localized label, first look up the corresponding translation in

src/tracking/i18n

(for example

resources/xlsx/sheets.ts

,

resources/xlsx/headers.ts

,

resources/xlsx/types.ts

, and

resources/cli/*.json

). If no matching translation exists there, preserve the imported text and ask before rewriting business semantics. Do NOT copy Chinese text verbatim from this document into English/Japanese replies unless it is an identifier, template name needed for CLI import, or original source material quoted for traceability.

Phase 1 / 3 / 4 are executed via

ae-cli tracking

CLI (

ae-cli tracking plan draft

/

ae-cli auth login

/

ae-cli tracking plan upload

/

ae-cli tracking plan delete

). All CLI commands must be prefixed with

AE_LANG=<user_lang>

(e.g.

AE_LANG=en ae-cli tracking plan draft ...

), ensuring CLI output messages and generated xlsx headers match the user's language. Upload commands MUST also pass

--lang <user_lang>

so the server parses the uploaded xlsx with the same sheet/header language.

Language rules: For newly generated content, user-facing fields in draft.json (

display_name

,

event_desc

,

event_tag

, property

display_name

, property

desc

, etc.) should be generated in the user's input language. Every event, event property, common event property, and user property must have a non-empty

display_name

. A canonical snake_case identifier is not a substitute for a user-facing display name. For imported templates, do NOT translate those fields manually. Template sheet names, headers, property type display values, CLI messages, and auto-track/i18n-owned labels must come from

src/tracking/i18n

via

AE_LANG=<user_lang>

and

draft.meta.lang

. When a localized label is needed, inspect

src/tracking/i18n

and use the existing resource key/value; do not invent translations from the model. If template business text needs localization and the CLI/i18n resources do not provide it, preserve the imported text and ask the user before rewriting business semantics. Only identifier fields like

event_name

,

prop_name

remain in English snake_case (canonical format). This skill only cares about command behavior, not internal implementation.

Step 1: Language initialization

Determine

<user_lang>

from user's input language: Chinese→

zh

, English→

en

, Japanese→

ja

, Korean→

ko

. Other languages default to

en

. All subsequent CLI commands must be prefixed with

AE_LANG=<user_lang>

to ensure CLI output and generated xlsx headers match the user's language. When uploading the xlsx, pass

--lang <user_lang>

as well; it must match

draft.meta.lang

/ the generated xlsx language.

cli-token.json

Choose your source material (up to 2):

1 - Product document (local path, image file, or folder) — Extract events and properties from product docs; supports md/pdf/docx/URL/images (png/jpg/jpeg/webp)
2 - Detailed description (conversational) — Describe app business flow, core features, user behaviors, monetization model, etc.
3 - Codebase (local project path; hidden in sandbox) — Analyze source code to extract events and properties
4 - Pre-built template (built-in industry and game genre templates) — Select a built-in template
5 - Modify existing tracking plan (local AE format xlsx file) — Import an existing tracking plan xlsx as baseline for modification; can be combined with Product doc / Description / Codebase, but NOT with Pre-built template

Reply with number(s), e.g. 1,5 or 4. Select up to 2.

Choose your source material (up to 2):

1 - Product document (sandbox workspace path, uploaded attachment, URL, image file, or folder) — Extract events and properties from product docs; supports md/pdf/docx/URL/images (png/jpg/jpeg/webp). You can attach/upload relevant files here.
2 - Detailed description (conversational) — Describe app business flow, core features, user behaviors, monetization model, etc.
3 - Pre-built template (built-in industry and game genre templates) — Select a built-in template
4 - Modify existing tracking plan (sandbox workspace path) — Import an existing tracking plan xlsx as baseline for modification; can be combined with Product doc / Description, but NOT with Pre-built template

Reply with number(s), e.g. 1,4 or 3. Select up to 2.

1 -

2 -

3 -

1. Product document ****(****local path, sandbox workspace path, uploaded attachment, URL, image file, or folder) — Extract events and properties from product docs; supports md/pdf/docx/URL/images (png/jpg/jpeg/webp)
2. Detailed description (conversational) — Describe app business flow, core features, user behaviors, monetization model, etc.
3. Codebase (local project path; hidden in sandbox) — Analyze source code to extract events and properties
4. Pre-built template (built-in industry and game genre templates) — Select a built-in template (run

   AE_LANG=<user_lang> ae-cli tracking plan list-templates --json

   to see available templates)

meta.source_type

prd

chat

codebase

template

existing_plan

_

• Product doc → if not in a sandbox environment, ask exactly:
  text

  What is the product document path?
  
  You can provide one or more items, separated by commas or newlines:
  1. Local file path
  2. URL
  3. Image file path
  4. Folder path

• Product doc → if in a sandbox environment, ask exactly:
  text

  What is the product document path?
  
  You can provide one or more items, separated by commas or newlines:
  1. Sandbox workspace path
  2. Uploaded attachment path
  3. URL
  4. Image file path
  5. Folder path
  
  You can also attach/upload relevant files here, and I will read them from the sandbox workspace if available.

• Detailed description → If too vague, follow up on core features, user behaviors, business flows, monetization
• Codebase → ask "What is the project directory path?", then scan source to extract business logic
• Pre-built template → display matching templates for user confirmation
• Modify existing tracking plan → ask "Please provide the xlsx file path of your existing tracking plan", then follow the flow below

1. Import: Ask user for the file path, then immediately import:
   bash

   AE_LANG=<user_lang> ae-cli tracking code import-template --template <path> --out .ae-cli/draft.json

2. Check result:
   • If CLI errors (file not found / parse failure) → report error, ask user to fix the file and retry
   • If

     draft.json

     has

     events

     array empty → 🛑 Severe: No AE-format sheets found (missing

     #

     prefix sheets like

     #事件数据

     ). Tell user the file does not appear to be an AE tracking plan xlsx. User must fix the original file and re-import.
3. Content validation (when events are non-empty):
   bash

   AE_LANG=<user_lang> ae-cli tracking plan validate --in .ae-cli/draft.json --fix

4. Handle validation results by severity:
   • If validate passes with no issues at all → skip to Step 5.

   Severity	Examples	Handling	User Action
   🔧 Minor (auto-fixable)	display_name duplicate, array_row sub-property inconsistency, event name duplicate	--fix auto-fixes, writes to draft.json . Inform user of what was fixed.	None (informed)
   ⚠️ Medium (needs confirmation)	snake_case violation, property name duplicate, invalid property type, nested property parent is not a composite type	List each issue with current value → suggested fix. User confirms item by item before writing to draft.json .	Confirm each fix
   🛑 Severe	File cannot be parsed, or events array is empty after import	Reject. Tell user the specific issue. User fixes original file and re-imports.	Fix original file

   Medium issue confirmation format:

   ⚠️ The following content needs to be fixed:
   
   | # | Issue | Location | Current | Suggested |
   |---|-------|----------|---------|------------|
   | 1 | snake_case | event_name | UserLogin | user_login |
   | 2 | snake_case | prop_name | vipLevel | vip_level |
   | 3 | invalid type | property "level" | integer | number |
   
   Apply all suggested fixes? ok / specify per item / skip

   • ok

     → apply all suggested fixes to

     draft.json

   • specify per item

     → confirm each item one by one

   • skip

     → keep current values, handle in Refine phase later
   ⚠️ Never modify the user's original xlsx file. All changes go into

   draft.json

   .
5. Re-validate after fixes → loop until clean, then continue to the next follow-up question (if combined with another source material), or Item 3 (if existing_plan is the only source).

codebase

1. User provides project directory path
2. Scan directory structure, identify tech stack (engine/framework/language)
3. Read core business modules (game logic, scene management, UI interaction, state/data models, networking/payment, etc.)
4. Extract from code:
   • Events: Player interaction actions (click/swipe/trigger), scene transitions, game state changes (start/pause/end), business flow nodes (purchase/upgrade/unlock)
   • Event Properties: Action parameters (bullet type/enemy level/item ID), state values (score/HP/coins), context (level ID/difficulty/mode)
   • User Properties: Persistent state (level/experience/VIP/cumulative spend)
5. Map extracted results to AE naming conventions (

   snake_case

   event names +

   display_name

   in user's language)
6. Confirm extracted results with user, supplement missing items

template

existing_plan

prd

codebase

chat

template_prd

template

template_prd

template_codebase

template_chat

Business Dimension (inherited from template: <template name>)

Revenue Model: <revenue_model>
Core Loop: <core_loop>
Functional Entries: <functional_entries>
Currency System: <currency_system>

Confirm using these business dimensions? ok / modify

• User

  ok

  → proceed to next step
• User says "modify" → switch to prd/chat flow for user to supplement
• For combos (e.g.

  template_prd

  ): after confirming template dimensions, also note any supplementary insights from

  prd

  /

  chat

  as context for Phase 1.2.

1. Analyze existing events: Examine

   event_tag

   values to identify functional modules (e.g. events tagged "Battle" → 战斗 module). Examine event names for payment/ad-related patterns to infer revenue model.
2. Inference display: Format inference results as a summary:

   Business Dimension (inferred from existing plan: <filename>)
   
   Revenue Model: <inferred from payment/ad events>
   Core Loop: <inferred from event flow>
   Functional Entries: <inferred from event_tag values>
   Currency System: <inferred from currency-related properties>
   
   Confirm these business dimensions? ok / modify

3. Follow up missing: Only ask about items that could not be inferred
4. Event injection preview: Show suggested injected event modules (only add events not already in the plan); user

   ok

   to proceed

• For combos (e.g.

  existing_plan_prd

  ): after confirming dimensions from the plan, also note any supplementary insights from

  prd

  /

  chat

  as context for Phase 1.2.

1. Inference display: Format inference results as a summary, using

   business-dimension-mapping.md

   as the mapping baseline
2. Follow up missing: Only ask about missing items or items inferred as "simple"
3. Event injection preview: Show suggested injected event modules; user

   ok

   to proceed

business-dimension-mapping.md

AE_LANG=<user_lang> ae-cli tracking plan list-templates --json

existing_plan（blocking validation, always first）→ codebase/prd（user's selection order）→ chat → template

• existing_plan

  must go first — import + validate may require the user to fix their file; processing it early avoids wasted context

• codebase

  /

  prd

  — directly reflect actual business requirements, prioritized over generic descriptions and templates

• chat

  — conversational description, supplements business context

• template

  — generic industry template, least specific to the user's business

existing_plan

existing_plan → template → codebase → prd → chat → autotrack

prop_names

The "Baseline" column identifies which source has higher merge priority (see Phase 1.2 merge order), which may differ from the user's selection order. Follow-up questioning uses the fixed order in "Multi-Source Combination Rules" above, not the user's selection order.

existing_plan + template

meta.business_dimension

"business_dimension": {
  "revenue_model": "<model>",
  "core_loop": "<description>",
  "functional_entries": ["<entry list>"],
  "currency_system": { ... },
  "ad_scenes": [],
  "iap_items": []
}

Language filter: The following SDKs have Chinese-only documentation and are visible to Chinese users only:

Mini-program

,

Mini-game

,

OpenHarmony

,

LayaAir

,

Egret

,

Cocos2d-Lua

. Do not show these to non-Chinese users.

sdk_integration_mode: "server_only"

client_platform_languages

"client_platform_languages": {
  "android": ["java", "kotlin"],
  "openharmony": ["typescript"]
}

⚠️ Multi-platform meta field rules: When ≥2 client platforms are selected, Draft meta must use

client_platforms

(array) +

client_platform_languages

(dictionary). Do NOT use only

client_sdk_type

(single value) +

client_language

(single value), which would only record one platform. Single-platform scenarios use

client_sdk_type

+

client_language

.

both

both

both

both

both

both

both

both

both

both

both

client_only

none

both

client_only

server_only

none

none

Other

• auto

  — SDK auto-generates (default, suitable for most scenarios)

• device_id

  — Use device ID (iOS IDFV / Android AndroidID)

• custom

  — Custom visitor ID (must call

  identify()

  immediately after SDK init)

custom

• user_account

  — User account ID (unique identifier after login)

• role_id

  — Role ID (game-specific; one account may have multiple roles)

• none

  — No account system (pure guest mode)

• chose

  user_account

  → ask "What specific value for account ID? e.g.: user_id (user ID), phone (phone number), email (email address)"
• chose

  role_id

  → explain "Role ID is suitable for games — one account can create multiple roles, enabling finer-grained per-role behavior analysis"

meta.user_identity

Draft
├── meta:
│   ├── app_type:                   App type
│   ├── sdk_integration_mode:       SDK integration mode: client_only / server_only / both
│   ├── client_platforms?:          Client SDK type list (required when multi-platform, e.g. ["android","ios"])
│   ├── client_sdk_type?:           Primary client SDK type (single platform, backward compatible)
│   ├── client_platform_languages?: Per-platform languages (required when multi-platform, e.g. {"android":["kotlin"],"ios":["swift"]})
│   ├── client_language?:           Client dev language (single platform, backward compatible)
│   ├── server_language?:           Server dev language (only when server_only or both)
│   ├── project_id?:                AE project ID (filled in Phase 3)
│   ├── host?:                      AE web address (filled in Phase 3)
│   ├── plan_name:                  Plan name
│   ├── lang:                       xlsx output language (zh/en/ja/ko), based on user's current language; controls generated xlsx headers/sheet names
│   ├── scenario:                   Business scenario description
│   ├── source_type:                Source material type
│   ├── user_identity:              User identity config
│   │   ├── account_id_source:      Account ID source: user_account / role_id / none
│   │   ├── account_id_field?:      Account ID field name (only when user_account, e.g. user_id / phone / email)
│   │   ├── distinct_id_strategy:   Visitor ID strategy: auto / device_id / custom
│   │   └── distinct_id_custom_value?: Custom visitor ID value
│   └── business_dimension:         Business dimension config (injected in Phase 1.3)
│       ├── revenue_model:          Revenue model: IAA / IAP / mixed / subscription / commission
│       ├── core_loop:              Core gameplay loop description
│       ├── functional_entries:     Functional entry list
│       ├── currency_system:        Currency system
│       ├── ad_scenes:              Ad scenes (IAA / mixed only)
│       └── iap_items:              IAP items (IAP / mixed only)
├── events:                         Event array, each with platform field
├── event_properties:               Global event property pool (deduplicated)
├── common_event_properties:        Common/super properties (attached to every event)
└── user_properties:                User properties

// Multi-platform example (Android + iOS)
{
  "sdk_integration_mode": "both",       // client_only / server_only / both
  "client_platforms": ["android", "ios"],   // Required for multi-platform
  "client_platform_languages": {            // Required for multi-platform; per-platform languages
    "android": ["kotlin"],
    "ios": ["swift"]
  },
  "server_language": "java"                // Only when server_only or both
}

// Single platform example (backward compatible)
{
  "sdk_integration_mode": "client_only",
  "client_sdk_type": "android",            // Single platform
  "client_language": "kotlin"              // Single platform
}

events[].platform

{
  "event_name": "order_create",
  "display_name": "Order Create",
  "platform": "server",    // client / server / both
  "prop_names": ["order_id", "order_amount", "payment_method"],
  "source": "prd"
}

• platform: "client"

  — Client-side upload (user behavior events)

• platform: "server"

  — Server-side upload (business data events)

• platform: "both"

  — Both sides upload (timestamps must be synced)

event_properties

common_event_properties

{
  "name": "order_amount",
  "display_name": "Order Amount",
  "type": "number",
  "desc": "Order total in cents",
  "source": "prd"
}

⚠️ Field names: use

name

(NOT

prop_name

),

display_name

,

type

,

desc

,

source

. Events reference properties by

prop_names: ["order_amount", ...]

— this is an array of property

name

references (string array), NOT property objects.

user_properties

{
  "name": "vip_level",
  "display_name": "VIP Level",
  "type": "number",
  "desc": "Current VIP level of the user",
  "source": "chat",
  "update_type": "user_set"
}

update_type

is one of:

user_set

(overwrite),

user_setOnce

(first-set-only),

user_add

(numeric accumulate).

meta.user_identity

{
  "account_id_source": "user_account", // Account ID source: user_account / role_id / none
  "account_id_field": "user_id",       // Account ID field name (only when user_account)
  "distinct_id_strategy": "auto",      // Visitor ID strategy: auto / device_id / custom
  "distinct_id_custom_value": null     // Custom visitor ID value description (only when strategy=custom)
}

string

number

bool

datetime

object

array_row

parent.child

array_string

snake_case

display_name

prop_names

• existing_plan: Already imported and validated in Phase 0 (see "Modify Existing Tracking Plan Flow"). Events are in draft.json as the baseline; each item marked

  source: "existing_plan"

  . Higher-priority sources supplement with new events only; same-name events keep the existing_plan version.
• template: User-selected industry template (see "Template Lookup Convention" below) as baseline; each item marked

  source: "template"

  • Templates are resolved by ae-cli from the ae-cli package root and user template directory
  • Import command:

    AE_LANG=<user_lang> ae-cli tracking code import-template --template-name "<template name>" --out .ae-cli/draft.json

  • ⚠️ Must validate immediately after template import (see Phase 1.6); template content may not be fully correct
  • ⚠️ Do not manually translate template content after import: Do NOT read draft.json and model-translate

    display_name

    ,

    event_desc

    ,

    event_tag

    , or property

    display_name

    /

    desc

    . Keep imported business content as produced by the CLI/template reader unless the user explicitly asks for semantic rewriting.
  • ⚠️ Use

    src/tracking/i18n

    for localization owned by the CLI:

    AE_LANG=<user_lang>

    +

    draft.meta.lang

    control CLI messages, xlsx sheet names, xlsx headers, property type display values, and auto-track/i18n-owned labels. If these are wrong, inspect the existing translations under

    src/tracking/i18n

    , then regenerate with the intended locale instead of editing labels by hand.
  • ⚠️ No model-invented translations for template labels: When replacing or explaining a localized template-owned label, use the exact value from

    src/tracking/i18n

    resources. If no corresponding resource exists, preserve the template text and ask the user before changing semantics.
  • ⚠️ event_tag is not free-form model translation: Do not manually map

    业务事件

    /

    系统事件

    to another language. Preserve template tags, or rely on

    src/tracking/i18n

    and autotrack generation for system labels when the CLI owns them.
• codebase: Scan project source directory, extract events/properties from business logic; same-name events merge prop_names without overwriting existing fields; new items

  source: "codebase"

• prd: Read all user-provided product documents (md / pdf / docx / URL / images), extract events and properties from each file; same-name events merge prop_names without overwriting existing fields; image files analyzed via multimodal interpretation of UI elements and interaction flows; all new items

  source: "prd"

  • prd path is a folder: Recursively scan all files in the directory:
    • md/pdf/docx → read text content, extract events/properties
    • png/jpg/jpeg/webp → multimodal interpretation, analyze UI elements and interaction flows
    • subdirectories → recurse
    • other files → skip
  • prd path is a URL: Fetch URL content directly, process by the same rules above
• chat: Anchor phase business scenario + refine phase edit instructions,

  source: "chat"

• autotrack: Auto-inject SDK auto-track events based on

  meta.client_sdk_type

  (only for

  client_only

  or

  both

  mode),

  source: "autotrack"

meta.business_dimension

IAA

ad_show

ad_click

ad_reward_get

IAP

payment

payment_fail

mixed

subscription

subscription_start

subscription_renew

subscription_cancel

commission

order_create

order_paid

commission_settled

core_loop

stage_start

stage_complete

stage_fail

token_get

token_type=diamond

token_amount

gacha_draw

pool_type

draw_count

hero_get

hero_id

stage_start

stage_complete

stage_fail

stage_id

gacha_draw

pool_type

draw_count

hero_get

shop_open

shop_buy

token_balance

guild_join

guild_donate

guild_boss_start

rank_view

rank_refresh

rank_click

task_accept

task_complete

task_reward_claim

achieve_unlock

achieve_reward_claim

daily_sign

sign_reward_claim

token_get

token_type=diamond

token_amount

token_balance

source

token_get

token_type=gold

token_amount

token_balance

source

token_consume

token_type

token_amount

token_balance

consume_type

token_consume

token_type

token_amount

token_balance

consume_type

1. Business dimension events marked

   source: "business_dimension"

2. When merging with source material events, same-name events keep the source material version, do not overwrite
3. When revenue model is

   none

   (no monetization), skip revenue-related event injection

• sdk_integration_mode === "client_only"

  → inject auto-track events

• sdk_integration_mode === "both"

  → inject auto-track events (client side only)

• sdk_integration_mode === "server_only"

  → do NOT inject (server SDKs have no auto-track)

• sdk_integration_mode === "none"

  → do NOT inject (no SDK; data ingestion via other methods)

1. Only inject recommended events; optional events are not auto-injected (prompted in Refine phase for optional enablement)
2. Auto-track events placed at the end of

   events

   array, marked

   source: "autotrack"

3. Auto-track event

   event_tag

   set to

   "System Event"

4. Auto-track events only carry preset properties (

   prop_names

   is empty or contains only preset property names)
5. Preset properties prefixed with

   #

   are not added to

   event_properties

   pool (auto-collected by SDK)
6. Cleanup + Deduplication: The CLI will:
   • Remove auto-track events inherited from templates or existing plans that don't match the user's selected SDKs. For example: if a template built for Android/iOS contains

     ta_app_install

     ,

     ta_app_start

     ,

     ta_app_end

     but the user selects JavaScript SDK, those

     ta_app_*

     events will be automatically removed since JavaScript SDK does not support them.
   • Inject the correct auto-track events for the user's selected SDKs.
   • Deduplicate by event name globally — won't inject events that already exist in the draft (correct auto-track events inherited from templates are kept).

references/autotrack-events.md

ta_app_install

ta_app_start

ta_app_end

ta_app_view

ta_app_click

ta_app_crash

ta_page_show

ta_page_hide

ta_pageview

ta_mp_launch

ta_mp_show

ta_mp_hide

ta_mp_view

ta_mp_share

ta_page_leave

ta_add_favorite

ta_mp_click

ta_mp_launch

ta_mp_show

ta_mp_hide

ta_app_install

ta_app_start

ta_app_end

ta_scene_loaded

ta_scene_unloaded

ta_mg_launch

ta_mg_show

ta_mg_hide

ta_scene_loaded

ta_scene_unloaded

ta_app_install

ta_app_start

ta_app_end

• Auto-track events are the SDK's built-in auto-reporting mechanism; you do not need to manually define same-name events
• Example: JavaScript SDK's

  ta_page_show

  auto-collects page views; no need to define

  home_page_show

  ,

  about_page_show

  etc.
• If templates already contain auto-track events (e.g.

  ta_app_install

  in industry templates), CLI will not inject duplicates
• These events require enabling corresponding switches during SDK initialization in the

  ae-generate-tracking-code

  phase

{
  "event_name": "ta_app_install",
  "display_name": "App Install",
  "event_desc": "Triggered on first app install; upgrades do not trigger; reinstall after deletion triggers",
  "event_tag": "System Event",
  "platform": "client",
  "prop_names": [],
  "source": "autotrack"
}

platform

"client"

• Save draft to

  .ae-cli/draft.json

• ⚠️ Write

  meta.lang

  : Set

  draft.meta.lang

  based on user's current language (

  zh

  /

  en

  /

  ja

  /

  ko

  ), ensuring generated xlsx headers / sheet names / type values match the AE platform language
• Must verify file was updated after writing (check file modification time or content); only generate xlsx after confirming new content
• Generate upload-ready xlsx:

AE_LANG=<user_lang> ae-cli tracking plan draft --in .ae-cli/draft.json --out .ae-cli/draft.xlsx

AE_LANG=<user_lang> ae-cli tracking plan draft --in .ae-cli/draft.json --out .ae-cli/draft.xlsx --fix

display_name

array_row

^[a-z][a-z0-9_]*$

1. CLI auto-validates draft.json
2. Fixable issues found → auto-fix → update draft.json → generate xlsx
3. Non-fixable issues found → error; manual fix of draft.json needed
4. No issues → proceed to Phase 1.7

vip_level

Relationship to Phase 0 existing_plan validation: The underlying rule engine is the same, but Phase 0 uses interactive 3-tier (Minor/Medium/Severe) because the user is present to confirm each fix. Phase 1.6 uses batch 2-tier (auto-fixable / manual-fix-needed) because it runs as part of the automated draft generation. Rules that are "Medium (needs confirmation)" in Phase 0 appear as "❌ Manual fix needed" here — the same rule, just without the interactive prompt.

AE_LANG=<user_lang> ae-cli tracking plan list-templates --json

src/tracking/i18n

list-templates --json

name

src/tracking/i18n

./tracking-plan-template/...

1. <ae-cli package root>/tracking-plan-template/

   — bundled templates

2. ~/.ae-cli/templates/

   — user-provided template directory

.md

.md

name

AE_LANG=<user_lang> ae-cli tracking code import-template --template-name "<template name>" --out .ae-cli/draft.json

1. sdk_config (SDK config + User identity, combined) — Show SDK integration mode, platform/language, visitor ID strategy, account ID source, corresponding SDK calls
2. business (Business dimension + Business events, combined) — Show revenue model, core loop, functional entries, injected event modules (grouped by platform)
3. autotrack (Auto-track events) — Show SDK auto-track events in a separate table, note enablement method
4. common_props (Super properties) — Show all super properties, note usage scenarios and considerations
5. props (Event properties + User properties) — Show event property pool grouped by event + user properties table

1. Display corresponding section of current draft
2. Ask a segment-specific confirmation question. Always include the current segment number, current segment key, and next segment key:
   text

   Segment <n>/5 <segment_key> confirmed? Reply ok to continue to Segment <n+1>/5 <next_segment_key>, or describe changes.

   For Segment 5:
   text

   Segment 5/5 props confirmed? Reply ok to archive the plan and continue to Phase 3, or describe changes.

3. User gives natural language instructions → update

   .ae-cli/draft.json

   → re-run:
   bash

   AE_LANG=<user_lang> ae-cli tracking plan draft --in .ae-cli/draft.json --out .ae-cli/draft.xlsx

4. User

   ok

   → proceed to next segment

ok

ok

ok

client_only

both

• These events are auto-collected by the SDK; no manual track() calls needed during code generation — just enable corresponding switches during SDK init

• display_name

  or

  event_desc

  can be adjusted; event names cannot be changed

name

display_name

type

desc

• Super properties are attached to every event; ideal for business-wide global dimensions
• Common super properties (by app type):
  • H5/Web:

    channel

    (source channel),

    referrer_domain

    (referring domain)
  • Mobile App:

    channel

    ,

    app_version

    ,

    platform

  • Game:

    channel

    ,

    vip_level

    ,

    server_id

  • Mini-program:

    channel

    ,

    scene

• Prohibited: Do NOT set SDK preset properties (

  #

  prefix) as super properties

• Event properties:

  name

  /

  display_name

  /

  type

  /

  desc

  , grouped by

  event_tag

• User properties:

  name

  /

  display_name

  /

  type

  /

  update_type

  /

  desc

user_setOnce

user_set

user_add