AE/TE capability gateway discovery and generic invocation with ae-cli. Use when the user needs to list or search available capabilities, inspect an unknown capability schema/risk/auth contract, optionally validate complex input or dry-run before execute, or invoke a long-tail capability that has no

ae capability 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. Use this skill for progressive capability discovery and generic gateway invocation. Prefer a domain specific curated command when one exists; use ae cli capability ... for discovery and long tail capabilities. Decision Order 1. Use a domain skill and its curated command when it directly covers the task. 2. Otherwise search the capability catalog. 3. Inspect the selected capability before constructing input. 4. Optionally pre check — pick at most one path from the table below (do not stack validate + dry run by default). 5. Execute ( capability run / curated command). Chat confirmation only for delete ( high risk write ). Never guess a capability ID, input field, enum value, resource ID, or project ID. CRITICAL — Host compat (do this first): After each ae cli run, check stderr and notice.host compat . If either is present, open the user reply with a short ⚠️ version warning and quote the recommended ae cli update (or update cluster) guidance, then present the business result. For new local installations use npx @thinkingai/ae cli@latest install . Soft tip; ok: true can still carry the notice. Agent Context Telemetry Hard rule: before running gateway backed ae cli commands, 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. Create or update the context file when starting a CLI backed task and whenever the user's CLI purpose changes. Reuse it while the purpose and model remain unchanged. 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. At minimum, include: agent client agent model whenever the current model can be confirmed stable agent session id agent turn id when available intent source: "agent context file" concise user intent for the current CLI triggering purpose current session goal 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. Write this JSON object to .ae/cli agent context.json : Use this local template when updating the file. Replace every placeholder with verified context before running it; write the confirmed model explicitly rather than reading an optional environment variable. For an unknown model, omit that field and add the partial status described above. If a field is unknown, omit that field rather than guessing; do not omit the whole context file. Keep agent session id stable across the conversation; increment or update intent revision when user corrections change the CLI purpose. Prefer a short task level user intent summary over a long raw transcript. If privacy is a concern, send user intent hash and a coarse intent summary instead of verbatim user text. After running a gateway command, if you are asked whether intent telemetry was sent, verify that .ae/cli agent context.json existed before the command and contained user intent or user intent hash . Runtime only context is only a partial fallback and does not satisfy this hard rule. Fallbacks, in priority order: .ta/cli agent context.json / .ae/cli agent context.json agent context for isolated no write environments or local debugging legacy TA CLI variables runtime environment auto detection. Analysis outcome assessment and supplementary feedback 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 only scenario samples; existing invocation and intent logs stay 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 the ae cli analysis scenario collect help and append help contracts, 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 one collection tool call but 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. On demand pre check (pick one) Motto: validate = fix params; dry run = confirm ready to run. Hard rule: for the same final input, do not run both validate and dry run by default. dry run already includes parameter validation. Situation What to call Then Simple / familiar input (typical read , few scalar fields) Neither — skip pre check run directly Complex qp / nested payload / share maps; still iterating shape validate / capability validate only (may repeat while fixing) After valid=true , run directly — skip dry run unless below applies Need risk / output mode / supports cancel , or high risk write delete gate dry run / capability dry run only (once on final input) Then confirm (delete) / run . Do not validate first on the same final payload Rare exception: many validate iterations, then still need delete confirmation validate while drafting → one dry run on the final input Then chat confirm → run yes Do not treat validate → dry run → run as the normal path. That stack is the rare exception in the last row only. Skill references Default: do not create a standalone skill reference for every new capability. Use search → inspect → ( optional validate or dry run) → run ; catalog description , risk , and inspect input schema are the contract. Create or keep a standalone reference only when at least one applies: L2 hard bar, easily confused with neighbors, high risk write delete workflow, or multi step orchestration. Domain skills may inline one line summaries in overview matrices (e.g. analysis gateway assets.md ). See [ capability command admission §10](../../docs/capability command admission.md). Commands input accepts: An inline JSON object. A JSON file path. @<path . to read JSON from stdin. The capability namespace is inferred from <capability id for inspect , validate , dry run , and run . Use domain <domain only to override routing. For list , search , and inspect , omit project id for company License/Feature visibility; pass it to include project membership, project Feature, and user permission filtering. validate vs dry run validate / validate dry run / dry run Purpose Check input shape while composing complex payloads Pre execution confirmation (params + risk/output/cancel) Does it mutate business data? No No Primary success fields valid , capability id , normalized input dry run , capability id , risk , output mode , supports cancel , normalized input When to prefer Iterating nested payload / qp / multi field JSON Final input; need risk/output contract or delete gate Typical failure focus Missing/invalid fields, type mismatches, bad qp structure Same param errors, plus readiness sign

ae-capability