Update to Cello

{
  "description": "Diagnose whether a Cello referral/attribution integration is working correctly, right from the IDE. Use this whenever a developer asks if their Cello integration is set up correctly, why referral or attribution events aren't showing up, why signups or purchases aren't being attributed, or reports symptoms like \"referral widget isn't loading,\" \"attribution isn't tracking,\" \"UCC not found,\" or \"events aren't firing.\" Also trigger when someone is mid-integration and asks \"is this working?\", \"why isn't this tracking?\", or wants a pre-launch sanity check before shipping a Cello integration. Proactively suggest this skill if a developer pastes Cello SDK/webhook code and expresses uncertainty about whether it's correct.",
  "included_files": [],
  "name": "cello-integration-health-check",
  "skill_md_contents": "---\nname: cello-integration-health-check\ndescription: Diagnose whether a Cello referral/attribution integration is working correctly, right from the IDE. Use this whenever a developer asks if their Cello integration is set up correctly, why referral or attribution events aren't showing up, why signups or purchases aren't being attributed, or reports symptoms like \"referral widget isn't loading,\" \"attribution isn't tracking,\" \"UCC not found,\" or \"events aren't firing.\" Also trigger when someone is mid-integration and asks \"is this working?\", \"why isn't this tracking?\", or wants a pre-launch sanity check before shipping a Cello integration. Proactively suggest this skill if a developer pastes Cello SDK/webhook code and expresses uncertainty about whether it's correct.\ncompatibility: Requires the Cello MCP server (cello_get_integration_status and cello_get_events tools). If these tools are not available, tell the user to connect the Cello MCP server first.\n---\n \n# Cello Integration Health Check\n \nA diagnostic skill that turns a raw Cello integration status check into a clear, actionable report a developer can act on without leaving their editor.\n \n## When to use this\n \nUse this skill whenever someone wants to know if their Cello integration is healthy, or is debugging why referral tracking / attribution / signup / purchase events aren't showing up as expected. This is a \"help me right now, mid-debugging\" tool — it should feel fast and concrete, not like a dashboard export.\n \n## Workflow\n \n1. **Call `cello_get_integration_status`** first. This checks all four integration components in one shot:\n   - Referral Widget (cello.js)\n   - Attribution Widget (cello-attribution.js)\n   - Signup tracking\n   - Purchase tracking\n2. **Call `cello_get_events`** next, regardless of whether step 1 found problems. The events feed often explains *why* a component is flagged — e.g. a component can show \"connected with warnings\" because events are arriving but failing validation (missing required fields), which status alone won't reveal.\n3. **Cross-reference the two.** For each component that isn't fully healthy:\n   - Check the events feed for related event types (signup, purchase/invoice, attribution) with `status: error` or `issuesCount > 0`.\n   - If you find matching errors, name the specific missing/invalid field(s) — don't just say \"there's an issue.\"\n   - If no related errors appear in the events feed but the component is still flagged, it's likely a \"no recent activity\" warning rather than a broken integration — say so explicitly, since these read the same but mean different things to a developer mid-build.\n4. **If something is broken or missing, use `cello_search_documentation`** to pull the specific fix — don't send the developer to go search for it themselves. Surface the doc link inline with the specific action needed.\n## Output format\n \nKeep it scannable — a developer is context-switching from their code, not reading a report. Structure as:\n \n```\n## Integration Health: [X/4 healthy]\n \n### ⚠️ [Component name]\n**What's happening:** [plain-language diagnosis]\n**Likely cause:** [root cause if found in events feed, otherwise \"no recent activity\" vs \"broken\" distinction]\n**Fix:** [specific action + doc link]\n \n### ✅ [Component name]\nWorking correctly, no issues.\n```\n \nIf event errors are found, always name the exact field(s) involved (e.g. \"the `interval` field is missing from your `invoice-paid` payload\") — this is the single most useful detail for a dev fixing webhook code, and it's exactly what the raw event payload gives you.\n \n## Edge cases\n \n- **All components flagged, but events feed is empty or all-valid:** this usually means low/no recent traffic rather than a broken integration. Say this plainly — don't alarm the developer over a quiet period.\n- **Some events are errors but the affected component shows as healthy:** mention it anyway as a heads-up (e.g. a webhook occasionally sends bad payloads even if enough valid ones get through to pass the health check).\n- **Developer pastes SDK/webhook code and asks \"does this look right?\":** run the two tools anyway to check the *live* result rather than only reviewing the code — code can look correct and still be misconfigured (wrong UCC field name, wrong event name string, etc.), and the events feed is ground truth.\n- **No live signups yet if a fresh implementation is still local/staging:** clarify whether the developer expects a live event to have fired; if not, this isn't a bug and the skill should say that framing explicitly instead of reporting \"0 events\" as a failure.\n\n## Tone\n \nBe direct and specific. Developers debugging an integration want the diagnosis and the fix, not a course on Cello's architecture. Lead with what's broken (if anything), not with a summary of what the tool checked."
}