Update to Adzviser

{
  "description": "Retrieve and analyze model-visible, row-level marketing or sales data with Adzviser. Use when the user asks for Data Mode, reporting_mode=data, raw rows, an audit, calculations, comparisons, trends, insights, optimization recommendations, or any answer that requires ChatGPT to inspect the underlying numbers. Do not use when the user explicitly wants only the interactive Preview UI.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 242
    }
  ],
  "name": "adzviser-data-mode",
  "skill_md_contents": "---\nname: adzviser-data-mode\ndescription: Retrieve and analyze model-visible, row-level marketing or sales data with Adzviser. Use when the user asks for Data Mode, reporting_mode=data, raw rows, an audit, calculations, comparisons, trends, insights, optimization recommendations, or any answer that requires ChatGPT to inspect the underlying numbers. Do not use when the user explicitly wants only the interactive Preview UI.\n---\n\n# Adzviser Data Mode\n\nUse Adzviser as the source of truth for connected marketing and sales data. Retrieve the actual rows, inspect them, and answer the user's question with evidence from those rows.\n\n## Reporting scope\n\nUse the source-specific discovery tools to choose fields and request keys. The all-in-one connection supports multiple sources in one request; include only the sources the user requested.\n\nThe plugin retrieves reports and manages their preview. It cannot change advertising budgets or bids, publish ads, delete analytics data, modify store orders, or issue refunds. Explain these limits when asked for those actions; do not call reporting tools as a substitute or claim a change occurred.\n\n## Route to the data tool\n\n- Call `retrieve_reporting_data` for this workflow.\n- Never call `preview_and_retrieve_reporting_data` for Data Mode. That tool is bound to an iframe and will render the embedded report instead of serving as the raw-data path.\n- Treat `reporting_mode=data` as user intent that selects `retrieve_reporting_data`; it is not an argument to send.\n- Never send `client_id`, `reporting_mode`, or `_widget_action`. They are internal compatibility fields, not model inputs.\n- If a user asks for both analysis and an interactive report, retrieve and analyze the rows first. Open Preview UI afterward only if the user explicitly requested that additional deliverable.\n\n## Follow the reporting workflow\n\n1. Interpret the question and identify the requested data sources, measures, dimensions, time window, and comparison periods. Ask one concise question only when a missing choice would materially change the report.\n2. Resolve relative dates from the current date available to ChatGPT. Pass inclusive `[start_date, end_date]` pairs in `YYYY-MM-DD` format. Never reuse a fixed date from an example or an older conversation.\n3. Call `list_workspace`. Use a user-named workspace when it exists. Otherwise auto-select only when one workspace unambiguously contains every requested connected source; ask when multiple candidates remain.\n4. For every requested source, call its `list_metrics_and_breakdowns_*` tool. Use the exact returned field names. Do not guess close variants.\n5. Build one `adzviser_request` with:\n   - `workspace_name`, except for a documented source that does not require it;\n   - `date_ranges` containing every requested period;\n   - optional `time_granularity` when the user requests a time series;\n   - `assorted_requests` as an object keyed by source request name, such as `google_ads_request` or `fb_ads_request`.\n6. Call `retrieve_reporting_data` once with `{ \"adzviser_request\": ... }`.\n7. Inspect all data sources, date-range segments, headers, rows, and `note_of_assumption` values in `structuredContent.reportingData`. Use the text/CSV content only as a fallback when structured content is absent.\n8. Answer with the requested numbers first, then material patterns and practical recommendations supported by the data. State the workspace, sources, and exact date ranges used when they help the user verify the result.\n\n## Compose valid requests\n\n- `assorted_requests` must be an object, never an array.\n- Include only requested sources. Do not add empty source requests.\n- Each ordinary source request must contain `metrics`; include `breakdowns` only when useful.\n- Keep at least one requested metric or breakdown for every included source.\n- Do not put Date, Week, Month, Quarter, or Year in `breakdowns`; use `time_granularity` instead.\n- Use multiple date-range pairs in one call when the user asks for several periods, including overlapping windows such as the last 30, 14, and 7 days.\n- Adzviser does not apply arbitrary report filters. Retrieve the fields needed to identify rows, then filter or calculate from the returned data.\n\nExample shape:\n\n```json\n{\n  \"adzviser_request\": {\n    \"workspace_name\": \"Workspace Name\",\n    \"date_ranges\": [[\"2026-08-01\", \"2026-08-20\"]],\n    \"time_granularity\": \"Date\",\n    \"assorted_requests\": {\n      \"google_ads_request\": {\n        \"metrics\": [\"Cost\", \"Clicks\"],\n        \"breakdowns\": [\"Campaign Name\"]\n      }\n    }\n  }\n}\n```\n\nThe field labels above illustrate structure only. Always obtain valid labels from the corresponding discovery tool.\n\n## Respect ChatGPT's result boundaries\n\n- `structuredContent` is model-visible and is the preferred basis for analysis. Do not claim the rows are inaccessible when they are present there.\n- `_meta` is hidden from the model. Never depend on it for analysis or describe it as returned report data.\n- Do not call the preview tool after a successful retrieval merely to display the same request.\n- Do not repeat an identical retrieval because a widget or follow-up message appears. Reuse model-visible rows already present in the conversation.\n- If a response contains headers but no data rows, report that no rows were returned for the requested fields and period. Do not infer zero spend or activity, silently switch modes, or invent values.\n- If a field or request is rejected, refresh the relevant discovery tool output, correct the request once, and retry. Do not work around schema errors by adding internal parameters.\n\n## Produce a useful analysis\n\n- Distinguish facts in the rows from interpretations and recommendations.\n- For audits, check totals and the requested entity-level breakdowns before recommending changes.\n- For comparisons, calculate both absolute and percentage changes when denominators are valid; flag zero or missing baselines.\n- Preserve units and currency as returned. Do not assume currencies match across accounts or sources.\n- Mention assumptions supplied by Adzviser and any material limitations such as missing rows, partial periods, or unavailable fields.\n\n## Keep simple reports simple\n\n- For a total over a period, omit time_granularity and unnecessary breakdowns. Do not sum daily active users or other non-additive metrics to manufacture a period total.\n- Interpret last month as the previous complete calendar month. If the user supplies no different week definition, use the previous complete Monday-Sunday week for last week and state the dates used.\n- For Google Ads spend, discover `Cost` and use the returned account currency. Respect normalized output headers; do not divide returned spend by one million again.\n- For GA4 active users, discover `Active users`; do not silently replace it with Sessions, Total users or a rolling active-user metric.\n- Meta Ads has multiple conversion definitions. For purchase conversions, use `Total Purchases` and label that definition. For an unspecified conversion request, use the user's established definition or clarify instead of guessing.\n- Keep separate campaign IDs when names repeat. A campaign name mentioning a different optimization event does not change the metric requested.\n- Do not request customer names, emails or order-level identifiers for aggregate reports when counts alone answer the question.\n"
}