agentsclimarketplace

Instrumentation

Skill linkrunner-labs/skills/skills/events/instrumentation

Installable Agent Skills for integrating the Linkrunner SDK and deep linking, for AI coding agents (Claude Code, Cursor, Windsurf, Copilot)

Install
npx -y skills add linkrunner-labs/skills --skill instrumentation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 16 days oldThe repository was created 16 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Instrument Linkrunner event and revenue tracking correctly - what events to send, when to send them, and how to avoid double-counted, dropped, or missing revenue. Platform-agnostic: covers the event taxonomy, ad-network ecommerce fields, capturePayment/removePayment correctness, and the server-side Capture Event / Revenue Tracking HTTP APIs. Use when asked to instrument Linkrunner events, track purchases or revenue with Linkrunner, decide what events to send, debug why revenue or events are missing or double-counted, or send events from a backend/web app that has no client SDK call for custom events.

SKILL.md

5.2 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Linkrunner - Events & revenue instrumentation

You are instrumenting Linkrunner event and revenue tracking. This skill is the platform-agnostic layer: what to send, when to send it, and how to keep revenue correct. It does not give you client call syntax - each platform's SDK skill (skills/sdk/<platform>/references/events.md) owns the exact trackEvent / capturePayment / removePayment snippets for that language.

0. Before you touch anything

  1. Confirm signup() has already been wired for this app. Events and revenue are only stored and displayed for attributed users - a user must have been registered via .signup in an SDK before their events show up. If it isn't wired yet, stop and set that up first via the relevant skills/sdk/<platform>/ skill.
  2. Identify which SDK is installed (Flutter, React Native, Expo, iOS, Android, Capacitor, Cordova, Unity, Web) - or whether this is a backend/web flow with no client SDK in the loop. That decides whether you write client code or call the HTTP API.
  3. Ask what's actually being tracked: generic product/behavior events, ecommerce events meant to feed Meta Catalog Sales, revenue/payments, or server-side-only tracking (cron jobs, webhooks, web backend).
  4. If this is server-side work, get the server key (dashboard → Settings → Data APIs: https://dashboard.linkrunner.io/settings?s=data-apis). Never hardcode it - ask where the user keeps secrets.

1. Decide what the user actually needs

They want...Do this
"What events should I send" / "instrument Linkrunner events"references/ecommerce-events.md for the taxonomy, then the platform skill's events.md for exact call syntax
"Track purchases / revenue" / "revenue is wrong, missing, or double-counted"references/revenue.md
"Track events from my backend / web app / server"references/server-side.md (also the only path for the web SDK, which has no client trackEvent)
"AddToCart / ViewContent / Purchase not showing in Meta"references/ecommerce-events.md, then confirm the custom event is mapped to the standard commerce event in the dashboard (Meta Ads → Event Mapping)

2. Golden rules

  • Nothing shows up for an unattributed user. signup() (or .signup) must run before any event or payment call means anything.
  • Client-side custom events and payments always go through the per-platform SDK - defer syntax to skills/sdk/<platform>/references/events.md. Don't invent a generic snippet here.
  • For revenue, use capturePayment / the Capture Payment API, not trackEvent / Capture Event - the docs explicitly recommend capture-payment for revenue since it has dedup guarantees capture-event doesn't.
  • Always send amount as a number, never a string, when you want ad-network revenue sharing (Meta/Google) to work.
  • Meta Catalog Sales ecommerce events (AddToCart, ViewContent, Purchase) need specific event_data fields (content_ids, contents, content_type, value, currency, num_items, order_id) and the custom event name must be mapped to the standard commerce event in the Linkrunner dashboard before it will sync - sending the event alone isn't enough. See references/ecommerce-events.md.
  • Payment dedup key is the (type, payment_id) combination - always send a unique payment_id per transaction so re-sends dedupe instead of silently colliding. See references/revenue.md for the full failure mode.
  • The web SDK has no client trackEvent/capturePayment call today - custom event and revenue tracking from a web app goes through the server-side APIs in references/server-side.md.

3. Verify

  • Check the dashboard Events Settings page to confirm events are being captured.
  • To attribute a test user before events will show up, follow the Integration Testing guide.
  • For Meta ecommerce events, check Meta Events Manager / Commerce Manager - allow up to 15 minutes for real-time hits and up to an hour for full event visibility.

References

  • references/ecommerce-events.md - event taxonomy, Meta Catalog Sales fields, when to fire each event
  • references/revenue.md - capturePayment/removePayment correctness, dedup, refunds, double-counting
  • references/server-side.md - Capture Event / Revenue Tracking HTTP APIs for server-to-server and web tracking

Gives 0 of the 12 instructions most data backend skills give in ~1.1k tokens

Counted across 229 of the 229 authors here whose files we hold, read 2026-08-06

  • separate business logic into service layersin 22 of 229, across 15 files
  • select only needed database columnsin 20 of 229, across 13 files
  • retry failures with exponential backoffin 20 of 229, across 13 files
  • abstract data access into repository classesin 19 of 229, across 12 files
  • Use centralized error handlersin 17 of 229, across 10 files
  • Use AsNoTracking for read-only queriesin 16 of 229, across 4 files
  • Implement structured loggingin 15 of 229, across 4 files
  • Use async/await for all I/O operationsin 15 of 229, across 3 files
  • use resource-based URLs for REST APIsin 15 of 229, across 9 files
  • Use dependency injection for all servicesin 14 of 229, across 2 files
  • Invalidate cache on data updatesin 13 of 229, across 9 files
  • Use a dependency injection containerin 12 of 229, across 4 files

Said here and by no other author read

  • confirm signup is wired before any event tracking
  • identify which SDK or backend flow is installed
  • ask what types of events are being tracked
  • use the Capture Payment API for revenue tracking
  • send amount as a number for ad-network revenue sharing
  • send a unique payment_id per transaction

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.