@thinkingai/ae-cli 6.0.30 → 6.0.32

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

@@ -1,69 +0,0 @@
-# analysis_audience +create_cluster (Create Cluster)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Cluster Management**
-
-## Use Cases
-- Prerequisite helper: first call `+get_cluster_definition_schema` to obtain the `definition` structure, then call this tool.
-- When building a real `definition`, metadata must be verified in the same session and `project_id`: first build in this session must call `analysis_meta +list_events` and `analysis_meta +list_properties`; later calls should reuse the session-verified results first.
-- Create a user cluster definition. Supports the condition and sql cluster types. Returns cluster information without cluster members.
-
-## Required Prerequisites (MUST)
-- Before constructing `--definition`, you must first read and follow these reference docs:
-  - [`./get_cluster_definition_schema.md`](./get_cluster_definition_schema.md)
-  - [`./list_events.md`](./list_events.md)
-  - [`./list_properties.md`](./list_properties.md)
-- Do not generate the final `definition` until the above docs have been read and metadata has been verified: first build in this session for the same `project_id` must run metadata commands; if session-verified metadata already exists, reuse it first.
-
-## Prerequisite Call Chain (Required for Building Definition)
-1. Read `get_cluster_definition_schema.md` to understand the input and output structure of `+get_cluster_definition_schema`.
-2. Obtain the schema progressively (by cluster type). Start with base mode:
-   `ae-cli analysis_audience +get_cluster_definition_schema --cluster_type condition`
-   Request `--response_mode examples` only if base is insufficient; request `--response_mode full` only for complex, ambiguous, or repeatedly failing definition construction.
-3. Read `list_events.md` to understand the parameters and return structure of `+list_events`.
-4. Get the event list (for `event_name` and other fields): if this is the first definition build in the current session for this `project_id` (or metadata is not yet verified), call
-   `ae-cli analysis_meta +list_events --project_id <project_id>`;
-   otherwise, reuse the session-verified event metadata first.
-5. Read `list_properties.md` to understand the parameters and return structure of `+list_properties`.
-6. Get the property list (for property filters, grouping, and comparison fields): if this is the first definition build in the current session for this `project_id` (or metadata is not yet verified), call
-   `ae-cli analysis_meta +list_properties --project_id <project_id>`;
-   otherwise, reuse the session-verified property metadata first.
-7. Build `definition` based on the schema + metadata, then call `+create_cluster`.
-
-## Commands
-```bash
-ae-cli analysis_audience +create_cluster --project_id <project_id> --cluster_name demo --display_name demo --definition '{}'
-ae-cli analysis_audience +create_cluster --project_id <project_id> --cluster_name demo --display_name demo --type condition --definition '{}' --zone_offset 8 --entity_id 1001
-ae-cli analysis_audience +create_cluster --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--cluster_name` | Yes | Cluster name. Must start with a letter and contain only letters, digits, and underscores. Length: 1-80 |
-| `--display_name` | Yes | Cluster display name. Length: 1-80 |
-| `--type` | No | Cluster type. Supported values: condition and sql. Default: condition |
-| `--definition` | Yes | Cluster definition JSON. MUST call `+get_cluster_definition_schema` first to learn the exact structure, then fill valid event/property names from metadata verified in the same `project_id` (first build queries `analysis_meta` metadata commands; later builds in the same session should reuse verified results first). |
-| `--zone_offset` | No | Optional time zone offset for cluster computation. Valid range: -12 to 14 (supports decimals like 5.5). If the user does not specify a timezone, omit this parameter. When a timezone is specified, call get_project_config first to check whether the project supports time zones (timeZoneEnabled) and available values (availableTimeZones). |
-| `--entity_id` | No | Optional entity ID for cluster definition. Use list_entities to query available entities. |
-
-## Decision Rules
-- `definition` cannot be written from experience alone: it must satisfy both the schema structure and the project's real metadata (events and properties).
-- Determine `--type` first, then fetch the schema for the corresponding `--cluster_type`; do not mix condition/sql structures.
-- Use progressive schema loading: base first, examples only when needed, full only as a last resort. Do not request full schema for simple cluster creation when the intent is clear.
-- Before calling `list_events` / `list_properties`, you must first read their reference docs to avoid misuse of parameters or misreading return fields. Query metadata on the first build in this session for the same `project_id`; after that, prefer reusing session-verified metadata.
-- For the first execution, it is recommended to pass only the required parameters (`--project_id`, `--cluster_name`, `--display_name`, `--definition`) and add optional parameters after confirming the path works.
-- Wrap JSON parameters in single quotes (e.g. `--definition '{}'`) to avoid shell escaping issues.
-- When troubleshooting across projects, first confirm whether `--project_id` matches the current permissions and target environment.
-- Write operations keep confirmation prompts by default; for automation scenarios, reevaluate whether to use `--yes`.
-
-## Next Step on Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill the gap (focus on `--project_id`, `--cluster_name`, `--display_name`, `--definition`).
-- If `Invalid JSON` appears, first check whether a schema-required field is missing, then verify whether event/property names come from the same `project_id`'s `list_events/list_properties` results.
-- If the result after writing is not as expected, immediately re-read the corresponding list/get interfaces and compare before and after.
-
-## Recommended Chain
-- +get_cluster_definition_schema -> (first build or refresh) analysis_meta +list_events -> analysis_meta +list_properties -> +create_cluster
-- +list_clusters -> +get_clusters_by_name -> +update_cluster

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

@@ -1,49 +0,0 @@
-# analysis +create_dashboard (create dashboard)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Dashboard Management**
-
-## Use Cases
-- Create a new dashboard.
-- Can automatically associate an initial report after creation.
-- Can optionally create an initial dashboard note at the same time.
-- Returns basic dashboard information (such as ID and name), not the full dashboard configuration.
-
-## Commands
-```bash
-ae-cli analysis +create_dashboard --project_id <project_id> --dashboard_name demo
-ae-cli analysis +create_dashboard --project_id <project_id> --dashboard_name demo --space_id 1 --folder_id 1 --initial_report_id 1 --note_title demo --note_content demo --note_style '{}'
-ae-cli analysis +create_dashboard --project_id <project_id> --dashboard_name demo --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--dashboard_name` | Yes | Dashboard name |
-| `--space_id` | No | Optional space ID. If provided, the dashboard is created in that space. |
-| `--folder_id` | No | Optional folder ID. If provided, the dashboard is created in that folder. |
-| `--initial_report_id` | No | Optional initial report ID. If provided, the report is automatically associated with the new dashboard after creation. |
-| `--note_title` | No | Optional note title for an initial dashboard note. |
-| `--note_content` | No | Optional note content for an initial dashboard note. |
-| `--note_style` | No | Optional note style configuration JSON for an initial dashboard note. |
-
-## Decision Rules
-- For the first run, it is recommended to pass only the required parameters (`--project_id`, `--dashboard_name`) and add optional parameters after confirming the chain works.
-- Wrap JSON parameters in single quotes (for example `--note_style '{}'`) to avoid shell escaping issues.
-- Only pass `--space_id` and `--folder_id` when you clearly know the target location; if unsure, create it in the default location first.
-- Dashboard note-related parameters are best passed as a group to avoid incomplete results caused by specifying only the title or only the content.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-- Write operations keep the confirmation prompt by default; evaluate whether to use `--yes` only for automation scenarios.
-
-## Next Step After Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill them in (focus on `--project_id`, `--dashboard_name`).
-- If `Invalid JSON` appears, first validate with the smallest JSON structure (for example `{}`), then add fields gradually.
-- If the result after writing is not as expected, immediately reread the corresponding list/get interface and compare before and after.
-
-## Recommended Chaining
-- +create_dashboard -> +list_dashboards
-- +create_dashboard -> +query_dashboard_detail
-- +create_dashboard -> +update_dashboard
-- +create_dashboard -> +query_adhoc -> +create_report -> +update_dashboard

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

@@ -1,40 +0,0 @@
-# analysis_audience +create_id_cluster (Create ID Cluster)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Cluster Management**
-
-## Use Cases
-- Create a new ID cluster by uploading a CSV of user IDs as plain text.
-- The CSV should contain a single column of user IDs (no header row required).
-- The operation is asynchronous — the cluster enters computing state after creation.
-
-## Commands
-```bash
-ae-cli analysis_audience +create_id_cluster --project_id <project_id> --display_name "My ID Cluster" --file_content "user_001
-user_002
-user_003" --entity_id <entity_id>
-ae-cli analysis_audience +create_id_cluster --project_id <project_id> --display_name "My ID Cluster" --file_content "user_001" --entity_id <entity_id> --cluster_name my_id_cluster --remarks "Created by script"
-ae-cli analysis_audience +create_id_cluster --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--display_name` | Yes | Cluster display name (1-80 characters) |
-| `--file_content` | Yes | CSV file content as plain text. No header row, UTF-8 encoding. Each row contains one user ID. Max 100MB. |
-| `--entity_id` | Yes | Entity ID to associate the cluster with. Use `analysis_meta +list_entities` to query. |
-| `--cluster_name` | No | Cluster name (lowercase letters, digits, underscores, starts with a letter, max 80 chars). Auto-generated if omitted. |
-| `--remarks` | No | Optional remarks (max 200 characters) |
-| `--main_column_name` | No | Optional main column name for ID matching |
-
-## Return Value
-Returns `clusterId`, `uploadNum` (rows uploaded), `userNum` (matched users), `unmatchedNum` (unmatched rows), and `clusterName`.
-
-## Decision Rules
-- Call `analysis_meta +list_entities` to resolve `entity_id` before creating.
-- If file size exceeds 100MB, inform the user to upload directly via the web interface.
-
-## Recommended Chain
-- `analysis_meta +list_entities` -> `+create_id_cluster` -> `+refresh_cluster`

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

@@ -1,39 +0,0 @@
-# analysis_audience +create_id_tag (Create ID Tag)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Tag Management**
-
-## Use Cases
-- Create a new ID tag by uploading a CSV of user IDs and tag values as plain text.
-- The CSV should contain two columns: user ID and tag value (tag value is optional).
-- The operation is asynchronous — the tag enters computing state after creation.
-
-## Commands
-```bash
-ae-cli analysis_audience +create_id_tag --project_id <project_id> --display_name "VIP Tag" --file_content "user_001,gold
-user_002,silver" --entity_id <entity_id>
-ae-cli analysis_audience +create_id_tag --project_id <project_id> --display_name "VIP Tag" --file_content "user_001,gold" --entity_id <entity_id> --tag_name vip_tag --remarks "ID-based tag"
-ae-cli analysis_audience +create_id_tag --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--display_name` | Yes | Tag display name (1-80 characters) |
-| `--file_content` | Yes | CSV file content as plain text. No header row, UTF-8 encoding. Column 1: user ID. Column 2: tag value (optional). Example: user_001,gold_member. Max 100MB. |
-| `--entity_id` | Yes | Entity ID to associate the tag with. Use `analysis_meta +list_entities` to query. |
-| `--tag_name` | No | Tag name (letters/digits/underscores, starts with a letter, max 80 chars). Auto-generated if omitted. |
-| `--remarks` | No | Optional remarks (max 200 characters) |
-| `--main_column_name` | No | Optional main column name for ID matching |
-
-## Return Value
-Returns `clusterId`, `uploadNum` (rows uploaded), `userNum` (matched users), `unmatchedNum` (unmatched rows), and `clusterName` (tag name).
-
-## Decision Rules
-- Call `analysis_meta +list_entities` to resolve `entity_id` before creating.
-- If file size exceeds 100MB, inform the user to upload directly via the web interface.
-
-## Recommended Chain
-- `analysis_meta +list_entities` -> `+create_id_tag` -> `+refresh_tag`

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

@@ -1,62 +0,0 @@
-# analysis_meta +create_metric (Create Metric)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../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 `analysis_meta +list_events` and `analysis_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:
-  - [`./get_analysis_query_schema.md`](./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 `ae-cli analysis +get_analysis_query_schema --model_type <event|retention>` to get the structure.
-3. Read `list_events.md`, then call `ae-cli analysis_meta +list_events --project_id <project_id>` to get available events.
-4. Read `list_properties.md`, then call `ae-cli analysis_meta +list_properties --project_id <project_id>` 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 skill constraints (call `analysis_common +get_resource_url`).
-
-## Commands
-```bash
-ae-cli analysis_meta +create_metric --project_id <project_id> --name demo --display_name demo --model_type event --events '[]' --params '{}'
-ae-cli analysis_meta +create_metric --project_id <project_id> --name demo --display_name demo --remark demo --model_type event --events '[]' --params '{}'
-ae-cli analysis_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 `analysis_meta +list_events` / `analysis_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 `analysis_meta +list_events` / `analysis_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 -> analysis_meta +list_events -> analysis_meta +list_properties -> +create_metric
-- +list_metrics -> +create_metric -> +get_metric

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

@@ -1,39 +0,0 @@
-# analysis +create_or_update_dashboard_note (Maintain Dashboard Note)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Dashboard management**
-
-## Use Cases
-- Create a new dashboard note or update an existing one. If noteId is provided, updates the existing note; otherwise creates a new note. Returns the created or updated note information.
-- Create a new dashboard note or update an existing one.
-
-## Command
-```bash
-ae-cli analysis +create_or_update_dashboard_note --project_id <project_id> --dashboard_id 1 --note_title demo
-ae-cli analysis +create_or_update_dashboard_note --project_id <project_id> --dashboard_id 1 --note_id 1 --note_title demo --description demo --ui_config '{}'
-ae-cli analysis +create_or_update_dashboard_note --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--dashboard_id` / `-d` | Yes | Dashboard ID |
-| `--note_id` | No | Optional note ID. If provided, updates the existing note; otherwise creates a new note. |
-| `--note_title` | Yes | Note title |
-| `--description` | No | Optional note description content. |
-| `--ui_config` | No | Optional UI configuration JSON string for the note style. |
-
-## Decision Rules
-- On the first run, start with only the required parameters (`--project_id`, `--dashboard_id`, `--note_title`) and add optional parameters after confirming the path works.
-- Wrap JSON parameters in single quotes (for example `--ui_config '{}'`) 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; evaluate whether to use `--yes` for automated scenarios.
-
-## 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`, `--dashboard_id`, `--note_title`).
-- If `Invalid JSON` appears, first verify with the smallest JSON structure (for example `{}` or `[]`), then add fields incrementally.
-- If the result after writing does not match expectations, immediately read back the corresponding list/get interface to compare before and after.
-
-## Recommended chaining

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

@@ -1,43 +0,0 @@
-# analysis +create_public_access_link (create public access link)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Dashboard Management**
-
-## Use Cases
-- Create a public access link for the project.
-- Creates a public link that allows unauthenticated users to access a specified dashboard or BI panel.
-- Returns the created link ID and short-link identifier.
-
-## Commands
-```bash
-ae-cli analysis +create_public_access_link --project_id <project_id> --resource_type dashboard --resource_id 1 --access_controls '{}' --effective_at "2026-04-09 10:00:00" --expires_at "2026-04-10 10:00:00"
-ae-cli analysis +create_public_access_link --project_id <project_id> --company_id 1 --resource_type dashboard --resource_id 1 --access_controls '{}' --remark demo --effective_at "2026-04-09 10:00:00" --expires_at "2026-04-10 10:00:00"
-ae-cli analysis +create_public_access_link --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--company_id` | No | Optional company ID. If omitted, the company ID of the project is used. |
-| `--resource_type` | Yes | Access target type. Supported values: dashboard (dashboard) and bi_panel (BI panel). |
-| `--resource_id` | Yes | Access target ID. Use a dashboard ID when resourceType is dashboard, and a BI panel ID when resourceType is bi_panel. |
-| `--access_controls` | Yes | Public access control JSON. Effective when resourceType is dashboard. DN controls whether the dashboard title is shown (1: shown, 2: hidden); GF controls whether filters are shown (1: shown and editable, 2: hidden, 3: shown but not editable); UA controls whether refresh is allowed (1: shown, 2: hidden). Pass JSON format. The default for dashboard is {"DN":"1","GF":"3","UA":"2"}; the default for bi_panel is {}. |
-| `--remark` | No | Optional remark. Maximum length: 200 characters. |
-| `--effective_at` | Yes | Effective time. Format: yyyy-MM-dd HH:mm:ss |
-| `--expires_at` | Yes | Expiration time. Format: yyyy-MM-dd HH:mm:ss |
-
-## Decision Rules
-- For the first run, it is recommended to pass only the required parameters (`--project_id`, `--resource_type`, `--resource_id`) and add optional parameters after confirming the chain works.
-- Wrap JSON parameters in single quotes (for example `--access_controls '{}'`) 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`, `--resource_type`, `--resource_id`).
-- If `Invalid JSON` appears, first validate with the smallest JSON structure (for example `{}` or `[]`), then add fields gradually.
-- If the result after writing is not as expected, immediately reread the corresponding list/get interface and compare before and after.
-
-## Recommended Chaining
-- +create_public_access_link -> +list_public_access_links

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

@@ -1,60 +0,0 @@
-# analysis +create_report (Create Report)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Report management**
-
-## Use Cases
-- Precondition helper: call `+get_analysis_query_schema` to get the structure before using this tool.
-- When constructing a real `analysis_query`, you must supplement it with real project metadata; first call `analysis_meta +list_events` and `analysis_meta +list_properties`.
-- Create and persist a new report definition. Returns the new report ID and name without querying data or modifying existing reports.
-
-## Mandatory prerequisites (MUST)
-- Before constructing `--analysis_query`, you must first read and follow these reference documents:
-  - [`./get_analysis_query_schema.md`](./get_analysis_query_schema.md)
-  - [`./list_events.md`](./list_events.md)
-  - [`./list_properties.md`](./list_properties.md)
-- Do not generate the final `analysis_query` until the documentation review and prerequisite command calls are complete.
-
-## Prerequisite call chain (required for constructing analysis_query)
-1. First determine `--model_type`.
-2. Read `get_analysis_query_schema.md`, then call `ae-cli analysis +get_analysis_query_schema --model_type <model_type>` to get the structure.
-3. Read `list_events.md`, then call `ae-cli analysis_meta +list_events --project_id <project_id>`.
-4. Read `list_properties.md`, then call `ae-cli analysis_meta +list_properties --project_id <project_id>`.
-5. Build `analysis_query` from the schema + metadata, then call `+create_report`.
-
-## Command
-```bash
-ae-cli analysis +create_report --project_id <project_id> --report_name demo --model_type event --analysis_query '{}'
-ae-cli analysis +create_report --project_id <project_id> --report_name demo --model_type event --analysis_query '{}' --description demo --cache_seconds 8 --query_duration_ms 8 --dashboard_ids '[]'
-ae-cli analysis +create_report --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--report_name` | Yes | Report name. Length: 1-80 characters |
-| `--model_type` | Yes | Report model type. Supported values: event, retention, funnel, prop_analysis, path, distribution, sql, interval, attribution |
-| `--analysis_query` | Yes | Report analysis query JSON. MUST call `+get_analysis_query_schema` first, and use event/property metadata from `analysis_meta +list_events` / `analysis_meta +list_properties` in the same `project_id`. |
-| `--description` | No | Optional report description |
-| `--cache_seconds` | No | Optional cache duration in seconds |
-| `--query_duration_ms` | No | Optional query duration in milliseconds |
-| `--dashboard_ids` | No | Optional list of dashboard IDs to associate |
-
-## Decision Rules
-- `analysis_query` cannot be written from experience alone: it must satisfy both the schema structure and the project metadata constraints.
-- Before calling `list_events` / `list_properties`, you must first study the corresponding reference documents.
-- On the first run, start with only the required parameters (`--project_id`,`--report_name`,`--model_type`), and add optional parameters after confirming the path works.
-- Wrap JSON parameters in single quotes (for example `--analysis_query '{}'`, `--dashboard_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 the confirmation prompt by default; evaluate whether to use `--yes` for automated scenarios.
-
-## 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`, `--report_name`, `--model_type`).
-- If `Invalid JSON` appears, first check the schema required fields, then verify whether the event/property names come from metadata query results for the same `project_id`.
-- If the result after writing does not match expectations, immediately read back the corresponding list/get interface to compare before and after.
-
-## Recommended chaining
-- +get_analysis_query_schema -> analysis_meta +list_events -> analysis_meta +list_properties -> +create_report
-- +list_reports -> +get_report_definition -> +query_report_data

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

@@ -1,73 +0,0 @@
-# analysis +create_result_cluster (create result cluster)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Model Analysis**
-
-## Use Cases
-- Create a reusable result cluster from users matched by a drilldown condition in an existing analysis result.
-- Use this tool only after query_adhoc, query_report_data, or query_dashboard_report_data.
-- Keep the qp consistent with the source analysis.
-- Drilldown parameters such as drilldownDate, funnelStep, and retentionDays must come from real analysis results.
-- Prerequisite: it is recommended to first run query_adhoc, query_report_data, or query_dashboard_report_data, then call this tool.
-
-## Mandatory Prerequisites (MUST)
-- Before building `--qp` and the various drilldown 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 create a result cluster until the upstream query and result reread have been completed.
-
-## Prerequisite Call Chain (required for creating a result cluster)
-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 (date, group, step, interval, and so on) from the upstream result.
-3. Verify that `--model_type` matches the upstream analysis model.
-4. Call `+create_result_cluster` to create the cluster.
-
-## Commands
-```bash
-ae-cli analysis +create_result_cluster --project_id <project_id> --cluster_name demo --model_type event --qp '{}'
-ae-cli analysis +create_result_cluster --project_id <project_id> --cluster_name demo --display_name demo --model_type event --qp '{}' --zone_offset 8 --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
-ae-cli analysis +create_result_cluster --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--cluster_name` | Yes | Cluster name. Must start with a letter and contain only letters, digits, and underscores. It must be unique within the project. |
-| `--display_name` | No | Optional cluster display name. If omitted, clusterName is used. |
-| `--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. MUST be copied from the source analysis request/result and keep fully consistent with the upstream analysis context. |
-| `--zone_offset` | No | Optional time zone offset. If omitted, the project default time zone is used. |
-| `--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 saves lost users and false saves retained users. Default: false |
-| `--retention_days` | No | Retention interval in days from the analysis result, for example 7 for day-7 retention |
-| `--is_churned_user` | No | For funnel analysis, true saves churned users for the step and false saves converted users. Default: false |
-| `--funnel_step` | No | Funnel step number from the analysis result starting from 1 |
-| `--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 save users from the total row. Default: false |
-| `--relation_val` | No | Relation value used in relation analysis scenarios |
-
-## 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 the first run, it is recommended to pass only the required parameters (`--project_id`, `--cluster_name`, `--model_type`, `--qp`) and add optional parameters after confirming the chain works.
-- Wrap JSON parameters in single quotes (for example `--qp '{}'`) 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`, `--cluster_name`, `--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.
-- If the result after writing is not as expected, immediately reread the corresponding list/get interface and compare before and after.
-
-## Recommended Chaining
-- +query_adhoc -> +create_result_cluster
-- +query_report_data -> +create_result_cluster
-- +query_dashboard_report_data -> +create_result_cluster

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

@@ -1,34 +0,0 @@
-# analysis +create_space (Create Space)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Space Management**
-
-## Use Cases
-- Create a new space in a project to organize dashboards and assets under a named container.
-- Returns basic space information (ID, name, avatar settings).
-
-## Commands
-```bash
-ae-cli analysis +create_space --project_id <project_id> --space_name "My Space"
-ae-cli analysis +create_space --project_id <project_id> --space_name "Team Space" --space_desc "Team dashboards"
-ae-cli analysis +create_space --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--space_name` | Yes | Space name (1-64 characters) |
-| `--space_desc` | No | Optional space description (max 200 characters) |
-
-## Decision Rules
-- `--space_name` must be between 1 and 64 characters.
-- Write operations keep the confirmation prompt by default; use `--yes` only for automation.
-
-## Next Steps After Failure
-- If `SPACE_NAME_TOO_LONG` appears, shorten `--space_name` to 64 characters or fewer.
-- If the result after writing is not as expected, use `analysis +list_dashboards` to inspect the space context.
-
-## Recommended Chaining
-- `+create_space` → `+create_dashboard` (create dashboard inside the new space using `--space_id`)

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

@@ -1,61 +0,0 @@
-# analysis_audience +create_tag (Create Tag)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Tag Management**
-
-## Use Cases
-- Prerequisite helper: first call `+get_tag_definition_schema` to obtain the structure, then call this tool.
-- When building a real `definition`, metadata must be verified in the same session and `project_id`: first build in this session must call `analysis_meta +list_events` and `analysis_meta +list_properties`; later calls should reuse the session-verified results first.
-- Create a user tag definition. Supports the condition, metric, first_last, and sql tag types. Returns the new tag ID without tag members.
-
-## Required Prerequisites (MUST)
-- Before constructing `--definition`, you must first read and follow these reference docs:
-  - [`./get_tag_definition_schema.md`](./get_tag_definition_schema.md)
-  - [`./list_events.md`](./list_events.md)
-  - [`./list_properties.md`](./list_properties.md)
-- Do not generate the final `definition` until the above docs have been read and metadata has been verified: first build in this session for the same `project_id` must run metadata commands; if session-verified metadata already exists, reuse it first.
-
-## Prerequisite Call Chain (Required for Building Definition)
-1. First determine `--type` (condition / metric / first_last / sql).
-2. Read `get_tag_definition_schema.md` to understand the return structure of `+get_tag_definition_schema`.
-3. Call `ae-cli analysis_audience +get_tag_definition_schema --type <condition|metric|first_last|sql>` to obtain the schema progressively. Start with base mode; request `examples` only if base is insufficient; request `full` only for complex, ambiguous, or repeatedly failing definition construction.
-4. Read `list_events.md`. If this is the first definition build in the current session for this `project_id` (or metadata is not yet verified), call `ae-cli analysis_meta +list_events --project_id <project_id>`; otherwise, reuse the session-verified event metadata first.
-5. Read `list_properties.md`. If this is the first definition build in the current session for this `project_id` (or metadata is not yet verified), call `ae-cli analysis_meta +list_properties --project_id <project_id>`; otherwise, reuse the session-verified property metadata first.
-6. Build `definition` based on the schema + metadata, then call `+create_tag`.
-
-## Commands
-```bash
-ae-cli analysis_audience +create_tag --project_id <project_id> --tag_name demo --display_name demo --definition '{}'
-ae-cli analysis_audience +create_tag --project_id <project_id> --tag_name demo --display_name demo --type condition --definition '{}' --zone_offset 8 --entity_id 1001
-ae-cli analysis_audience +create_tag --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--tag_name` | Yes | Tag name. Must start with a letter and contain only letters, digits, and underscores. Length: 1-80 |
-| `--display_name` | Yes | Tag display name. Length: 1-80 |
-| `--type` | No | Tag type. Supported values: condition, metric, first_last, sql |
-| `--definition` | Yes | Tag definition JSON. MUST call `+get_tag_definition_schema` first, then fill valid event/property names from metadata verified in the same `project_id` (first build queries `analysis_meta` metadata commands; later builds in the same session should reuse verified results first). |
-| `--zone_offset` | No | Optional time zone offset for tag computation. Valid range: -12 to 14 (supports decimals like 5.5). If the user does not specify a timezone, omit this parameter. When a timezone is specified, call get_project_config first to check whether the project supports time zones (timeZoneEnabled) and available values (availableTimeZones). |
-| `--entity_id` | No | Optional entity ID for tag definition. Use list_entities to query available entities. |
-
-## Decision Rules
-- `definition` cannot be written from experience alone: it must satisfy both the schema structure and the project's real metadata.
-- Use progressive schema loading: base first, examples only when needed, full only as a last resort. Do not request full schema for simple tag creation when the intent is clear.
-- Before calling `list_events` / `list_properties`, you must first read the corresponding reference docs to avoid misuse of parameters or misreading return fields. Query metadata on the first build in this session for the same `project_id`; after that, prefer reusing session-verified metadata.
-- For the first execution, it is recommended to pass only the required parameters (`--project_id`, `--tag_name`, `--display_name`, `--definition`) and add optional parameters after confirming the path works.
-- Wrap JSON parameters in single quotes (e.g. `--definition '{}'`) to avoid shell escaping issues.
-- When troubleshooting across projects, first confirm whether `--project_id` matches the current permissions and target environment.
-- Write operations keep confirmation prompts by default; for automation scenarios, reevaluate whether to use `--yes`.
-
-## Next Step on Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill the gap (focus on `--project_id`, `--tag_name`, `--display_name`, `--definition`).
-- If `Invalid JSON` appears, first check schema-required fields, then verify whether event/property names come from the same `project_id`'s metadata query results.
-- If the result after writing is not as expected, immediately re-read the corresponding list/get interfaces and compare before and after.
-
-## Recommended Chain
-- +get_tag_definition_schema -> (first build or refresh) analysis_meta +list_events -> analysis_meta +list_properties -> +create_tag
-- +list_tags -> +get_tags_by_name -> +update_tag