@thinkingai/ae-cli 1.0.1

package/skills/te-engage/references/whitelist-list.md

@@ -0,0 +1,19 @@
+# te-engage +whitelist-list
+
+> **前置条件:** 阅读 [`../../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+查询项目下的白名单列表。
+
+映射命令: `te-cli te-engage +whitelist-list`
+
+## Flags
+
+| Flag | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `--project-id` / `-p` | number | 是 | 项目 ID |
+
+## 示例
+
+```bash
+te-cli te-engage +whitelist-list --project-id 1
+```

package/skills/te-meta/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: te-meta
+version: 1.0.0
+description: "TE metadata and tracking-plan governance: event/property management, metric creation and updates, batch metadata editing, virtual events/properties, project configuration and members, tracking plans (track program), milestones/date markers (mark time), and entity catalog. Triggered when users mention editing tracking, tracking dictionaries, event/property governance, building metrics, checking project config, maintaining track programs, or managing mark time."
+metadata:
+  requires:
+    bins: ["ae-cli"]
+  cliHelp: "ae-cli te_meta --help"
+---
+
+# te-meta
+
+> **CRITICAL - Before starting, MUST first read [`../te-shared/SKILL.md`](../te-shared/SKILL.md)**: authentication, host configuration, global parameters, and write-operation confirmation rules are all there.
+> **CRITICAL - Before performing write operations, MUST first read [`../te-common/SKILL.md`](../te-common/SKILL.md)**: the unified post-operation constraints (resource-link completion after create/update) are defined there.
+> **CRITICAL - For all commands that require `project_id`, MUST follow `te-common`'s `PROJECT_ID_GATE` (if missing, stop and confirm with the user).**
+> **CRITICAL - Before running any `+<tool_name>` command, MUST first read the corresponding reference doc `./references/<tool-name>.md`**. For example: before running `+create_metric`, you must first read [`./references/create-metric.md`](./references/create-metric.md)
+
+## When to Use
+
+When the user needs "metadata governance and project configuration" capabilities, use `te-meta`:
+
+- Event/property metadata queries: `+list_events`, `+list_properties`
+- Metric and virtual metadata governance: metric / batch metadata / virtual event/property
+- Project configuration: `+get_project_config`, `+list_project_users`
+- Tracking plans and date markers: track program / mark time
+- Entity catalog: `+list_entities`
+
+## Command Format
+
+`ae-cli te_meta +<tool_name> [options]`
+
+## Tool Groups (20)
+
+### Metadata and Governance (10)
+- `+list_events` ([documentation](./references/list-events.md))
+- `+list_properties` ([documentation](./references/list-properties.md))
+- `+list_metrics` ([documentation](./references/list-metrics.md))
+- `+get_metric` ([documentation](./references/get-metric.md))
+- `+create_metric` ([documentation](./references/create-metric.md))
+- `+update_metric` ([documentation](./references/update-metric.md))
+- `+batch_edit_metadata` ([documentation](./references/batch-edit-metadata.md))
+- `+batch_create_metadata` ([documentation](./references/batch-create-metadata.md))
+- `+create_virtual_event` ([documentation](./references/create-virtual-event.md))
+- `+create_virtual_property` ([documentation](./references/create-virtual-property.md))
+
+### Project and Tracking (9)
+- `+get_project_config` ([documentation](./references/get-project-config.md))
+- `+list_project_users` ([documentation](./references/list-project-users.md))
+- `+get_track_program` ([documentation](./references/get-track-program.md))
+- `+save_track_items` ([documentation](./references/save-track-items.md))
+- `+delete_track_items` ([documentation](./references/delete-track-items.md))
+- `+create_project_mark_time` ([documentation](./references/create-project-mark-time.md))
+- `+update_project_mark_time` ([documentation](./references/update-project-mark-time.md))
+- `+list_project_mark_times` ([documentation](./references/list-project-mark-times.md))
+- `+delete_project_mark_times` ([documentation](./references/delete-project-mark-times.md))
+
+### Entity Catalog (1)
+- `+list_entities` ([documentation](./references/list-entities.md))
+
+## Quick Verification
+
+```bash
+ae-cli te_meta --help
+npm run verify:te-meta-tools
+# Example: use dry-run to preview the request (replace project_id with your actual project ID)
+ae-cli te_meta +list_events --project_id <YOUR_PROJECT_ID> --dry-run
+```
+
+## Reference Docs
+
+See the `references/` directory (20 per-command docs total).

package/skills/te-meta/references/batch-create-metadata.md

@@ -0,0 +1,37 @@
+# te_meta +batch_create_metadata (Batch Create Metadata)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Metadata Query**
+
+## Use Cases
+- Batch create SYSTEM METADATA in one atomic request (events/eventProperties/userProperties) and apply name-based associations. This tool is only for effective production metadata, not tracking-plan metadata. For bury plan draft/review/publish data, use BuryProgramTool only.
+
+## Commands
+```bash
+te-cli te_meta +batch_create_metadata --project_id 1
+te-cli te_meta +batch_create_metadata --project_id 1 --events '[{"eventName":"purchase"}]' --event_properties '[{"propName":"price","selectType":"number"}]' --user_properties '[{"propName":"vip_level","selectType":"string"}]'
+te-cli te_meta +batch_create_metadata --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--events` | No | Event creation list. Each item: eventName(required), eventDesc(optional), remark(optional), superEventPropNames(optional List<String>). |
+| `--event_properties` | No | Event property creation list. Each item: propName(required), selectType(required canonical: number/string/date/bool/list; aliases like datetime/timestamp/time auto-normalize to date), propDesc(optional, defaults to propName when omitted), propRemark(optional), commonProp(optional boolean), superEventNames(optional List<String>). |
+| `--user_properties` | No | User property creation list. Each item: propName(required), selectType(required canonical: number/string/date/bool/list; aliases like datetime/timestamp/time auto-normalize to date), propDesc(optional, defaults to propName when omitted), propRemark(optional). |
+
+## Decision Rules
+- For the first run, pass only the required parameter (`--project_id`) to confirm the path works, then add optional parameters.
+- Wrap JSON parameters in single quotes (for example `--events '{}'` and `--event_properties '{}'`) to avoid shell escaping issues.
+- At least one non-empty list among `--events`, `--event_properties`, and `--user_properties` must be provided.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+- Write operations keep confirmation prompts by default; evaluate whether to use `--yes` only for automation scenarios.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id`).
+- If `Invalid JSON` appears, first validate with the smallest JSON structure (such as `{}` or `[]`), then add fields step by step.
+
+## Recommended Chaining
+- +batch_create_metadata -> +batch_edit_metadata

package/skills/te-meta/references/batch-edit-metadata.md

@@ -0,0 +1,36 @@
+# te_meta +batch_edit_metadata (Batch Edit Metadata)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Metadata Query**
+
+## Use Cases
+- Batch edit SYSTEM METADATA already effective in project (super events / event properties / user properties). Do NOT use for tracking-plan metadata (bury/track program); tracking plan operations must use BuryProgramTool. Routing rule: if target is planned/unpublished bury metadata, never call this tool.
+- Batch edit SYSTEM METADATA already effective in project (super events / event properties / user properties).
+
+## Command
+```bash
+te-cli te_meta +batch_edit_metadata --project_id 1 --type event --items '[{"eventName":"purchase","eventDesc":"Purchase"}]'
+te-cli te_meta +batch_edit_metadata --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--type` | Yes | Type of metadata to update: event, event_property, or user_property |
+| `--items` | Yes | Batch update list. For event: eventName (required), eventDesc (optional), remark (optional). For properties: propName (required), propDesc (optional), remark (optional). |
+
+## Decision Rules
+- First run should only pass required parameters (`--project_id`, `--type`, `--items`), and add optional parameters only after the path is confirmed to work.
+- Wrap JSON arguments in single quotes (for example `--items '{}'`) to avoid shell escaping issues.
+- `--type` only accepts `event`, `event_property`, and `user_property`.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+- Write operations keep the confirmation prompt by default; re-evaluate whether to use `--yes` in automation scenarios.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in (focus on `--project_id`, `--type`, and `--items`).
+- If `Invalid JSON` occurs, validate with the smallest JSON structure first (for example `{}` or `[]`), then add fields step by step.
+
+## Recommended Chaining
+- +batch_edit_metadata -> +batch_create_metadata

package/skills/te-meta/references/create-metric.md

@@ -0,0 +1,62 @@
+# te_meta +create_metric (Create Metric)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Metadata Query**
+
+## Use Cases
+- Preliminary step: call `+get_analysis_query_schema` to get the structure, then call this tool.
+- When constructing real `events` / `params`, you must supplement project-native metadata; first call `te_meta +list_events` and `te_meta +list_properties`.
+- Create a metric from analysis configuration.
+- Creates a new metric based on event or retention analysis.
+
+## MUST Prerequisites
+- Before constructing `--events` / `--params`, you must first read and follow these reference documents:
+  - [`../../te-analysis/references/get-analysis-query-schema.md`](../../te-analysis/references/get-analysis-query-schema.md)
+  - [`./list-events.md`](./list-events.md)
+  - [`./list-properties.md`](./list-properties.md)
+- Do not generate the final `events` / `params` until the document review and prerequisite command calls above are complete.
+
+## Prerequisite Call Chain (Required for Constructing events/params)
+1. Determine `--model_type` first (`event` / `retention`).
+2. Read `get-analysis-query-schema.md`, then call `te-cli te_analysis +get_analysis_query_schema --model_type <event|retention>` to get the structure.
+3. Read `list-events.md`, then call `te-cli te_meta +list_events --project_id 1` to get available events.
+4. Read `list-properties.md`, then call `te-cli te_meta +list_properties --project_id 1` to get available properties.
+5. Build `events` / `params` from the schema + metadata, then call `+create_metric`.
+6. If an accessible URL must be returned, apply resource-link completion according to the unified `te-common` constraints (call `te_common +get_resource_url`).
+
+## Commands
+```bash
+te-cli te_meta +create_metric --project_id 1 --name demo --display_name demo --model_type event --events '[]' --params '{}'
+te-cli te_meta +create_metric --project_id 1 --name demo --display_name demo --remark demo --model_type event --events '[]' --params '{}'
+te-cli te_meta +create_metric --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--name` | Yes | Metric name. Must start with a lowercase letter and contain only lowercase letters, digits, and underscores. Maximum length: 80. |
+| `--display_name` | Yes | Metric display name |
+| `--remark` | No | Optional metric remark |
+| `--model_type` | Yes | Metric model type. Supported values: event and retention |
+| `--events` | Yes | Metric events JSON. MUST call `+get_analysis_query_schema` first, then fill event/property fields using metadata from `te_meta +list_events` / `te_meta +list_properties` in the same `project_id`. |
+| `--params` | Yes | Metric params JSON. MUST follow the schema from `+get_analysis_query_schema`; use project metadata from `te_meta +list_events` / `te_meta +list_properties` when filling referenced fields. |
+
+## Decision Rules
+- `events` / `params` must not be handwritten by intuition alone: they must satisfy both the schema structure and the project's real metadata constraints.
+- Set `--model_type` first, then use the matching schema; do not mix event/retention structures.
+- Before calling `list_events` / `list_properties`, you must first study the corresponding reference documents.
+- For the first run, pass only the required parameters (`--project_id`, `--name`, `--display_name`) to confirm the path works, then add optional parameters.
+- Wrap JSON parameters in single quotes (for example `--events '{}'` and `--params '{}'`) to avoid shell escaping issues.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+- Write operations keep confirmation prompts by default; evaluate whether to use `--yes` only for automation scenarios.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id`, `--name`, and `--display_name`).
+- If `Invalid JSON` appears, first check the schema's required fields, then verify whether the event and property names come from metadata query results in the same `project_id`.
+- If the result after writing does not match expectations, immediately reread the corresponding list/get interfaces for before-and-after comparison.
+
+## Recommended Chaining
+- +get_analysis_query_schema -> te_meta +list_events -> te_meta +list_properties -> +create_metric
+- +list_metrics -> +create_metric -> +get_metric

package/skills/te-meta/references/create-project-mark-time.md

@@ -0,0 +1,38 @@
+# te_meta +create_project_mark_time (Create Project Date Marker)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Project Configuration**
+
+## Use Cases
+- Create a project date marker. Returns the new marker ID, timestamp, content, and visibility status.
+- Create a project date marker.
+
+## Command
+```bash
+te-cli te_meta +create_project_mark_time --project_id 1 --marked_at '2026-04-09 10:00' --content demo
+te-cli te_meta +create_project_mark_time --project_id 1 --marked_at '2026-04-09 10:00' --zone_offset 8 --content demo --is_visible 1
+te-cli te_meta +create_project_mark_time --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--marked_at` | Yes | Marker timestamp. Format: yyyy-MM-dd HH:mm |
+| `--zone_offset` | No | Marker time zone offset |
+| `--content` | Yes | Marker content |
+| `--is_visible` | No | Whether the marker is visible. Default: 1 |
+
+## Decision Rules
+- First run should only pass required parameters (`--project_id`, `--marked_at`, `--content`), and add optional parameters only after the path is confirmed to work.
+- For date/time ranges, first validate with a short range, then expand the range step by step.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+- Write operations keep the confirmation prompt by default; re-evaluate whether to use `--yes` in automation scenarios.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in (focus on `--project_id`, `--marked_at`, and `--content`).
+- If the result after writing is not as expected, immediately read back the corresponding list/get interface for a before-and-after comparison.
+
+## Recommended Chaining
+- +create_project_mark_time -> +list_project_mark_times

package/skills/te-meta/references/create-virtual-event.md

@@ -0,0 +1,64 @@
+# te_meta +create_virtual_event (Create Virtual Event)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Metadata Query**
+
+## Use Cases
+- Preliminary step: call `+get_filter_schema` to get the structure, then call this tool.
+- When constructing real `events` / `filter`, you must first obtain the project's available event and property metadata.
+- Create a virtual event that combines multiple events with filters.
+- A virtual event is a composite event defined by combining multiple real events with optional filters.
+- Key parameters:
+- eventName: Unique name for the virtual event (must start with 'ta@'); the name after 'ta@' must start with a letter, and it can contain letters, numbers, and underscores, with a maximum of 60 characters.
+- eventDesc: Display name/description
+- events: JSON array of real events to combine, each with eventName and optional filter. Call get_filter_schema first to obtain the filter schema.
+
+## MUST Prerequisites
+- Before constructing `--events` / `--filter`, you must first read and follow these reference documents:
+  - [`../../te-analysis/references/get-filter-schema.md`](../../te-analysis/references/get-filter-schema.md)
+  - [`./list-events.md`](./list-events.md)
+  - [`./list-properties.md`](./list-properties.md)
+- Do not generate the final `events` / `filter` until the document review and prerequisite command calls above are complete.
+
+## Prerequisite Call Chain (Required for Constructing events/filter)
+1. Read `get-filter-schema.md`, then call `te-cli te_analysis +get_filter_schema` to get the filter structure.
+2. Read `list-events.md`, then call `te-cli te_meta +list_events --project_id 1` to get available events.
+3. Read `list-properties.md`, then call `te-cli te_meta +list_properties --project_id 1` to get properties available for filtering.
+4. Build `events` / `filter` from the schema + metadata, then call `+create_virtual_event`.
+5. Example events JSON: `[{"eventName":"purchase"},{"eventName":"add_to_cart"}]`
+
+## Commands
+```bash
+te-cli te_meta +create_virtual_event --project_id 1 --event_name ta@demo --event_desc demo --events '[{"eventName":"purchase"}]'
+te-cli te_meta +create_virtual_event --project_id 1 --event_name ta@demo2 --event_desc demo --remark demo --events '[{"eventName":"add_to_cart"}]' --filter '{}' --override true
+te-cli te_meta +create_virtual_event --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--event_name` | Yes | Unique name for the virtual event (must start with 'ta@') |
+| `--event_desc` | Yes | Display name/description |
+| `--remark` | No | Optional remarks |
+| `--events` | Yes | JSON array of events to combine. MUST follow `+get_filter_schema`, and event/property fields must come from `te_meta +list_events` / `te_meta +list_properties` in the same `project_id`. |
+| `--filter` | No | Optional global filter JSON for all events. If provided, MUST follow `+get_filter_schema`, and referenced fields must come from `te_meta +list_properties`. |
+| `--override` | No | Whether to override if event already exists. Default: false |
+
+## Decision Rules
+- `events` / `filter` must not be handwritten by intuition alone: they must satisfy both the filter schema and the project's real metadata constraints.
+- Before calling `list_events` / `list_properties`, you must first study the corresponding reference documents.
+- For the first run, pass only the required parameters (`--project_id`, `--event_name`, `--event_desc`, `--events`) to confirm the path works, then add optional parameters.
+- Wrap JSON parameters in single quotes (for example `--events '{}'` and `--filter '{}'`) to avoid shell escaping issues.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+- Write operations keep confirmation prompts by default; evaluate whether to use `--yes` only for automation scenarios.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id`, `--event_name`, and `--event_desc`).
+- If `Invalid JSON` appears, first check the filter schema's required fields, then verify whether the event and property names come from metadata query results in the same `project_id`.
+- If the result after writing does not match expectations, immediately reread the corresponding list/get interfaces for before-and-after comparison.
+
+## Recommended Chaining
+- +get_filter_schema -> te_meta +list_events -> te_meta +list_properties -> +create_virtual_event
+- +list_events -> +create_virtual_event

package/skills/te-meta/references/create-virtual-property.md

@@ -0,0 +1,69 @@
+# te_meta +create_virtual_property (Create Virtual Property)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Metadata Query**
+
+## Use Cases
+- Before creating a virtual property, first confirm the available properties and, as needed, available events from the project metadata.
+- Create a SQL-based virtual property.
+- A SQL virtual property is a computed property defined by a SQL expression.
+- Key parameters:
+- propertyName: Unique name for the virtual property (must start with '#vp@'), the name after '#vp@' must start with a letter, and can contain letters, numbers and underscores, with a maximum of 60 characters.
+- propertyDesc: Display name/description
+- tableType: event or user. Determine based on the prompt whether to create a virtual event property or a virtual user property
+- selectType: Data type (string, number, bool, datetime)
+- sqlExpression: SQL expression for computing the property
+- sqlEventRelationType: relation_default, relation_always, or relation_by_setting
+
+## Mandatory Prerequisites (MUST)
+- Before building `--sql_expression` / `--related_events`, you must first read and follow the reference docs below:
+  - [`./list-properties.md`](./list-properties.md)
+  - [`./list-events.md`](./list-events.md) (only when `sql_event_relation_type=relation_by_setting`)
+- Do not submit the final SQL and event-association configuration until the above docs have been read and the prerequisite commands have been run.
+
+## Prerequisite Call Chain (required for building SQL and relations)
+1. Read `list-properties.md`, then run `te-cli te_meta +list_properties --project_id 1` to get the available properties.
+2. Use `--table_type` to determine the SQL field source (event or user scope).
+3. Write `--sql_expression` using only fields confirmed in the previous step; the expression must conform to Trino syntax.
+4. If `--sql_event_relation_type=relation_by_setting`, read `list-events.md`, then run `te-cli te_meta +list_events --project_id 1` to get the available events and build `--related_events`.
+5. Call `+create_virtual_property` to create the virtual property.
+6. Example `sql_expression`: `property_a + property_b` or `CASE WHEN status = 1 THEN 'active' ELSE 'inactive' END`.
+
+## Command
+```bash
+te-cli te_meta +create_virtual_property --project_id 1 --property_name '#vp@demo' --table_type event --select_type string --sql_expression 'event_name' --sql_event_relation_type relation_default
+te-cli te_meta +create_virtual_property --project_id 1 --property_name '#vp@demo' --property_desc demo --table_type event --select_type string --sql_expression "CASE WHEN status = 1 THEN 'active' ELSE 'inactive' END" --sql_event_relation_type relation_by_setting --related_events '[{"eventName":"purchase"}]' --property_remark demo
+te-cli te_meta +create_virtual_property --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--property_name` | Yes | Name for the virtual property (must start with '#vp@'), the name after '#vp@' must start with a letter, and can contain letters, numbers and underscores, with a maximum of 60 characters. |
+| `--property_desc` | No | Display name/description |
+| `--table_type` | Yes | Table type. event: create virtual event property(virtual property generated based on event or user properties), user: create virtual user property(virtual property generated based on user properties) |
+| `--select_type` | Yes | Data type: string, number, bool, datetime |
+| `--sql_expression` | Yes | SQL expression for computing the property. MUST be built from fields confirmed by `te_meta +list_properties` in the same `project_id`, and MUST conform to Trino syntax (for example, columns starting with '#' or containing '@' should be double-quoted). |
+| `--sql_event_relation_type` | Yes | Type of associating attributes with events, relation_default: auto; relation_always: all events; relation_by_setting: specified events |
+| `--related_events` | No | Optional JSON array of related events. When `sql_event_relation_type=relation_by_setting`, this field is required and event names MUST come from `te_meta +list_events` in the same `project_id`. |
+| `--property_remark` | No | Optional property remark |
+
+## Decision Rules
+- `sql_expression` / `related_events` cannot be written from experience alone: they must be built from real project metadata.
+- `list_properties` / `list_events` must be read before their corresponding commands are run.
+- First run should only pass required parameters (`--project_id`, `--property_name`, `--table_type`, `--select_type`, `--sql_expression`, `--sql_event_relation_type`), and add optional parameters only after the path is confirmed to work.
+- Wrap JSON arguments in single quotes (for example `--related_events '{}'`) to avoid shell escaping issues.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+- Write operations keep the confirmation prompt by default; re-evaluate whether to use `--yes` in automation scenarios.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in (focus on `--project_id`, `--property_name`, and `--table_type`).
+- If `Invalid JSON` occurs, first check the `related_events` structure, then verify whether the event names came from the `list_events` result for the same `project_id`.
+- If SQL execution or validation fails, first check whether the field names came from `list_properties`, then check whether the Trino syntax and field references are correct.
+- If the result after writing is not as expected, immediately read back the corresponding list/get interface for a before-and-after comparison.
+
+## Recommended Chaining
+- +list_properties -> +create_virtual_property
+- +list_properties -> +list_events -> +create_virtual_property (sql_event_relation_type=relation_by_setting)

package/skills/te-meta/references/delete-project-mark-times.md

@@ -0,0 +1,34 @@
+# te_meta +delete_project_mark_times (Delete Project Mark Times)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Project Configuration**
+
+## Use Cases
+- Delete one or more project date markers.
+
+## Commands
+```bash
+te-cli te_meta +delete_project_mark_times --project_id 1 --mark_time_ids '[]'
+te-cli te_meta +delete_project_mark_times --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--mark_time_ids` | Yes | List of marker IDs |
+
+## Decision Rules
+- For the first run, pass only the required parameters (`--project_id` and `--mark_time_ids`) to confirm the path works, then add optional parameters.
+- Wrap JSON parameters in single quotes (for example `--mark_time_ids '{}'`) to avoid shell escaping issues.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+- Write operations keep confirmation prompts by default; evaluate whether to use `--yes` only for automation scenarios.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id` and `--mark_time_ids`).
+- If `Invalid JSON` appears, first validate with the smallest JSON structure (such as `{}` or `[]`), then add fields step by step.
+- If the result after writing does not match expectations, immediately reread the corresponding list/get interfaces for before-and-after comparison.
+
+## Recommended Chaining
+- +list_project_mark_times -> +delete_project_mark_times

package/skills/te-meta/references/delete-track-items.md

@@ -0,0 +1,35 @@
+# te_meta +delete_track_items (Delete Track Program Items)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Project Configuration**
+
+## Use Cases
+- Delete TRACKING-PLAN metadata items only. Do not use for effective system metadata deletion/editing; those belong to MetaPowerTool/other system metadata flows.
+- Delete TRACKING-PLAN metadata items only.
+
+## Command
+```bash
+te-cli te_meta +delete_track_items --project_id 1 --delete_data '{}'
+te-cli te_meta +delete_track_items --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--delete_data` | Yes | Delete payload JSON object with events/eventPropNames/userPropNames/commonEventPropNames. At least one list must be provided. |
+
+## Decision Rules
+- First run should only pass required parameters (`--project_id`, `--delete_data`), and add optional parameters only after the path is confirmed to work.
+- Wrap JSON arguments in single quotes (for example `--delete_data '{}'`) to avoid shell escaping issues.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+- Write operations keep the confirmation prompt by default; re-evaluate whether to use `--yes` in automation scenarios.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in (focus on `--project_id` and `--delete_data`).
+- If `Invalid JSON` occurs, validate with the smallest JSON structure first (for example `{}` or `[]`), then add fields step by step.
+- If the result after writing is not as expected, immediately read back the corresponding list/get interface for a before-and-after comparison.
+
+## Recommended Chaining
+- +get_track_program -> +delete_track_items -> +get_track_program

package/skills/te-meta/references/get-metric.md

@@ -0,0 +1,32 @@
+# te_meta +get_metric (View Metric Details)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Metadata Query**
+
+## Use Cases
+- Get the definition details of a single metric. Returns the metric name, display name, remark, model type, linked events, and parameter definition without executing metric calculation.
+- Get the definition details of a single metric.
+
+## Commands
+```bash
+te-cli te_meta +get_metric --project_id 1 --metric_id 1
+te-cli te_meta +get_metric --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--metric_id` / `-m` | Yes | Metric ID |
+
+## Decision Rules
+- For the first run, pass only the required parameters (`--project_id` and `--metric_id`) to confirm the path works, then add optional parameters.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id` and `--metric_id`).
+- If reading fails, first verify that the object ID exists and belongs to the current project.
+
+## Recommended Chaining
+- +get_metric -> +update_metric

package/skills/te-meta/references/get-project-config.md

@@ -0,0 +1,32 @@
+# te_meta +get_project_config (Read Project Analysis Configuration)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Project Configuration**
+
+## Use Cases
+- Get project configuration details. Returns: projectId, projectName, companyId, defaultTimeZoneOffset (project default time zone offset), remark, timeZoneEnabled (whether multiple time zones are supported), timeZoneOffsetColumn (time zone column name in event data), and availableTimeZones (array of time zone offsets used in this project). Call this tool when you need project basic info or time zone configuration.
+- Get project configuration details.
+
+## Command
+```bash
+te-cli te_meta +get_project_config --project_id 1
+te-cli te_meta +get_project_config --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+
+## Decision Rules
+- First run should only pass the required parameter (`--project_id`), and add optional parameters only after the path is confirmed to work.
+- `timeZoneEnabled` and `availableTimeZones` are often used to determine whether `zone_offset` can be passed to `create/update_cluster` and `create/update_tag`.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+
+## Next Steps After Failure
+- If the required parameter is missing, fall back to the smallest runnable command and fill it in (focus on `--project_id`).
+- If reading fails, first verify whether the object ID exists and belongs to the current project.
+
+## Recommended Chaining
+- +get_project_config -> +create_project_mark_time / +update_project_mark_time

package/skills/te-meta/references/get-track-program.md

@@ -0,0 +1,31 @@
+# te_meta +get_track_program (Read Tracking Plan Baseline)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Project Configuration**
+
+## Use Cases
+- Query TRACKING-PLAN metadata (bury program), including planned events/properties/common properties. This is NOT system metadata. Do NOT use MetaTool/MetaPowerTool for these plan objects.
+- Query TRACKING-PLAN metadata (bury program), including planned events/properties/common properties.
+
+## Commands
+```bash
+te-cli te_meta +get_track_program --project_id 1
+te-cli te_meta +get_track_program --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+
+## Decision Rules
+- For the first run, pass only the required parameter (`--project_id`) to confirm the path works, then add optional parameters.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id`).
+- If reading fails, first verify that the object ID exists and belongs to the current project.
+
+## Recommended Chaining
+- +get_project_config -> +get_track_program

package/skills/te-meta/references/list-entities.md

@@ -0,0 +1,34 @@
+# te_meta +list_entities (Entity Search)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Entity Query**
+
+## Use Cases
+- List entities in the project. Returns entity details such as entity ID, name, column name, column description, and type. Can be filtered by event name.
+- List entities in the project.
+
+## Command
+```bash
+ae-cli te_meta +list_entities --project_id 1
+ae-cli te_meta +list_entities --project_id 1 --event_name demo
+ae-cli te_meta +list_entities --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--event_name` | No | Optional event name filter |
+
+## Decision Rules
+- First run should only pass the required parameter (`--project_id`), and add optional parameters only after the path is confirmed to work.
+- `--event_name` is used to filter entities by event name, not for keyword search.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+
+## Next Steps After Failure
+- If the required parameter is missing, fall back to the smallest runnable command and fill it in (focus on `--project_id`).
+- If the result is empty, first confirm the project ID/keyword, then try loosening the filter conditions.
+
+## Recommended Chaining
+- +list_entities -> +create_virtual_property / +create_virtual_event

package/skills/te-meta/references/list-events.md

@@ -0,0 +1,33 @@
+# te_meta +list_events (Event Metadata Discovery)
+
+> **Prerequisite:** Read [`../te-shared/SKILL.md`](../../te-shared/SKILL.md)
+
+Domain: **Metadata Query**
+
+## Use Cases
+- Read-only query for SYSTEM METADATA already effective in the project. Use for super events in production metadata. Do NOT use for tracking-plan metadata (bury/track program); that belongs to BuryProgramTool.
+- Read-only query for SYSTEM METADATA already effective in the project.
+
+## Commands
+```bash
+ae-cli te_meta +list_events --project_id 1
+ae-cli te_meta +list_events --project_id 1 --query demo
+ae-cli te_meta +list_events --dry-run
+```
+
+## Parameters
+| Parameter | Required | Description |
+|---|---|---|
+| `--project_id` / `-p` | Yes | Project ID |
+| `--query` / `-q` | No | Optional keyword filter. Performs fuzzy matching against event names, descriptions, and AI remarks; if omitted, all events are returned. |
+
+## Decision Rules
+- For the first run, pass only the required parameter (`--project_id`) to confirm the path works, then add optional parameters.
+- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
+
+## Next Steps After Failure
+- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id`).
+- If the result is empty, first confirm the project ID/keyword, then try loosening the filter conditions.
+
+## Recommended Chaining
+- +list_events -> +create_virtual_event