Update to Dathent

{
  "description": "Show Dathent brand statistics, views, engagement, platform comparisons, trends, and top posts in the Performance widget. Use for analytics questions and focused post-performance drill-downs, not scheduling or media uploads.",
  "included_files": [],
  "name": "performance",
  "skill_md_contents": "---\nname: performance\ndescription: Show Dathent brand statistics, views, engagement, platform comparisons, trends, and top posts in the Performance widget. Use for analytics questions and focused post-performance drill-downs, not scheduling or media uploads.\n---\n\n# Explain performance with one useful view\n\nRespond in the user's language. For a brand statistics request, call `get_post_performance` first with `window: 30` unless another lookback period was requested (supported range: 1–365 days). Omit `brandProfileId` for the active brand. Resolve a different or genuinely unclear brand with `list_brands`; do not rediscover a brand already selected.\n\nThe returned Performance widget already contains totals, trends, platform breakdowns, and top posts. Give a short interpretation of those results. Do not also load profile, connected accounts, usage limits, calendar, or post galleries for a statistics-only request unless a requested detail actually requires them. Do not sum a paginated post list to invent brand totals.\n\nWhen the user asks for a larger view, interactive comparison or sustained work\nwith charts, use `open_workspace` with `view: \"performance\"` instead of opening\nanother set of widgets. Its range and platform controls use the same measured\ndata. Do not call both entry views for one request; an already-open panel can\ncontinue the interaction.\n\n## Interpret the measurements accurately\n\n- Keep views, reach, impressions, interactions, and engagement rate distinct. Engagement rate uses measured interactions with reach or impressions as its denominator, not views. Prefer the returned rate and coverage rather than recomputing from mismatched aggregates.\n- Missing or unavailable metrics are not measured zero. Do not conclude that content failed, that a network has no engagement, or that totals are complete when coverage is partial. Mention a material limitation briefly; put detailed methodology behind a focused explanation when asked.\n- Preserve the result's period, units, and aggregation. Lifetime observations grouped by publication date are not necessarily views earned on each chart day. Published platform targets and unique content items are different counts; label the returned measure correctly.\n- If the result includes an actionable account notice, such as a statistics-permission reconnection, explain that notice and use its returned link. Do not initiate unrelated account changes or claim a refresh/reconnection succeeded without evidence.\n\n## Drill down only when useful\n\nFor one known post, call `get_post` with its `contentItemId`; it includes saved metrics and the post card. If its ID is unknown, use `list_posts` to find it. For publications on a specific past date/range, use `list_scheduled` with `status: \"published\"` and explicit `from`/`to` boundaries in the intended timezone; those cards include saved metrics when available.\n\nUse returned post/publication links and explain their scope when several platform publications exist. Let the widget provide charts and interactive details instead of duplicating every number in prose. If data is unavailable, report the actual result and next available action; never fabricate estimates or republish content to obtain statistics.\n"
}