--- name: eli-aeo description: Review Eli AI-search evidence and safely operate an Eli workspace through MCP or REST v2. Use when a user asks an assistant to inspect monitoring, find the next improvement, configure tracked questions, competitors or pages, prepare content, review or execute approved own-site work, manage off-site drafts, 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 `get_machine_capabilities` when the user wants to configure or operate Eli. Use its exact operation name and input contract. Never guess an operation or pass a workspace ID inside the operation input. Call `get_growth_control_tower` when the user asks what Eli should do to grow, what the agents selected, why it was selected, or how to run the selected intervention through a GTM stack. Follow the returned `operation.mcp` route and preserve the normal preview, approval, receipt, verification and rollback rules. 3. When the user asks what to do next, for the highest-priority action, or to fix the most important issue, call `get_next_action`. Show its `plainLanguageAnswer` briefly. Use `list_pending_actions` only when they ask for the whole queue. If no action is ready and the user asked Eli to find, prepare, or fix today's best opportunity, call the returned `prepare_highest_priority_onsite_change` tool immediately. This creates a draft only. Follow the returned exact tool arguments. Call `get_learning_state` when the user asks what Eli has learned, whether its choices improve, or which measured outcomes support the current strategy. Treat a shadow policy as unproven. 4. Call the returned preview tool without `user_confirmed`. This call must return `confirmation_required`, the complete execution preview and a `preview_hash`; it must not mutate anything. The optional detail reads are: - `get_onsite_change` for a before/after page diff. - `get_content_draft` for the full body, evidence validation and publication state. - `get_correction` for the complete factual correction and evidence. - `list_tracked_prompts` for the buyer question and model evidence behind new work. 5. Lead with one plain sentence: what to fix first and why. Then summarize the target, current status, evidence, proposed change, exact publication provider and destination pattern, intended buyer and AI-search outcome, connected publication path, limits and revertability. Explain that Eli will verify the live URL and remeasure the same buyer question. Do not promise ranking, traffic, citation, customers, or revenue uplift. 6. Ask the human to approve that exact resource, destination and action. Do not infer approval from an earlier request, silence, a general goal, or approval of a different version. 7. Only after specific approval, call the shipping tool with the JSON boolean `user_confirmed: true` and `confirmed_preview_hash` copied exactly from the preview response. Never pass `"yes"`, `1`, a phrase, a fabricated confirmation or a hash from another resource. 8. Interpret and report the receipt. Preserve `receipt_id`, provider, mode, URL and audit ID. Treat `applying`, `publishing`, `reverting` and `awaiting_verification` as incomplete states, not success. 9. 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. - The weekly progress email may be turned on or off through `settings.set_weekly_digest` after exact approval. Never try to enable `autopilot_publish` or grant publication autonomy. - 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. ## Workspace operations Use `run_workspace_operation` for the allowlisted operations returned by `get_machine_capabilities`. The first call is a preview only. Show the operation name, exact input, effect and workspace to the user. After explicit approval, repeat the call with literal `user_confirmed: true` and the exact returned `confirmed_preview_hash`. The underlying dashboard route rechecks the signed-in user, owner or admin role, workspace, subscription, feature access, ownership rules and plan limits. A third-party status action can approve a draft or record that a human or another system sent it. Eli itself never sends that message. Connection credentials, API-key creation and billing stay on secure signed-in API pages. ## 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.