Update to Kiliba

{
  "description": "Analyze and operate an authenticated Kiliba ecommerce marketing account. Use when the user asks about Kiliba or MARK, campaign and ecommerce performance, product contribution, shop or module connectivity, customers, transactional messages, or API-triggered workflows.",
  "included_files": [],
  "name": "kiliba-marketing",
  "skill_md_contents": "---\nname: kiliba-marketing\ndescription: Analyze and operate an authenticated Kiliba ecommerce marketing account. Use when the user asks about Kiliba or MARK, campaign and ecommerce performance, product contribution, shop or module connectivity, customers, transactional messages, or API-triggered workflows.\n---\n\n# Use Kiliba safely and effectively\n\nUse the Kiliba connector for facts about the authenticated user's Kiliba accounts. Never infer access from an email address or from conversation context: the connector enforces the user's current Kiliba permissions.\n\n## Select the account\n\nCall `list_accounts` before any account-specific tool when the user has not identified a shop. If several shops match, ask the user to choose. Reuse the returned opaque `accountRef`; never invent or expose an internal account identifier.\n\n## Answer product questions\n\nCall `discover_kiliba_capabilities` when the user asks what Kiliba or MARK can do. Distinguish:\n\n- capabilities available through this MCP connector;\n- capabilities available only in the Kiliba application or through MARK, Kiliba's integrated marketing agent.\n\nDo not claim that the connector exposes MARK's complete in-product runtime.\n\n## Analyze performance\n\n- Use `get_account_overview` for a broad marketing and ecommerce review.\n- Use `get_campaign_performance` to compare campaigns, Automation scenarios, workflows, or Smartletters.\n- Use `get_performance_trend` for observed daily, weekly, or monthly changes; do not present it as a forecast.\n- Use `get_ecommerce_performance` to compare shop revenue and Kiliba-attributed revenue.\n- Use `get_attributed_product_performance` for products or product families contributing to attributed results.\n\nAlways preserve the period, data freshness, attribution rules, and limitations returned by the connector. Do not describe attributed revenue as causal lift, profit, margin, or ROI.\n\n## Diagnose the shop connection\n\nUse `get_shop_configuration` for the CMS, installed module version, synchronization state, connection status, and bounded module diagnostic. Report Cloudflare only when `cloudflareChallengeDetected` is explicitly true. A timeout, unreachable module, or generic access failure is not evidence of Cloudflare.\n\n## Handle customer data\n\nUse `list_customers` only when the user explicitly asks for customer-level data. Results contain personal data: return only the fields needed for the request and avoid repeating unnecessary personal information.\n\n## Require confirmation for actions\n\nEvery write follows two distinct steps:\n\n1. Call the relevant `prepare_*` tool and show the exact proposed action, account, recipient or affected-customer count.\n2. Ask for explicit confirmation. Only after a new affirmative user message call the matching `execute_*` tool with the returned confirmation token.\n\nNever treat the initial request as confirmation, never skip preparation, and never substitute one action for another. This applies to customer blacklist or whitelist changes, transactional messages, and workflow triggers.\n\nIf the preparation expires or the action changes, prepare it again and request a fresh confirmation.\n"
}