@thinkingai/ae-cli 6.0.30 → 6.0.31

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

@@ -5,28 +5,25 @@
 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.
+- events: JSON array of real events to combine, each with eventName and optional filter.
 
 ## 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"}]`
+1. Read `list_events.md`, then call `ae-cli analysis_meta +list_events --project_id <project_id>` to get available events.
+2. Read `list_properties.md`, then call `ae-cli analysis_meta +list_properties --project_id <project_id>` to get properties available for filtering.
+3. Build `events` / `filter` from the command payload shape and verified metadata, then call `+create_virtual_event`.
+4. Example events JSON: `[{"eventName":"purchase"},{"eventName":"add_to_cart"}]`
 
 ## Commands
 ```bash
@@ -42,23 +39,22 @@ ae-cli analysis_meta +create_virtual_event --dry-run
 | `--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`. |
+| `--events` | Yes | JSON array of events to combine. 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, 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.
+- `events` / `filter` must not be handwritten by intuition alone: they must satisfy the command payload shape 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.
+- This is an ordinary `write` operation and does not require CLI confirmation.
 
 ## 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 `Invalid JSON` appears, first check 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

@@ -56,7 +56,7 @@ ae-cli analysis_meta +create_virtual_property --dry-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.
+- This is an ordinary `write` operation and does not require CLI confirmation.
 
 ## 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`).

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

@@ -9,7 +9,7 @@ If both `--to-space-id` and `--to-folder-id` are omitted, the gateway copies to
 Command:
 
 ```bash
-ae-cli analysis dashboard copy --project-id <project_id> --dashboard-id <source_dashboard_id> --dashboard-name <new_name> [--report-copy true] [--to-space-id <space_id>] [--to-folder-id <folder_id>] --yes
+ae-cli analysis dashboard copy --project-id <project_id> --dashboard-id <source_dashboard_id> --dashboard-name <new_name> [--report-copy true] [--to-space-id <space_id>] [--to-folder-id <folder_id>]
 ```
 
 Input sends `project_id`, `dashboard_id`, `dashboard_name`, `report_copy` defaulting to false, and optional `to_space_id`, `to_folder_id`.

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

@@ -7,7 +7,7 @@ Do not use to copy an existing dashboard. Use `dashboard copy` for copy workflow
 Command:
 
 ```bash
-ae-cli analysis dashboard create --project-id <project_id> --dashboard-name <name> [--space-id <space_id>] [--folder-id <folder_id>] [--initial-report-id <report_id>] [--payload '{...}'] --yes
+ae-cli analysis dashboard create --project-id <project_id> --dashboard-name <name> [--space-id <space_id>] [--folder-id <folder_id>] [--initial-report-id <report_id>] [--payload '{...}']
 ```
 
 Input sends `project_id`, `dashboard_name`, and optional `space_id`, `folder_id`, `initial_report_id`, `payload`.

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

@@ -7,7 +7,7 @@ Do not use for configuration changes. Use `dashboard-daily-report update`.
 Command:
 
 ```bash
-ae-cli analysis dashboard-daily-report send --project-id <project_id> --dashboard-id <dashboard_id> [--need-csv true] [--host-url <url>] [--payload '{...}'] --yes
+ae-cli analysis dashboard-daily-report send --project-id <project_id> --dashboard-id <dashboard_id> [--need-csv true] [--host-url <url>] [--payload '{...}']
 ```
 
 Input sends `project_id`, `dashboard_id`, and optional daily report fields or `payload`.

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

@@ -7,7 +7,7 @@ Do not use to send immediately. Use `dashboard-daily-report send`.
 Command:
 
 ```bash
-ae-cli analysis dashboard-daily-report update --project-id <project_id> --dashboard-id <dashboard_id> [--enable-send true] [--send-time <time>] [--send-title <title>] [--send-content <content>] [--payload '{...}'] --yes
+ae-cli analysis dashboard-daily-report update --project-id <project_id> --dashboard-id <dashboard_id> [--enable-send true] [--send-time <time>] [--send-title <title>] [--send-content <content>] [--payload '{...}']
 ```
 
 Input sends `project_id`, `dashboard_id`, and optional daily report fields or `payload`.

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

@@ -7,7 +7,7 @@ Do not use a separate pre-check command; validation is part of this import comma
 Command:
 
 ```bash
-ae-cli analysis dashboard-definition import --project-id <project_id> --definition '{...}' [--validate-only true] [--dashboard-name-conflict-policy <policy>] [--space-dashboard-policy <policy>] [--payload '{...}'] --yes
+ae-cli analysis dashboard-definition import --project-id <project_id> --definition '{...}' [--validate-only true] [--dashboard-name-conflict-policy <policy>] [--space-dashboard-policy <policy>] [--payload '{...}']
 ```
 
 Input sends `project_id`, `definition`, and optional validation/import policies and `payload`.

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

@@ -7,6 +7,8 @@ Do not use for soft archival or hiding unless the gateway contract defines that
 Command:
 
 ```bash
+ae-cli analysis dashboard delete --project-id <project_id> --dashboard-ids '[1001,1002]' --dry-run
+# Summarize the target and impact, then wait for explicit user confirmation.
 ae-cli analysis dashboard delete --project-id <project_id> --dashboard-ids '[1001,1002]' --yes
 ```
 

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

@@ -7,7 +7,7 @@ Do not use for dashboard lock/version operations; those are intentionally not CL
 Command:
 
 ```bash
-ae-cli analysis dashboard freeze --project-id <project_id> --dashboard-ids '[1001,1002]' [--freeze true] --yes
+ae-cli analysis dashboard freeze --project-id <project_id> --dashboard-ids '[1001,1002]' [--freeze true]
 ```
 
 Input sends `project_id`, `dashboard_ids`, and optional `freeze`.

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

@@ -7,7 +7,7 @@ Do not use to share dashboards without ownership transfer. Use `dashboard share`
 Command:
 
 ```bash
-ae-cli analysis dashboard handover --project-id <project_id> --dashboard-ids '[1001,1002]' --to-user-id <user_id> --yes
+ae-cli analysis dashboard handover --project-id <project_id> --dashboard-ids '[1001,1002]' --to-user-id <user_id>
 ```
 
 Input sends `project_id`, `dashboard_ids`, and `to_user_id`.

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

@@ -7,9 +7,11 @@ Do not use for dashboard report data. Use `dashboard-report-data run` or `dashbo
 Command:
 
 ```bash
-ae-cli analysis dashboard list --project-id <project_id> [--query <keyword>] [--fields '["id","name"]'] [--limit 20] [--offset 0]
+ae-cli analysis dashboard list --project-id <project_id> [--query <keyword>] [--fields '["dashboard_id","dashboard_name"]'] [--limit 50] [--offset 0]
 ```
 
-Input uses `project_id` plus optional `query`, `fields`, `limit`, `offset`. Use `--payload` only when the dedicated gateway contract requires extra snake_case filters.
+Input uses `project_id` plus optional `query`, `fields`, `limit`, `offset`. `--fields` accepts only `dashboard_id`, `dashboard_name`, and `remark`. Input and output both use snake_case; do not use `dashboardId`, `dashboardName`, generic `id`, or generic `name`.
+
+When `has_more=true`, continue only with the returned `next_offset`; do not calculate the next page locally.
 
 Output is the gateway envelope. `data` contains dashboard summaries and paging metadata when returned by the gateway.

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

@@ -0,0 +1,15 @@
+# analysis dashboard-report add
+
+Use when the user explicitly wants to add existing saved reports to a dashboard.
+
+Do not use for creating reports or dashboards. Create those assets first, then call this command with exact IDs.
+
+Command:
+
+```bash
+ae-cli analysis dashboard-report add --project-id <project_id> --dashboard-id <dashboard_id> --report-ids '[1001,1002]'
+```
+
+Input sends `project_id`, `dashboard_id`, and `report_ids`.
+
+Output is the gateway envelope. `data` contains `dashboard_id`, requested `report_ids`, and `added_count`.

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

@@ -1,8 +1,10 @@
 # analysis dashboard-report-data export
 
-Use for dashboard report data queries that may be large or long-running.
+Submit dashboard report data as a downloadable async artifact. Dashboard report data follows report-data model coverage: the 12 analysis report models from `ai_models.md` plus tag report data.
 
-Do not use when the user needs a tiny immediate preview. Use `dashboard-report-data run` with a small `--limit`.
+Routing: read [`analysis_data_retrieval.md`](analysis_data_retrieval.md) before choosing this `export` command instead of `dashboard-report-data run`.
+
+Do not use this command for bounded inline previews; use `dashboard-report-data run` when the requested result fits the sync data retrieval rule.
 
 Command:
 
@@ -10,15 +12,21 @@ Command:
 ae-cli analysis dashboard-report-data export --project-id <project_id> --dashboard-id <dashboard_id> [--report-ids '[1,2]'] [--filters '{...}'] [--start-time <time>] [--end-time <time>] [--artifact-format jsonl]
 ```
 
-Input sends `project_id`, `dashboard_id`, and optional `report_ids`, `filters`, `start_time`, `end_time`, `use_cache`, `request_id`, `timeout_seconds`, `format`. Use CLI flag `--artifact-format` for the gateway `format` input; `--format` is the CLI output formatter.
+Input sends `project_id`, `dashboard_id`, and optional `report_ids`, `filters`, `start_time`, `end_time`, `use_cache`, `request_id`, `timeout_seconds`, `format`. Use CLI flag `--artifact-format` for the gateway `format` input; `--format` is the CLI output formatter. Async export has no inline row limit. Runtime defaults to and is capped at 21600 seconds (6 hours); cancel earlier with `analysis query cancel --run-id <run_id>`. The routing rule lives in [`analysis_data_retrieval.md`](analysis_data_retrieval.md).
 
-`--filters` is an analysis Filter JSON injected as `commonFilter.aiFilter` for each queried report. It is not a dashboard UI control dump. Use `ae-cli analysis +get_filter_schema` for the exact schema. Minimal shape:
+`--filters` uses the same AI-facing filter model as report data. The gateway resolves fields and compiles it to the dashboard backend filter. Do not pass a dashboard UI control dump or raw QP filter. Minimal shape:
 
 ```json
-{"relation":"and","filts":[{"field":{"type":"event_property","propertyName":"#event_name"},"operator":"equal","values":["login"]}]}
+{"relation":"and","items":[{"field":{"name":"country","type":"user_property"},"operator":"eq","values":["US"]}]}
 ```
 
-Output is the gateway envelope. `data` contains an async export descriptor with `run_id`, `artifact_id`, status fields, and expiration fields. It does not expose inspect/download API paths; use the CLI commands below.
+Dashboard `filters`, `start_time`, and `end_time` do not apply to SQL reports. Export still completes with SQL report data; the JSONL result object includes `warnings[]` with `OVERRIDE_IGNORED_FOR_MODEL`, affected SQL `report_ids`, and `ignored_fields`. Query SQL reports directly with report-data `--sql-params` when SQL conditions must change.
+
+Output is the gateway envelope. `data` contains an async export descriptor with `run_id`, `artifact_id`, status fields, expiration fields, and `query_context_id` / `query_context_expires_at` when Redis context creation succeeds. It does not expose inspect/download API paths; use the CLI commands below.
+
+An empty artifact is successful and means the requested time range has no data. The run reaches `FAILED` only when every returned dashboard report entry contains an explicit execution error. Mixed dashboard exports retain successful data and explicit per-report failure entries.
+
+Use the submit response `query_context_id` immediately with `analysis drilldown-users run` or `analysis query create-result-cluster` when present. After the run completes, the downloaded artifact's first metadata line repeats the query context for file consumers. Do not pass raw QP.
 
 Follow-up workflow:
 
@@ -26,6 +34,6 @@ Follow-up workflow:
 2. Poll status with `ae-cli analysis run inspect --run-id <run_id>`.
 3. Continue polling while status is running or pending. Treat `COMPLETED` or `SUCCEEDED` as success, and `FAILED`, `CANCELED`, or `CANCELLED` as terminal failure.
 4. On success, download with `ae-cli analysis artifact download --run-id <run_id> --artifact-id <artifact_id> --output <file>`.
-5. If the export is no longer needed, cancel with `ae-cli analysis query cancel --run-id <run_id> --yes`.
+5. If the export is no longer needed, cancel with `ae-cli analysis query cancel --run-id <run_id>`.
 
 Do not write custom Python/curl for polling or download unless the CLI command itself is unavailable.

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

@@ -1,21 +1,29 @@
 # analysis dashboard-report-data run
 
-Use for bounded inline dashboard report data queries when the expected result is small enough for immediate JSON output.
+Execute bounded inline dashboard report data queries. Dashboard report data follows report-data model coverage: the 12 analysis report models from `ai_models.md` plus tag report data.
 
-Do not use for large or long-running result sets. Use `dashboard-report-data export`.
+Routing: read [`analysis_data_retrieval.md`](analysis_data_retrieval.md) before choosing this `run` command instead of `dashboard-report-data export`.
+
+Do not use this command for full, unknown-size, larger than 1000-row, or long-running dashboard report data; use `dashboard-report-data export`.
 
 Command:
 
 ```bash
-ae-cli analysis dashboard-report-data run --project-id <project_id> --dashboard-id <dashboard_id> [--report-ids '[1,2]'] [--filters '{...}'] [--start-time <time>] [--end-time <time>] [--limit 100] [--timeout-seconds 60]
+ae-cli analysis dashboard-report-data run --project-id <project_id> --dashboard-id <dashboard_id> [--report-ids '[1,2]'] [--filters '{...}'] [--start-time <time>] [--end-time <time>] [--limit 100] [--timeout-seconds 180]
 ```
 
-Input sends `project_id`, `dashboard_id`, and optional `report_ids`, `filters`, `start_time`, `end_time`, `use_cache`, `request_id`, `timeout_seconds`, `limit`.
+Input sends `project_id`, `dashboard_id`, and optional `report_ids`, `filters`, `start_time`, `end_time`, `use_cache`, `request_id`, `timeout_seconds`, `limit`. Control defaults: `--limit` default 100 / max 1000, `--timeout-seconds` default and max 180. An explicitly supplied lower timeout still wins. The routing rule lives in [`analysis_data_retrieval.md`](analysis_data_retrieval.md).
 
-`--filters` is an analysis Filter JSON injected as `commonFilter.aiFilter` for each queried report. It is not a dashboard UI control dump. Use `ae-cli analysis +get_filter_schema` for the exact schema. Minimal shape:
+`--filters` uses the same AI-facing filter model as report data. The gateway resolves fields and compiles it to the dashboard backend filter. Do not pass a dashboard UI control dump or raw QP filter. Minimal shape:
 
 ```json
-{"relation":"and","filts":[{"field":{"type":"event_property","propertyName":"#event_name"},"operator":"equal","values":["login"]}]}
+{"relation":"and","items":[{"field":{"name":"country","type":"user_property"},"operator":"eq","values":["US"]}]}
 ```
 
-Output is the gateway envelope. `data` contains bounded inline report data.
+Dashboard `filters`, `start_time`, and `end_time` do not apply to SQL reports. The query still succeeds and returns those SQL report results. Inspect `data.warnings[]`; `OVERRIDE_IGNORED_FOR_MODEL` contains the affected SQL `report_ids` and `ignored_fields`. To change SQL conditions, query the SQL report directly with `analysis report-data run` and saved `definition.params` through `--sql-params`.
+
+Output is the gateway envelope. `data` contains bounded inline report data, optional structured `warnings`, plus `query_context_id`, `drilldown_available`, and `result_cluster_available` when a context can be created.
+
+An empty dashboard batch or report result with no rows is a successful query: it means the requested time range has no data. The command fails only when every returned report entry contains an explicit execution error. Mixed dashboard batches keep successful data and return `meta.partial`, counts, and per-report `meta.failures`.
+
+Use `query_context_id` with `analysis drilldown-users run` or `analysis query create-result-cluster`. Do not pass raw QP.

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

@@ -7,9 +7,18 @@ Do not use to read sharing only. Use `dashboard share-info`.
 Command:
 
 ```bash
-ae-cli analysis dashboard share --project-id <project_id> --dashboard-id <dashboard_id> [--member-authorities '{...}'] [--payload '{...}'] --yes
+ae-cli analysis dashboard share --project-id <project_id> --dashboard-id <dashboard_id> --member-authorities '{"10001":"READ","10002":"EDIT"}'
 ```
 
-Input sends `project_id`, `dashboard_id`, and either `member_authorities` or a backend-compatible snake_case `payload`.
+Input sends `project_id`, `dashboard_id`, and either `member_authorities` or a documented snake_case `payload`.
+
+`member_authorities` is the complete directly shared user map, not an incremental patch:
+
+- each key is a numeric user ID encoded as a JSON object key;
+- each value is `READ`, `EDIT`, `CREATOR`, or `MAINTAIN`;
+- users omitted from the map are removed from direct sharing;
+- `{}` removes all directly shared users.
+
+Call `analysis dashboard share-info` first when the user intends to preserve existing members while adding or changing only some entries.
 
 Output is the gateway envelope. `data` contains the share update result.

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

@@ -7,10 +7,19 @@ Do not use for moving/copying dashboards. Use `dashboard copy`, `dashboard hando
 Command:
 
 ```bash
-ae-cli analysis dashboard update --project-id <project_id> --operation settings --dashboard-ids '[1001,1002]' [--zone-offset 8] [--payload '{...}'] --yes
-ae-cli analysis dashboard update --project-id <project_id> --operation note-upsert --dashboard-id <dashboard_id> [--note-id <note_id>] [--note-title <title>] [--description <text>] --yes
+ae-cli analysis dashboard update --project-id <project_id> --operation settings --dashboard-ids '[1001,1002]' [--zone-offset 8] [--payload '{...}']
+ae-cli analysis dashboard update --project-id <project_id> --operation settings --dashboard-id <dashboard_id> --refresh-type 1 --dashboard-status normal --payload '{"dashboard_job_schedule":"0 0 8 * * ?","time_config_open":true,"time_config":{},"cache_config":{},"schedule_ui_config":{}}'
+ae-cli analysis dashboard update --project-id <project_id> --operation note-upsert --dashboard-id <dashboard_id> [--note-id <note_id>] [--note-title <title>] [--description <text>]
 ```
 
-Input sends `project_id`, `operation`, optional dashboard identifiers, setting fields (including `zone_offset` as hours, e.g. `8` for UTC+8), note fields, and optional `payload`.
+For `operation=settings`:
+
+- identify one dashboard with `dashboard_id`, or a batch with `dashboard_ids`;
+- `refresh_type` is integer `0` (real-time) or `1` (scheduled);
+- `dashboard_status` is string `normal` or `freeze`;
+- `zone_offset` is an integer hour offset from `-12` to `14`;
+- complex settings belong in snake_case `payload`: `reports_version` string, `dashboard_job_schedule` string, `time_config_open` boolean, and object fields `time_config`, `cache_config`, `schedule_ui_config`; `ui_config` may be a string or object.
+
+For `operation=note-upsert`, pass `dashboard_id`; omit `note_id` to create a note or pass it to update an existing note. Do not mix note fields with batch settings fields.
 
 Output is the gateway envelope. `data` contains the update result.

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

@@ -2,7 +2,7 @@
 
 Use when the user needs to get columns for a project table reference.
 
-Do not use this command for unrelated analysis queries, ad-hoc query construction, or MCP metadata discovery when an existing specialized command already fits the user's request.
+Do not use it to read table rows or infer a table reference; discover the exact table first and use a data query for row values.
 
 Command:
 
@@ -15,7 +15,7 @@ Capability id: `metadata.data_table.columns_get`.
 
 Input sends `project_id`, `table_ref`.
 
-Output is the gateway envelope. `data` contains the common-service capability result.
+Output contains resolved `data.table_ref` and `data.columns[]` from SQL IDE metadata.
 
 ## Parameters
 | Parameter | Required | Description |

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

@@ -2,7 +2,7 @@
 
 Use when the user needs to list metadata and assets affected by data table deletion or column changes.
 
-Do not use this command for unrelated analysis queries, ad-hoc query construction, or MCP metadata discovery when an existing specialized command already fits the user's request.
+Do not use it as a delete command. It is a read-only dependency check before table/column mutation.
 
 Command:
 
@@ -15,7 +15,7 @@ Capability id: `metadata.data_table.influence_list`.
 
 Input sends `project_id`, `datatable_id`.
 
-Output is the gateway envelope. `data` contains the common-service capability result.
+Output includes `data.resources[]`, `data.continuable`, and `data.project_info` for the proposed table operation.
 
 ## Parameters
 | Parameter | Required | Description |

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

@@ -2,7 +2,7 @@
 
 Use when the user needs to get data table version detail.
 
-Do not use this command for unrelated analysis queries, ad-hoc query construction, or MCP metadata discovery when an existing specialized command already fits the user's request.
+Do not use it for the current table definition without a verified version ID; list versions first.
 
 Command:
 
@@ -15,7 +15,7 @@ Capability id: `metadata.data_table_version.get`.
 
 Input sends `project_id`, `version_id`.
 
-Output is the gateway envelope. `data` contains the common-service capability result.
+Output `data.version` contains the selected historical version detail.
 
 ## Parameters
 | Parameter | Required | Description |

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

@@ -2,7 +2,7 @@
 
 Use when the user needs to list data table historical versions.
 
-Do not use this command for unrelated analysis queries, ad-hoc query construction, or MCP metadata discovery when an existing specialized command already fits the user's request.
+Do not use it for one version's full definition or table row history; use `datatable version-get` for the selected metadata version.
 
 Command:
 
@@ -15,7 +15,7 @@ Capability id: `metadata.data_table_version.list`.
 
 Input sends `project_id`, `datatable_id`.
 
-Output is the gateway envelope. `data` contains the common-service capability result.
+Output `data.versions[]` contains historical metadata versions for the data table.
 
 ## Parameters
 | Parameter | Required | Description |

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

@@ -6,11 +6,16 @@ Domain: **Alert Management**
 
 ## Use Cases
 - Permanently delete an alert by its ID.
+- Do not use this command to disable or edit an alert; use `+update_alert` when the alert must remain.
+
+## Output
+Success confirms that the specified alert was deleted. The command does not return alert data; use `+list_alerts` to verify it is absent.
 
 ## Commands
 ```bash
-ae-cli analysis +delete_alert --project_id <project_id> --alert_id <alert_id>
-ae-cli analysis +delete_alert --dry-run
+ae-cli analysis +delete_alert --project_id <project_id> --alert_id <alert_id> --dry-run
+# Summarize the target and impact, then wait for explicit user confirmation.
+ae-cli analysis +delete_alert --project_id <project_id> --alert_id <alert_id> --yes
 ```
 
 ## Parameters
@@ -21,7 +26,7 @@ ae-cli analysis +delete_alert --dry-run
 
 ## Decision Rules
 - Use `+list_alerts` first to confirm the alert ID before deleting.
-- This is a destructive operation; keep the confirmation prompt unless automation is explicitly required.
+- This is `high-risk-write`: inspect the dry-run, summarize the target and impact, and wait for explicit user confirmation before the `--yes` execution.
 
 ## Recommended Chain
 - `+list_alerts` -> `+delete_alert`

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

@@ -6,11 +6,16 @@ Domain: **Metric Management**
 
 ## Use Cases
 - Permanently delete a metric by its ID.
+- Do not use it when the metric should be retained with a corrected definition; use `+update_metric` instead.
+
+## Output
+Success confirms deletion of the specified metric. The command does not return a metric definition; verify absence with `+list_metrics`.
 
 ## Commands
 ```bash
-ae-cli analysis_meta +delete_metric --project_id <project_id> --metric_id <metric_id>
-ae-cli analysis_meta +delete_metric --dry-run
+ae-cli analysis_meta +delete_metric --project_id <project_id> --metric_id <metric_id> --dry-run
+# Summarize the target and impact, then wait for explicit user confirmation.
+ae-cli analysis_meta +delete_metric --project_id <project_id> --metric_id <metric_id> --yes
 ```
 
 ## Parameters
@@ -21,7 +26,7 @@ ae-cli analysis_meta +delete_metric --dry-run
 
 ## 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.
+- This is `high-risk-write`: inspect the dry-run, summarize the target and impact, and wait for explicit user confirmation before the `--yes` execution.
 
 ## Recommended Chain
 - `+list_metrics` -> `+delete_metric`

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

@@ -6,11 +6,13 @@ Domain: **Project Configuration**
 
 ## Use Cases
 - Delete one or more project date markers.
+- Do not use it to hide or edit a marker; use `+update_project_mark_time` when the marker should remain.
 
 ## Commands
 ```bash
-ae-cli analysis_meta +delete_project_mark_times --project_id <project_id> --mark_time_ids '[]'
-ae-cli analysis_meta +delete_project_mark_times --dry-run
+ae-cli analysis_meta +delete_project_mark_times --project_id <project_id> --mark_time_ids '[]' --dry-run
+# Summarize the target and impact, then wait for explicit user confirmation.
+ae-cli analysis_meta +delete_project_mark_times --project_id <project_id> --mark_time_ids '[]' --yes
 ```
 
 ## Parameters
@@ -23,7 +25,7 @@ ae-cli analysis_meta +delete_project_mark_times --dry-run
 - 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.
+- This is `high-risk-write`: inspect the dry-run, summarize the target and impact, and wait for explicit user confirmation before the `--yes` execution.
 
 ## 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`).

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

@@ -10,8 +10,9 @@ Domain: **Project Configuration**
 
 ## Command
 ```bash
-ae-cli analysis_meta +delete_track_items --project_id <project_id> --delete_data '{}'
-ae-cli analysis_meta +delete_track_items --dry-run
+ae-cli analysis_meta +delete_track_items --project_id <project_id> --delete_data '{}' --dry-run
+# Summarize the target and impact, then wait for explicit user confirmation.
+ae-cli analysis_meta +delete_track_items --project_id <project_id> --delete_data '{}' --yes
 ```
 
 ## Parameters
@@ -24,7 +25,7 @@ ae-cli analysis_meta +delete_track_items --dry-run
 - 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.
+- This is `high-risk-write`: inspect the dry-run, summarize the target and impact, and wait for explicit user confirmation before the `--yes` execution.
 
 ## 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`).

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

@@ -0,0 +1,20 @@
+# analysis drilldown-user-events export
+
+Export the complete event sequence for one user from a drilldown context. Do not pass raw QP.
+
+## Command
+
+```bash
+ae-cli analysis drilldown-user-events export \
+  --drilldown-context-id <drilldown_context_id> \
+  --user-id <user_id> \
+  [--sort-order desc] \
+  [--artifact-format jsonl] \
+  [--timeout-seconds 21600]
+```
+
+Use identifiers returned by `analysis drilldown-users run` or its export artifact. Export does not accept `--limit`, `--page-num`, or `--page-size`; Common advances backend pages internally and writes one JSONL artifact.
+
+Inspect the returned `run_id` with `analysis run inspect`, then download the completed artifact with `analysis artifact download`.
+
+Output is an async run/artifact descriptor. The complete event rows exist only in the downloaded artifact.

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

@@ -0,0 +1,34 @@
+# analysis drilldown-user-events run
+
+Query event sequence details for one user after `analysis drilldown-users run`.
+
+Use this only after `analysis drilldown-users run` returns a `drilldown_context_id`.
+
+Do not pass raw QP.
+
+## Command
+
+```bash
+ae-cli analysis drilldown-user-events run \
+  --drilldown-context-id <drilldown_context_id> \
+  --user-id <user_id> \
+  [--sort-order desc] \
+  [--limit 100] \
+  [--timeout-seconds 120]
+```
+
+## Input
+
+- `--drilldown-context-id`: returned by `analysis drilldown-users run`.
+- `--user-id`: user id returned by `analysis drilldown-users run`.
+- `--properties`: optional backend property request object array. Omit this in normal agent calls and use the default returned columns. Do not pass string-name arrays such as `["event_time"]`.
+- `--sort-order`: `asc` or `desc`.
+- `--event-name-filter`, `--time-filter`, `--time-filter-before-nums`, `--time-filter-after-nums`: optional event sequence filters.
+
+Do not use raw QP, `query_context_id`, or guessed user IDs for this command.
+
+The `drilldown_context_id` must come from a `drilldown-users` target that includes date context, such as `drilldown_date` or `target_dates`. A context created from `include_total` alone can list users, but may fail event-sequence lookup with `TARGET_DATES_REQUIRED`.
+
+## Output
+
+The response contains at most `limit` event rows. When `truncated=true`, use `analysis drilldown-user-events export`; do not attempt to fetch another page.

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

@@ -0,0 +1,17 @@
+# analysis drilldown-users export
+
+Export all users for a selected result target from a previous analysis query context. Do not pass raw QP.
+
+## Command
+
+```bash
+ae-cli analysis drilldown-users export \
+  --query-context-id <query_context_id> \
+  --target '<json>' \
+  [--artifact-format jsonl] \
+  [--timeout-seconds 21600]
+```
+
+Use the same `query_context_id`, `target`, and optional `properties` contract as `analysis drilldown-users run`. Export does not accept `--limit` or `--offset`; Common reads backend batches internally and writes one JSONL artifact.
+
+Inspect the returned `run_id` with `analysis run inspect`, then download the completed artifact with `analysis artifact download`. The final metadata line includes `rows`, `total`, and `drilldown_context_id`.