Cello

View saved version →

---
name: cello-get-integration-guide
description: Generate a tailored, step-by-step guide for integrating Cello (referral/attribution tracking) into a specific application. Use this whenever a developer says they want to "integrate Cello," "add Cello to my app," "set up referral tracking," or "add attribution tracking," especially when they haven't integrated it yet or are starting from scratch. Also trigger if someone asks "how do I add Cello to [React/Next.js/Rails/etc]" or pastes their codebase/repo and asks for an integration plan. This analyzes the actual app (frontend framework, mobile vs. web, payment gateway, signup flow) before generating the guide — it does not just paste the generic docs. Do not use this for debugging an *existing* integration (use cello-integration-health-check for that instead).
compatibility: Requires the Cello MCP server (cello_search_documentation, and ideally cello_get_integration_status for the final verification step). Works best with read access to the target codebase (package.json, requirements.txt, webhook handlers, etc.) so the stack can be detected automatically instead of asked about.
---

# Cello Integration Guide Generator

Produces a step-by-step Cello integration plan customized to the app you're actually integrating into — not a copy of the generic docs. The generic path (docs.cello.so/integration-overview) has 4 steps that apply to everyone, but steps 2 and 4 branch hard depending on the app's stack, and most of the actual work is picking the right branch.

## Step 1: Analyze the app

Before writing any guide, figure out:

1. **Platform**: Web app, mobile app (iOS/Android/React Native), or both?
2. **Frontend framework**: Plain JS/HTML, React, Vue, Angular, Next.js, etc. (Cello's referral component is a script tag + JS API, so it works with all of these — but the mount pattern differs, e.g. SPA re-render timing matters for custom launchers.)
3. **Signup flow**: Does the user sign up on a web form the app controls, via a form tool (HubSpot, Typeform), or via mobile?
4. **Payment/billing system**: Stripe, Chargebee, or something else (custom billing, Paddle, etc.)? And critically: is the gateway customer object created at signup, or only later at purchase/checkout? This timing question — not just "which gateway" — is what actually determines the step 4 path (see Step 2 below), so don't skip it even if Stripe/Chargebee is confirmed.
5. **Auth/user identity**: Where does a stable user ID (or email) live at signup time, that can be attached to Cello as the `ucc` (unique customer code) reference?
6. **Buying persona — user or organization?**: Does the app have organizations/teams/workspaces, and does the *purchase* happen at the org level rather than the individual level (e.g. a workspace admin pays for the whole team)? This determines whether attribution needs to run on the user or the organization, which changes what ID gets passed at several points — don't skip this even for straightforward B2B SaaS apps, since it's easy to assume user-level by default when the actual buyer is the org.
7. **New user discount wanted?**: Does the app want to offer referred users a discount at signup/checkout? This is optional and separate from the core 4 steps — ask if unclear rather than assuming yes or no.

**How to gather this:**
- If you have codebase access: check `package.json`/`requirements.txt`/`Gemfile` for frontend framework and payment SDKs (`stripe`, `chargebee`), grep for webhook handler routes, check for existing auth/session code.
- If you don't have codebase access, or something's ambiguous (e.g. multiple payment integrations found, or none): ask the developer directly rather than guessing. Getting the payment gateway wrong wastes their whole step 4.

## Step 2: Map findings to the 4 setup steps

Use `cello_search_documentation` to pull the exact, current content for each — don't rely on memory, since Cello's docs and snippets change. Map based on what Step 1 found:

| Setup step | Br

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: cello-get-program-performance
description: Analyze Cello's referral program health, trends, industry benchmarks, prioritized recommendations, and top-performing referrers into one performance readout. Use this whenever someone asks how their referral program is doing, wants a performance summary, asks "how are we trending," "how do we compare to industry," "what should we improve," "who are our top referrers," or wants a recurring digest (weekly/monthly) of program health. Also trigger for questions like "why did signups drop" or "are we above/below benchmark" — this pulls metrics, recommendations, and top referrers together rather than answering from any single tool alone. Do not use this for integration/technical debugging (use cello-integration-health-check) or for a deep fraud/anomaly investigation into a specific referrer (this skill flags an obviously odd top-referrer ratio in passing, but a dedicated referrer-analysis skill should do the actual investigation).
compatibility: Requires the Cello MCP server (cello_get_program_metrics, cello_get_recommendations, and cello_get_top_referrers tools).
---

# Get Program Performance

Turns raw metrics and recommendation data into a readout that actually says something — not just a table of numbers. The core value-add is connecting the two: a metrics dip is more useful paired with the specific recommendation that addresses it, and a recommendation is more convincing paired with the number it would move.

## Workflow

1. **Call `cello_get_program_metrics`.** This returns lifetime totals, weekly/monthly history, and industry benchmarks in one call.

2. **Call `cello_get_top_referrers`.** This returns the top 10 referrers ranked by revenue, with signups, recurring purchases, ARR, days active, and days sharing per referrer.

3. **Call `cello_get_recommendations`.** This returns a prioritized (impact-weighted) list of improvement actions and their completion status.

4. **Connect them — this is the actual analysis, not just reporting each tool's output separately:**
   - Identify the most significant trend(s) in the metrics: compare last-30d vs. prior-30d across referrers enabled, active referrers, sharing activity, signups, and recurring purchases. Note when a headline number (e.g. ARR) is moving opposite to the underlying activity metrics — lagging revenue recognition can mask a cooling funnel, and that gap is often the most important thing to surface, not the ARR figure alone.
   - Check each metric against its industry benchmark where available. Being above benchmark doesn't mean "nothing to improve" — say so if the trend is declining even while still above benchmark, since trajectory matters as much as the snapshot.
   - Cross-reference declining metrics against the recommendation list: does an unfinished recommendation directly address the metric that's slipping? If so, lead with that pairing — it's the most actionable insight in the whole readout ("sharing is down 10% and 3 of 3 Sharing-category recommendations are still open").
   - Note top completed vs. incomplete recommendations by impact weight, so the highest-leverage open item is never buried.
   - From the top referrers list, note whether a small number of referrers account for a disproportionate share of revenue/signups (concentration risk for the program, independent of any individual fraud question) — this matters for performance framing even without flagging fraud specifically.
   - While reviewing top referrers, do a light plausibility check on the ratio of `daysActive` to `daysSharing` versus signup volume — a referrer with very few sharing days but outsized signups is worth one flagged line (not a full writeup) since it's the kind of thing worth a closer look. Keep this brief: name the referrer and the specific ratio, then suggest a dedicated referrer/fraud-analysis pass if one is available, rather than investigating further here — that's a different skill's job.

## Output format

Keep it to a short re

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: cello-integration-health-check
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.
compatibility: 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.
---
 
# Cello Integration Health Check
 
A diagnostic skill that turns a raw Cello integration status check into a clear, actionable report a developer can act on without leaving their editor.
 
## When to use this
 
Use 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.
 
## Workflow
 
1. **Call `cello_get_integration_status`** first. This checks all four integration components in one shot:
   - Referral Widget (cello.js)
   - Attribution Widget (cello-attribution.js)
   - Signup tracking
   - Purchase tracking
2. **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.
3. **Cross-reference the two.** For each component that isn't fully healthy:
   - Check the events feed for related event types (signup, purchase/invoice, attribution) with `status: error` or `issuesCount > 0`.
   - If you find matching errors, name the specific missing/invalid field(s) — don't just say "there's an issue."
   - 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.
4. **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.
## Output format
 
Keep it scannable — a developer is context-switching from their code, not reading a report. Structure as:
 
```
## Integration Health: [X/4 healthy]
 
### ⚠️ [Component name]
**What's happening:** [plain-language diagnosis]
**Likely cause:** [root cause if found in events feed, otherwise "no recent activity" vs "broken" distinction]
**Fix:** [specific action + doc link]
 
### ✅ [Component name]
Working correctly, no issues.
```
 
If 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.
 
## Edge cases
 
- **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.
- **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 p

Preview of the first 4,000 characters. Read full instructions →