Use ae-cli for AE/TE analysis-side data questions, asset operations, and asset governance: reports, analysis boards, BI dashboards, ad-hoc models, drilldown, detail data, alerts, clusters, tags, metrics, metadata, project configuration, tracking plans, governance asset lists/rules/lineage/impact/dep

ae analysis This is the single entry skill for analysis intent and command execution, including review and semantic deduplication of collected analysis questions and evidence based badcase assessment. At the beginning of a new analysis question, capture ae cli analysis scenario begin locally and retain its exact data.start time for that answer. Pass it as start time only when the project permits collection. Do not invent a start time or reuse it for a later revised answer; capture a fresh start for that follow up. This records one question to answer elapsed duration, not separate timing phases. Historical archive review does not start or collect a scenario. For historical analysis question inventory or badcase review, route directly to [scenario list and review](references/scenario list.md), and for quality assessment read [independent scenario evaluation](references/scenario evaluation.md). This is a separate archive review task: skip business query semantic/KB/personal preference preflight and do not collect the review itself as another analysis scenario. The CLI retrieves evidence; the calling Agent judges and deduplicates it. No server side rating or evaluation writeback is required. Capability contract Responsibilities: analysis queries and assets, metadata discovery, audience definitions, local input file upload, and the governance/project/tracking workflows described below. Inputs: verified project context and the requested measures, time windows, filters or operation specific resources; upload also needs a local file and a discovered purpose. Outputs: query evidence with its scope, verified metadata, operation/resource identifiers, uploaded input file identifiers, or asynchronous run/artifact status as applicable. Query rows are not automatically a persisted audience. Boundaries: engagement operations and metadata data table writes/dimension binding are outside this skill's workflows; find the capability needed for any remaining work. Completion: the requested analysis side result is verified, or pending/blocked work is identified. Keep any other parts of the user's request unfinished until addressed. Cross skill collaboration When remaining work is outside this skill's scope, or a necessary prerequisite needs another capability, follow [the collaboration protocol](references/collaboration.md). Choose from the skills available in this run by capability, preserve verified context, and continue the remaining task. Reuse this protocol if already loaded. Agent Context Telemetry Hard rule: before running gateway backed ae cli commands in this skill, maintain the current Agent context in .ae/cli agent context.json at the working directory root, unless the user explicitly asks not to send intent telemetry. Keep the business command clean; do not append agent context <base64url json by default. Runtime auto detection alone is only a partial fallback and is not enough for user intent telemetry. The context file must use intent source: "agent context file" and should include a concise task level user intent , the current session goal , stable agent session id , current agent turn id when available, intent relation , and intent revision . Include agent model whenever the current model can be confirmed. Use the user's original language for session initial intent , user intent , and session goal ; for example, use Chinese text for a Chinese user request. Omit unknown parent turn fields rather than guessing; do not omit the whole context payload. Prefer concise intent summaries over long raw transcripts. Update the file when starting a CLI backed task or when the user's CLI purpose changes. Reuse it while the purpose and model remain unchanged. The Agent must actively obtain the current model identifier and write it explicitly as agent model in the context file. Use trusted runtime context or bounded metadata for the exact current session and turn; for example, Codex's current session turn context.model . Do not rely solely on a model environment variable being present. Never infer the model from the Agent/product name, a configured default, or another session. This requirement applies to every Agent client. Update the file when the model changes, even if the CLI purpose stays the same. If the model cannot be confirmed, omit agent model , set context capture status: "partial" , and continue; do not block or delay the business command or ask the user to identify the model just for telemetry. Once confirmed, write the model and remove the stale partial marker so the CLI can compute capture status from the remaining fields. Analysis workflow For data queries: 1. Take the current project and requested metrics, windows, groups and filters. Before choosing a knowledge base or analysis route, apply the [Project Semantic Knowledge and Discovery]( project semantic knowledge and discovery) gate. Reuse known assets and definitions; discover unknown business measures with [metadata resolution](references/metadata resolution.md), then select the needed saved report or ad hoc command/model references. 2. Confirm any new business mapping once, fill the required parameters, and execute the applicable saved report or complete ad hoc definition. Reuse confirmed meanings in dependent queries. If the confirmation tool cannot obtain a reply, present the same choices in text and wait for the reply. 3. Correct compiler errors at their reported paths. New evidence or a user correction changes a completed choice; preserve the other verified inputs. 4. Use the returned result directly. Save original JSON only when the user requests a file or necessary local processing requires one; follow [result handling](references/analysis data retrieval.md preserve and interpret results). Keep stderr and the CLI exit status visible. 5. Compute only missing values needed by the request, together in one local call. Reuse completed results and answer when the requested data is available, or explain the specific error or missing input. 6. Scenario collection is project opt in. Before preparing or uploading a scenario sample, read ae cli project info get project id <source project id for the current host, authenticated account, and source analysis project. Only data.analysis scenario collection enabled === true permits collection. Recheck for each new scenario and before appending feedback or a revision; do not reuse a previous grant or the company configuration's 24 hour cache. A missing field (including older services), false, unreadable configuration, or unknown project means skip collection and answer normally. Never enable the project switch, choose a different project, or invent a project ID to make collection succeed. The curated collect/append commands also check immediately before submission, and the service is authoritative if the switch changes. This controls scenario samples and the related Common gateway HDFS call archive; existing invocation and intent event reporting stays unchanged. accepted=false, skipped=true is a normal skip, not a failed analysis or successful upload. Do not retry, backfill, or fall back to analysis feedback submit to bypass this switch. Collect one sample for the whole user scenario, not one per CLI call. After forming the final answer, use ae cli analysis scenario collect as specified in [scenario collection](references/scenario collect.md), then deliver that exact answer text. Capture the original question/confirmed clarifications, actual final answer and the ordered query path (existing capability/call IDs and optional short purpose; prefer only meta.invocation id, never confuse a business request id with gateway client request id), never query result rows or error payloads; do not score correctness or generate a separate self evaluation. The question id is the original scenario's first user turn ID, stable across clarification, retries, multiple queries and corrections. Store/reuse the IDs returned by collection in conversation context. On later user objections, scope corrections or reported omissions targeting that answer, append the user's original text with ae cli analysis scenario append entry type user feedback and the original question id/target answer id; do not decide whether the user is right. An ambiguous request for an explanation may be preserved as user text when clearly linked; do not invent a link. A normal follow up or changed requirement is not automatically negative feedback. After a substantive follow up answer to the same scenario (recheck, explanation, correction or scope clarification), append answer revision with that exact answer/query path and a new answer id, even when the conclusion stays the same; keep earlier answers. If the triggering user request was not already captured as user feedback, include its exact text using user message on answer revision so later scope changes are not lost. Do not duplicate feedback text in user message. Acknowledgments such as thanks alone need no entry. A genuinely separate question gets a new question id. Do not create another initial sample for an existing scenario. A separate evaluation task reads these samples later and can join existing call telemetry for parameters/status/timing. Path only evidence cannot prove numeric answer correctness; unresolved correctness stays unknown. Only attempted analysis data queries qualify; metadata, discovery, help and asset writes alone do not. No routine satisfaction question. Collection failure must not block the answer or subsequent business work, trigger login or automatic retries, or be claimed as successful ingestion. For external Agents this is a Skill collection step, not a guaranteed post answer hook; it has a local clock capture plus the collection tool call, with no additional evaluation task on the answering path. User feedback is evidence, not a correctness label. Preserve exact user words and their target answer even if you disagree. Do not routinely ask for a satisfaction rating. The existing analysis feedback submit contract remains available for explicit standalone user ratings without a collected scenario; when a scenario exists, use its append command instead of submitting duplicate feedback. No explicit feedback means no submission or new feedback event for cli analysis feedback . Do not upload the analysis answer through that legacy feedback command. All collection excludes credentials, full transcripts and private reasoning. Route before reading 1. Map the request to a command family before opening any reference. CLI Agent asset authentication and metric recommendation review: this includes requests to recommend project assets for certification/authentication, review asset certification candidates, review project asset governance recommendations, review recommended metrics, or explicitly auto review/auto certify recommended assets. Open references/governance recommendation export.md and route to analysis meta governance recommendation export submit auto review decisions . For review page submission, open references/agent review submit to page.md and use analysis meta agent review submit to page list detail records review retry . Apply its Business Topics and Subtopics contract: both levels require business interpretation and independent review; a source dashboard is an evidence container, not a default second level group. Do not load project semantics, project KB, or personal semantic preferences as a preflight. Project semantic knowledge base build/update/refresh/sync: open references/project semantic knowledge wiki.md and route to project semantic asset package export , local semantic planning, and local Wiki rendering. Default to CLI semantic precompilation into Markdown sources, source ZIP upload, formal preset initialization/reuse, and KB compilation. Do not regenerate Schema or AI validate unchanged presets during normal refresh. Update ch

ae-analysis