@thinkingai/ae-cli 6.0.30 → 6.0.32

package/skills/ae-analysis/references/create_virtual_event.md

@@ -1,64 +0,0 @@
-# analysis_meta +create_virtual_event (Create Virtual Event)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../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:
-  - [`./get_filter_schema.md`](./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 `ae-cli analysis +get_filter_schema` to get the filter structure.
-2. Read `list_events.md`, then call `ae-cli analysis_meta +list_events --project_id <project_id>` to get available events.
-3. Read `list_properties.md`, then call `ae-cli analysis_meta +list_properties --project_id <project_id>` 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
-ae-cli analysis_meta +create_virtual_event --project_id <project_id> --event_name ta@demo --event_desc demo --events '[{"eventName":"purchase"}]'
-ae-cli analysis_meta +create_virtual_event --project_id <project_id> --event_name ta@demo2 --event_desc demo --remark demo --events '[{"eventName":"add_to_cart"}]' --filter '{}' --override true
-ae-cli analysis_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 `analysis_meta +list_events` / `analysis_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 `analysis_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 -> analysis_meta +list_events -> analysis_meta +list_properties -> +create_virtual_event
-- +list_events -> +create_virtual_event

package/skills/ae-analysis/references/create_virtual_property.md

@@ -1,69 +0,0 @@
-# analysis_meta +create_virtual_property (Create Virtual Property)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../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 `ae-cli analysis_meta +list_properties --project_id <project_id>` 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 `ae-cli analysis_meta +list_events --project_id <project_id>` 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
-ae-cli analysis_meta +create_virtual_property --project_id <project_id> --property_name '#vp@demo' --table_type event --select_type string --sql_expression 'event_name' --sql_event_relation_type relation_default
-ae-cli analysis_meta +create_virtual_property --project_id <project_id> --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
-ae-cli analysis_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 `analysis_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 `analysis_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/ae-analysis/references/delete_cluster.md

@@ -1,27 +0,0 @@
-# analysis_audience +delete_cluster (Delete Cluster)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Cluster Management**
-
-## Use Cases
-- Permanently delete a cluster by its name.
-
-## Commands
-```bash
-ae-cli analysis_audience +delete_cluster --project_id <project_id> --cluster_name my_cluster
-ae-cli analysis_audience +delete_cluster --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--cluster_name` | Yes | Cluster name to delete |
-
-## Decision Rules
-- Use `+list_clusters` first to confirm the cluster name before deleting.
-- This is a destructive operation; keep the confirmation prompt unless automation is explicitly required.
-
-## Recommended Chain
-- `+list_clusters` -> `+delete_cluster`

package/skills/ae-analysis/references/delete_dashboard.md

@@ -1,30 +0,0 @@
-# analysis +delete_dashboard (Delete Dashboard)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Dashboard Management**
-
-## Use Cases
-- Permanently delete a dashboard by its ID.
-
-## Commands
-```bash
-ae-cli analysis +delete_dashboard --project_id <project_id> --dashboard_id <dashboard_id>
-ae-cli analysis +delete_dashboard --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--dashboard_id` | Yes | Dashboard ID to delete |
-
-## Decision Rules
-- Use `+list_dashboards` first to confirm the dashboard ID before deleting.
-- This is a destructive operation; keep the confirmation prompt unless automation is explicitly required.
-
-## Next Step on Failure
-- If the dashboard is not found, use `+list_dashboards` to verify the ID.
-
-## Recommended Chain
-- `+list_dashboards` -> `+delete_dashboard`

package/skills/ae-analysis/references/delete_metric.md

@@ -1,27 +0,0 @@
-# analysis_meta +delete_metric (Delete Metric)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metric Management**
-
-## Use Cases
-- Permanently delete a metric by its ID.
-
-## Commands
-```bash
-ae-cli analysis_meta +delete_metric --project_id <project_id> --metric_id <metric_id>
-ae-cli analysis_meta +delete_metric --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--metric_id` | Yes | Metric ID to delete |
-
-## Decision Rules
-- Use `+list_metrics` first to confirm the metric ID before deleting.
-- This is a destructive operation; keep the confirmation prompt unless automation is explicitly required.
-
-## Recommended Chain
-- `+list_metrics` -> `+delete_metric`

package/skills/ae-analysis/references/delete_report.md

@@ -1,27 +0,0 @@
-# analysis +delete_report (Delete Report)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Report Management**
-
-## Use Cases
-- Permanently delete a report by its ID.
-
-## Commands
-```bash
-ae-cli analysis +delete_report --project_id <project_id> --report_id <report_id>
-ae-cli analysis +delete_report --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--report_id` | Yes | Report ID to delete |
-
-## Decision Rules
-- Use `+list_reports` first to confirm the report ID before deleting.
-- This is a destructive operation; keep the confirmation prompt unless automation is explicitly required.
-
-## Recommended Chain
-- `+list_reports` -> `+delete_report`

package/skills/ae-analysis/references/delete_tag.md

@@ -1,27 +0,0 @@
-# analysis_audience +delete_tag (Delete Tag)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Tag Management**
-
-## Use Cases
-- Permanently delete a tag by its name.
-
-## Commands
-```bash
-ae-cli analysis_audience +delete_tag --project_id <project_id> --tag_name my_tag
-ae-cli analysis_audience +delete_tag --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--tag_name` | Yes | Tag name to delete |
-
-## Decision Rules
-- Use `+list_tags` first to confirm the tag name before deleting.
-- This is a destructive operation; keep the confirmation prompt unless automation is explicitly required.
-
-## Recommended Chain
-- `+list_tags` -> `+delete_tag`

package/skills/ae-analysis/references/drilldown_user_events.md

@@ -1,74 +0,0 @@
-# analysis +drilldown_user_events (Single-User Event Sequence Drilldown)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Model analysis**
-
-## Use Cases
-- Drill down to detailed event sequences for a specific user on specific dates.
-- This tool is typically used after drilldown_users.
-- Common parameters (focus on these): projectId, userId, eventNames, targetDates.
-- Advanced parameters (for special scenarios): zoneOffset, properties, timeGranularity, firstDayOfWeek, sortOrder, eventNameFilter, timeFilter, timeFilterBeforeNums, timeFilterAfterNums, entityId, entityValue, useCache, limit, offset.
-- The userId must come from drilldown_users and must not be guessed.
-- targetDates is a list of discrete dates, not a date range.
-- Constraint: drilldown positioning parameters must come from the previous query result and must not be guessed.
-- Constraint: time parameters are passed as an array of discrete time points, not a start/end interval.
-
-## Mandatory prerequisites (MUST)
-- Before constructing `--user_id` / `--event_names` / `--target_dates`, you must first read and follow these reference documents:
-  - [`./drilldown_users.md`](./drilldown_users.md)
-  - [`./list_events.md`](./list_events.md)
-  - [`./list_properties.md`](./list_properties.md) (only when passing `--properties`)
-- `user_id` must come from the `+drilldown_users` result; `event_names` / `target_dates` must come from the previous drilldown context or the actual result and must not be guessed.
-- Do not execute single-user event sequence drilldown until the upstream drilldown and result readback are complete.
-
-## Prerequisite call chain (required for executing single-user event drilldown)
-1. First execute `+drilldown_users` and obtain the target user and drilldown context.
-2. Confirm the `user_id`, candidate events, and target discrete time points from the previous step result.
-3. If additional property display is needed, first call `analysis_meta +list_properties --project_id <project_id>` to verify property names.
-4. Call `+drilldown_user_events` to query the event sequence.
-
-## Command
-```bash
-ae-cli analysis +drilldown_user_events --project_id <project_id> --user_id u_123 --event_names '["login"]' --target_dates '["2026-04-08 00:00:00"]'
-ae-cli analysis +drilldown_user_events --project_id <project_id> --user_id u_123 --event_names '["login"]' --target_dates '["2026-04-08 00:00:00"]' --zone_offset 8 --use_cache true --limit 20 --offset 0 --request_id mcp_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
-ae-cli analysis +drilldown_user_events --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--user_id` | Yes | User ID from drilldown_users. It must come from drilldown_users and must not be guessed. |
-| `--event_names` | Yes | JSON array of event names. Values should come from upstream drilldown context or `analysis_meta +list_events` in the same `project_id`. |
-| `--target_dates` | Yes | JSON array of discrete target dates from upstream drilldown context. Not a start/end range. |
-| `--zone_offset` | No | Time zone offset. For example, UTC+8 is 8 |
-| `--properties` | No | Optional event properties JSON array |
-| `--time_granularity` | No | Time granularity: T0/T1/T2/T3/T4/T5/T6/T7 |
-| `--first_day_of_week` | No | First day of week: 1-7 |
-| `--sort_order` | No | Sort order: asc or desc |
-| `--event_name_filter` | No | Optional event name filter |
-| `--time_filter` | No | Optional time filter condition |
-| `--time_filter_before_nums` | No | Number of records before the time filter point |
-| `--time_filter_after_nums` | No | Number of records after the time filter point |
-| `--entity_id` | No | Optional entity ID for multi-entity scenarios |
-| `--entity_value` | No | Optional entity value for multi-entity scenarios |
-| `--use_cache` | No | Whether to use cache. Default: true |
-| `--limit` | No | Maximum rows. Default: 1000, maximum: 10000 |
-| `--offset` | No | Row offset. Default: 0 |
-| `--request_id` | Yes | Required unique request ID used for tracking and cancellation. Generate it before starting the query. It must use `mcp_<32 lowercase hex UUID>`, for example `mcp_0123456789abcdef0123456789abcdef`. Provide this before starting the query so it can be cancelled later with `+cancel_query --request_id <same value>`, even if the caller stops waiting before the tool returns. If `fetch failed`, HTTP timeout, or caller timeout happens, the backend query may still be running. `requestId` is not auto-generated for MCP query tools because the caller must know it before the response for proactive cleanup. If omitted or blank, the backend returns `REQUEST_ID_REQUIRED`; invalid format returns `INVALID_REQUEST_ID`. The response `metadata.requestId` echoes the supplied requestId and can also be passed to `cancel_query(requestId)` when the query is no longer needed. |
-| `--timeout_minutes` | No | Query timeout in minutes |
-
-## Decision Rules
-- `user_id` / `event_names` / `target_dates` must come from the previous step result and must not be constructed out of thin air.
-- On the first run, include all required parameters (`--project_id`,`--user_id`,`--event_names`,`--target_dates`,`--request_id`), and add optional parameters after confirming the path works.
-- Wrap JSON parameters in single quotes (for example `--event_names '[]'`, `--target_dates '[]'`) to avoid shell escaping issues.
-- Generate and pass `--request_id` before starting any cancelable query; it is required. If `fetch failed`, HTTP timeout, or caller timeout happens, the backend query may still be running; call `+cancel_query --request_id <same value>` with the preset ID. The value must use `mcp_<32 lowercase hex UUID>`, for example `mcp_0123456789abcdef0123456789abcdef`. Omitted or blank IDs return `REQUEST_ID_REQUIRED`; invalid format returns `INVALID_REQUEST_ID`.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-
-## Next Steps on Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id`, `--user_id`, `--event_names`, `--target_dates`, `--request_id`).
-- If `Invalid JSON` appears, first verify the array structure, then compare it with the previous drilldown result to confirm the values are complete and valid.
-
-## Recommended chaining
-- +drilldown_users -> +drilldown_user_events

package/skills/ae-analysis/references/drilldown_users.md

@@ -1,80 +0,0 @@
-# analysis +drilldown_users (drill down analysis results to users)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Model Analysis**
-
-## Use Cases
-- Prerequisite helper: first call `+get_analysis_query_schema` to get the structure, then call this tool.
-- Drill down to the user list for a specific data point in an existing analysis result.
-- Use this tool only after query_adhoc, query_report_data, or query_dashboard_report_data.
-- The qp must stay the same as the previous analysis.
-- Drilldown parameters such as drilldownDate, drilldownGroups, retentionDays, and funnelStep must come from actual analysis results and must not be guessed.
-- Prerequisite: it is recommended to first run query_adhoc, query_report_data, or query_dashboard_report_data, then call this tool.
-- Constraint: drilldown positioning parameters must come from the previous query result and must not be guessed.
-
-## Mandatory Prerequisites (MUST)
-- Before building `--qp` and the drilldown positioning parameters, you must first read and follow the following reference docs:
-  - [`./query_adhoc.md`](./query_adhoc.md)
-  - [`./query_report_data.md`](./query_report_data.md)
-  - [`./query_dashboard_report_data.md`](./query_dashboard_report_data.md)
-- `qp`, `drilldown_date`, `drilldown_groups`, `event_index`, `retention_days`, `funnel_step`, and other parameters must come from real analysis results and must not be guessed.
-- Do not execute user drilldown until the upstream query and result reread have been completed.
-
-## Prerequisite Call Chain (required for drilldown)
-1. Run the upstream analysis first (`+query_adhoc` / `+query_report_data` / `+query_dashboard_report_data`) and save the result.
-2. Extract `qp` and the drilldown positioning parameters from the upstream result.
-3. Verify that `--model_type` matches the upstream analysis model.
-4. Call `+drilldown_users` to execute the user drilldown.
-
-## Commands
-```bash
-ae-cli analysis +drilldown_users --project_id <project_id> --model_type event --qp '{}'
-ae-cli analysis +drilldown_users --project_id <project_id> --model_type retention --qp '{}' --drilldown_date 2026-04-08 --drilldown_groups '[]' --event_index 8 --is_lost true --retention_days 8 --is_churned_user true --funnel_step 8 --interval demo --distribution_bucket 8 --compare_index 8 --include_total true --relation_val demo --limit 10 --offset 0 --request_id mcp_cccccccccccccccccccccccccccccccc
-ae-cli analysis +drilldown_users --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--model_type` | Yes | Model type used in the source analysis. Supported values: event, retention, funnel, distribution, attribution, heat_map, interval, path, rank_list, prop_analysis, sql. |
-| `--qp` | Yes | Query parameter JSON used for drilldown. MUST be copied from the source analysis request/result and keep consistent with upstream context. |
-| `--properties` | No | Optional user properties JSON array |
-| `--zone_offset` | No | Time zone offset. For example, UTC+8 is 8 |
-| `--drilldown_date` | No | Target drilldown date from the analysis result. Required for event and retention models. Format: yyyy-MM-dd |
-| `--drilldown_groups` | No | Drilldown group values from the analysis result as a JSON array, for example ["ios"]. Defaults to the overall group when omitted. |
-| `--event_index` | No | Event index for event-model drilldown. Use the event position from the analysis result starting from 0. |
-| `--is_lost` | No | For retention analysis, true queries lost users and false queries retained users. Default: false |
-| `--retention_days` | No | Retention interval in days from the analysis result, for example 7 for day-7 retention. If model_type is 'retention', the retention_days must not be null. |
-| `--is_churned_user` | No | For funnel analysis, true queries churned users for the step and false queries converted users. Default: false |
-| `--funnel_step` | No | Funnel step number from the analysis result starting from 1. If model_type is 'funnel', the funnel_step must not be null. |
-| `--interval` | No | Interval used for interval analysis |
-| `--distribution_bucket` | No | Distribution bucket index from the analysis result |
-| `--compare_index` | No | Comparison index used in comparison analysis scenarios |
-| `--include_total` | No | Whether to query users from the total row. Default: false |
-| `--relation_val` | No | Relation value used in relation analysis scenarios |
-| `--use_cache` | No | Whether to use cache. Default: true |
-| `--limit` | No | Optional limit. Default: 1000, maximum: 10000. |
-| `--offset` | No | Optional offset. Default: 0. |
-| `--request_id` | Yes | Required unique request ID used for tracking and cancellation. Generate it before starting the query. It must use `mcp_<32 lowercase hex UUID>`, for example `mcp_0123456789abcdef0123456789abcdef`. Provide this before starting the query so it can be cancelled later with `+cancel_query --request_id <same value>`, even if the caller stops waiting before the tool returns. If `fetch failed`, HTTP timeout, or caller timeout happens, the backend query may still be running. `requestId` is not auto-generated for MCP query tools because the caller must know it before the response for proactive cleanup. If omitted or blank, the backend returns `REQUEST_ID_REQUIRED`; invalid format returns `INVALID_REQUEST_ID`. The response `metadata.requestId` echoes the supplied requestId and can also be passed to `cancel_query(requestId)` when the query is no longer needed. |
-| `--timeout_minutes` | No | Query timeout in minutes. If the query exceeds this time, it will be cancelled automatically. |
-
-## Decision Rules
-- Drilldown positioning parameters must come from upstream analysis results and must not be fabricated.
-- `qp` must not be rewritten or "simplified"; it should remain consistent with the source analysis.
-- For pagination, use `--limit` and `--offset` together. Default limit is 1000, maximum 100000.
-- Generate and pass `--request_id` before starting any cancelable query; it is required. If `fetch failed`, HTTP timeout, or caller timeout happens, the backend query may still be running; call `+cancel_query --request_id <same value>` with the preset ID. The value must use `mcp_<32 lowercase hex UUID>`, for example `mcp_0123456789abcdef0123456789abcdef`. Omitted or blank IDs return `REQUEST_ID_REQUIRED`; invalid format returns `INVALID_REQUEST_ID`.
-- For the first run, include all required parameters (`--project_id`, `--model_type`, `--qp`, `--request_id`) and add optional parameters after confirming the chain works.
-- Wrap JSON parameters in single quotes (for example `--qp '{}'`, `--drilldown_groups '{}'`) to avoid shell escaping issues.
-- When dates/time ranges are involved, validate with a short range first and then expand gradually.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-
-## Next Step After Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill them in (focus on `--project_id`, `--model_type`, `--qp`).
-- If `Invalid JSON` appears, first check the raw `qp` from the upstream query request, then verify that all necessary drilldown parameters are present.
-
-## Recommended Chaining
-- +query_adhoc -> +drilldown_users
-- +query_report_data -> +drilldown_users
-- +query_dashboard_report_data -> +drilldown_users

package/skills/ae-analysis/references/freeze_dashboards.md

@@ -1,29 +0,0 @@
-# analysis +freeze_dashboards (Freeze / Unfreeze Dashboards)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Dashboard Management**
-
-## Use Cases
-- Freeze one or more dashboards to take their scheduled refresh jobs offline.
-- Unfreeze dashboards to bring scheduled jobs back online (for dashboards that have a schedule configured).
-
-## Commands
-```bash
-ae-cli analysis_audience +freeze_dashboards --project_id <project_id> --dashboard_ids '[123, 456]' --freeze true
-ae-cli analysis_audience +freeze_dashboards --project_id <project_id> --dashboard_ids '[123]' --freeze false
-ae-cli analysis_audience +freeze_dashboards --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--dashboard_ids` | Yes | JSON array of dashboard IDs to freeze or unfreeze |
-| `--freeze` | Yes | true to freeze, false to unfreeze |
-
-## Decision Rules
-- Use `+list_dashboards` to confirm dashboard IDs before freezing.
-
-## Recommended Chain
-- `+list_dashboards` -> `+freeze_dashboards`

package/skills/ae-analysis/references/get_analysis_query_schema.md

@@ -1,71 +0,0 @@
-# analysis +get_analysis_query_schema (Get Analysis Query Schema)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Model schema queries**
-
-> **CRITICAL - Builder-supported ad hoc models**
->
-> Do **not** use this tool for natural-language non-SQL ad hoc requests.
-> All ten non-SQL models have matching QP builders; use the builder first, then `+query_adhoc`.
->
-> If a builder returns `need_clarification`, `invalid_argument`, `unsupported_feature`, or `validation_error`, stop and ask the user or report the structured error. Do not fall back to this schema tool.
-
-> **CRITICAL - Step-by-Step Execution (BLOCKING)**
->
-> This blocking sequence applies only to the SQL manual path.
-> **You MUST execute these steps in order. Do NOT skip any step.**
->
-> | Step | Command | When to proceed |
-> |------|---------|-----------------|
-> | **Step 1 (MANUAL PATH ONLY)** | `--model_type sql` **without `--segments`** | Execute first only for SQL. Review result. |
-> | **Step 2 (OPTIONAL)** | Add `--segments 'filter_group'` | Only if Step 1 result lacks filter/groupBy structures AND you need them |
-> | **Step 3 (OPTIONAL)** | Add `--segments 'examples'` | Only if Step 1+2 insufficient for multi-metric, time comparison, formulas |
->
-> **WRONG:** `ae-cli analysis +get_analysis_query_schema --model_type sql --segments 'examples'` ← **Never start here!**
-> **RIGHT:** `ae-cli analysis +get_analysis_query_schema --model_type sql` → review → add segments if needed
-
-## Pre-call Checklist (Execute in Order)
-
-0. ✓ **Builder-supported model?** → If non-SQL, stop using this tool and use the matching builder.
-1. ✓ **Step 1 completed?** → Review core schema
-2. ✓ **Gap identified?** → Justify need (e.g., "need filter_group structure")
-3. ✓ **Justified?** → Call again with specific segment
-
-**Rule**: For SQL, uncertain → execute Step 1 first. For non-SQL models, uncertain → read the matching builder reference first.
-
-## Command (Execute in Order)
-
-```bash
-# Step 1: start here only for SQL (no segments)
-ae-cli analysis +get_analysis_query_schema --model_type sql
-
-# Step 2: Only after Step 1, if filter/groupBy needed
-ae-cli analysis +get_analysis_query_schema --model_type sql --segments 'filter_group' --include_core false
-
-# Step 3: Only after Step 1/2, for complex scenarios
-ae-cli analysis +get_analysis_query_schema --model_type sql --segments 'examples' --include_core false
-
-# Follow-up request (already have core from earlier step in same session)
-ae-cli analysis +get_analysis_query_schema --model_type sql --segments 'examples' --include_core false
-```
-
-## Parameters
-
-| Parameter | Required | Description |
-|---|---|---|
-| `--model_type` | Yes | Model type: event, retention, funnel, distribution, sql, interval, path, attribution, prop_analysis, rank_list, heat_map |
-| `--segments` | No | `core` (default), `filter_group`, `calctype`, `aggregatetype`, `examples`, `full`. Empty → core only. |
-| `--include_core` | No | Default: true. Set false for follow-up requests when core already retrieved. |
-
-## 场景分级
-
-| 场景 | 参数 | 执行顺序 |
-|---|---|---|
-| Builder 支持模型 | 不适用 | 所有非 SQL 模型禁止用此工具作为 QP 准备步骤，改用 builder |
-| 简单 | 不传 `--segments` | **Step 1** - SQL manual path |
-| 中等 | `--segments 'filter_group'` | **Step 2** - SQL manual path，有过滤或分组，需先完成 Step 1 |
-| 复杂 | `--segments 'examples'` | **Step 3** - SQL manual path，需先完成 Step 1 |
-
-## Next Steps on Failure
-- Verify model type and segment compatibility (e.g., aggregatetype not for funnel/path/interval/sql)

package/skills/ae-analysis/references/get_bi_panel_detail.md

@@ -1,35 +0,0 @@
-# analysis +get_bi_panel_detail (read BI panel structure)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **BI panel management**
-
-## Use Cases
-- Read a BI panel's released structure without querying data.
-- Inspect pages, queryable charts, summary page metadata, dashboard-level parameter controls, dashboard-level permission controls, and page chart filter controls.
-- Get `pageKey`, `chartId`, `defaultColumns`, and control schemas needed by `+query_bi_panel_data`.
-
-## Command
-```bash
-ae-cli analysis +get_bi_panel_detail --project_id <project_id> --panel_id <panel_id>
-ae-cli analysis +get_bi_panel_detail --project_id <project_id> --panel_id <panel_id> --fields '["basic","pages","charts","parameterControls","permissionControls","chartFilterControls","summary"]'
-ae-cli analysis +get_bi_panel_detail --project_id <project_id> --panel_id <panel_id> --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--panel_id` | Yes | BI panel ID returned by `+list_bi_panels` |
-| `--fields` / `-f` | No | Optional detail sections. Supported values: `basic`, `pages`, `charts`, `parameterControls`, `permissionControls`, `chartFilterControls`, `summary`. |
-
-## Decision Rules
-- This command reads the released BI panel version only. It does not expose version selection.
-- Use `charts` and the three control sections when preparing `+query_bi_panel_data`.
-- `parameterControls` are dashboard-level parameter controls and keep single-value semantics.
-- `permissionControls` are dashboard-level permission control values. Their `allowedValues` are hints, not an MCP-side whitelist.
-- `chartFilterControls` are page-level filter controls and apply only to their `boundChartIds`. Some filters are stored as `pageCharts` components and are returned as non-queryable filter controls.
-- Do not infer internal fields such as `paramList`, `permissionFilters`, `visualCfg`, `whereList`, `field`, `columnName`, `userId`, or `openId`.
-
-## Recommended Chaining
-- `+list_bi_panels` -> `+get_bi_panel_detail` -> `+query_bi_panel_data`

package/skills/ae-analysis/references/get_cluster_definition_schema.md

@@ -1,53 +0,0 @@
-# analysis_audience +get_cluster_definition_schema (Get Cluster Definition Schema)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Schema Query**
-
-## Use Cases
-- Support tool positioning: the current command provides the structure definition (schema) and should be used as a prerequisite step.
-- Recommended sequence: first call this schema tool to get the structure, then verify metadata in the same session and `project_id` (first build/update calls `analysis_meta +list_events` / `analysis_meta +list_properties`; later calls should reuse session-verified results first), and finally create or update clusters.
-- Get the cluster definition schema. Supports cluster type + response mode + condition subtype.
-
-## Commands
-```bash
-ae-cli analysis_audience +get_cluster_definition_schema --cluster_type condition
-ae-cli analysis_audience +get_cluster_definition_schema --cluster_type sql
-ae-cli analysis_audience +get_cluster_definition_schema --cluster_type condition --response_mode base
-ae-cli analysis_audience +get_cluster_definition_schema --cluster_type condition --response_mode examples --condition_subtype behavior_seq
-ae-cli analysis_audience +get_cluster_definition_schema --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--cluster_type` | Yes | Cluster type. Supported values: condition and sql |
-| `--response_mode` | No | Schema response mode. Supported values: `base`, `examples`, `full`. Default: `base`. |
-| `--condition_subtype` | No | Only effective when `--cluster_type condition`. Supported values: `core`, `behavior_seq`, `all`. Default: `core`. |
-
-## Progressive Loading Strategy
-- Use the smallest response that can solve the current task. Large schemas consume context and can make the follow-up definition construction less reliable.
-- Start with `--response_mode base` or omit `--response_mode` for simple condition clusters and SQL clusters.
-- Request `--response_mode examples` only when the base schema is not enough to build or validate the target `definition`.
-- Request `--response_mode full` only for complex, ambiguous, or repeatedly failing definition construction. Do not use `full` by default.
-- For normal condition clusters, use the default `--condition_subtype core`.
-- Use `--condition_subtype behavior_seq` only when the user specifically needs behavior sequence conditions.
-- Use `--condition_subtype all` only when comparing condition subtypes or when the exact subtype cannot be determined after reading the user request. Avoid `all` for simple creation/update tasks.
-- For clear SQL cluster requests, call `--cluster_type sql` with base mode first.
-
-## Decision Rules
-- `--cluster_type` must be explicitly set to `condition` or `sql`.
-- Prefer `--response_mode base` first; request `examples` only when needed; request `full` only as a last resort.
-- `--condition_subtype` should only be passed for `condition` schemas.
-- It is recommended to run `--dry-run` first to inspect the request mapping before making the actual call.
-- The current command returns only structure constraints; it does not guarantee that the field values are available in the target project. Event names and property names must be confirmed again with `analysis_meta` metadata interfaces.
-- Before calling `analysis_meta +list_events` / `analysis_meta +list_properties`, first read their reference docs to confirm the parameter and return-field meanings. Query metadata on the first build/update in this session for the same `project_id`; after that, prefer reusing session-verified metadata.
-
-## Next Step on Failure
-- If reading fails, first verify whether the object ID exists and belongs to the current project.
-- If the schema does not match expectations, confirm whether the correct schema interface was used (filter/groupby/query/tag/cluster).
-
-## Recommended Chain
-- First read: [`./get_cluster_definition_schema.md`](./get_cluster_definition_schema.md) -> [`./list_events.md`](./list_events.md) -> [`./list_properties.md`](./list_properties.md)
-- +get_cluster_definition_schema -> (first build/update in session or refresh) analysis_meta +list_events -> analysis_meta +list_properties -> +create_cluster
-- +get_cluster_definition_schema -> (first build/update in session or refresh) analysis_meta +list_events -> analysis_meta +list_properties -> +update_cluster