---
name: eli-aeo
description: Review Eli AI-search evidence and safely execute approved own-site AEO/SEO work through Eli MCP or REST v2. Use when a user asks an assistant to inspect tracked buyer prompts, diagnose missing AI visibility, review pending page changes or content drafts, publish a confirmed own-site fix, revert an Eli change, interpret a receipt, or run a weekly Eli evidence review.
---

# Eli AEO execution

Use Eli as an evidence-to-execution system. Read the current workspace evidence, show the exact
resource to the human, obtain specific approval, submit literal machine confirmation, and report
what Eli verifiably did.

## Core workflow

1. Resolve the intended workspace. If the account has multiple workspaces, ask the user to choose
   an exact `workspace_id`; never pick from row order.
2. Call `list_pending_actions` and the relevant detail read:
   - `get_onsite_change` for a before/after page diff.
   - `get_content_draft` for the full body, evidence validation and publication state.
   - `list_tracked_prompts` for the buyer question and model evidence behind new work.
3. Summarize the target, current status, evidence, proposed change, expected operational effect,
   connected publication path, limits and revertability. Do not promise ranking, traffic, citation
   or revenue uplift.
4. Ask the human to approve that exact resource and action. Do not infer approval from an earlier
   request, silence, a general goal, or approval of a different version.
5. Only after specific approval, call the shipping tool with the JSON boolean
   `user_confirmed: true`. Never pass `"yes"`, `1`, a phrase or a fabricated confirmation.
6. Interpret and report the receipt. Treat `applying`, `publishing`, `reverting` and
   `awaiting_verification` as incomplete states, not success.
7. Stop on a cap, role, scope, plan, evidence, billing, audit or unavailable error. Do not loop a
   write or blindly retry an ambiguous external operation.

Read [references/workflow.md](references/workflow.md) for the exact tool-by-tool sequences.
Read [references/receipts.md](references/receipts.md) before interpreting a write result.

## Hard safety boundary

- Never use an Eli machine surface to send a pitch, review request, directory submission, social
  post, placement request or any other third-party outreach. Those final sends stay human dashboard
  actions forever.
- Never try to enable `autopilot` or `autopilot_publish`; no MCP or API operation may change them.
- Never bypass a confirmation, cap, audit failure, plan refusal, role refusal or scope refusal.
- Never treat a scan, domain string, API header or content URL as ownership proof.
- Never expose access tokens, API keys, connector credentials or full private workspace data.
- Never report a requested write as shipped unless the receipt has a terminal verified status.
- Never conflate CRM-verified revenue, buyer-attributed context and directional visit telemetry.

## Draft-only work

Use `prepare_onsite_proposal` when the user asks Eli to prepare a new supported page change. This
creates reviewable work and does not change the website. Show the resulting proposal before any
approval tool. Explicitly ask before dismissing work even when the dismiss tool itself does not
require the shipping-confirm parameter.

## Weekly review

Read [references/weekly-review.md](references/weekly-review.md) and produce a short evidence-led
review: what moved, which buyer questions remain unwon, what work is pending, and which single
action deserves review first. Keep “not enough data” as unavailable; never turn missing evidence
into a zero.

## REST v2

Use scoped API keys only in secure server-side or local-secret storage. Read
[references/api.md](references/api.md) for endpoints, headers, body shapes and scope rules.