sheleg-dev

Shape: static. Each integration is a fixed sequence of seams; nothing decides its own next step.

stripe-billing

Use when connecting a product to Stripe, fixing a payment bug ( ), or auditing a live integration: checkout, renewals, seats, proration, refunds, cancellation and the cancel-step coupon, the portal, and the webhook that turns a payment into an entitlement. Covers Stripe's agent toolchain, the pinned API version, SDK retries, price resolution, claim-first webhook idempotency, what billing_reason decides, cumulative refunds, the cancellation field flexible billing_mode moved, retention eligibility Stripe cannot express, and write ordering with compensating reverts. Not for choosing between Stripe products (stripe-best-practices) or reading Stripe docs (stripe-docs).

crypto-payments

Use when adding or auditing crypto checkout, crypto top-up, or payment webhooks — where a payer sends the wrong amount, a webhook arrives more than once, and the rate moves between quote and transfer. Covers invoice lifecycle and status mapping, webhook signature verification and the JSON-escaping trap, idempotent processing, IP allowlisting behind a proxy, CSRF exemption for callback routes, the conversion buffer, reconciliation fields, credit waterfalls, refund and AML-hold states, local development with a tunnel and signed mock callbacks, a test matrix and a security checklist. Not for card billing — use stripe-billing.

error-tracking

Use when wiring error tracking into a product — adding Sentry to a service, deciding what a DSN is and where it may live, keeping secrets out of events before they reach a third party, tying releases to commits so a stack trace names the change that caused it, or judging whether a green health check means anything. Covers the Sentry SDK options that matter for a backend, the two different tools both called sentry, the auth-token taxonomy and which kind can create a project, and the MCP server with the config channel it belongs in. NOT for judging an agent's trajectory (agent-evals), triaging tickets in a tracker (your tracker's own triage skill), or choosing an uptime vendor.

ad-tracking

Use when setting up or modifying ad pixel integration, conversion tracking, consent management, purchase event tracking, retargeting audiences, or auditing an existing advertising analytics stack. Covers Google Analytics 4, Google Ads, Meta (Facebook) Pixel and LinkedIn Insight Tag in web applications: Consent Mode v2, standard events, e-commerce tracking, advanced matching, Enhanced Conversions, CSP configuration, user identification, cross-device tracking, and GDPR/DMA compliance. Not for running the ad campaigns themselves.

google-signin

Use when implementing, reviewing or debugging Google login / sign-in / sign-up on a website — wiring the GIS button or One Tap, verifying Google ID tokens on the server, linking Google to existing password accounts, or fixing. Covers GCP OAuth client setup, backend ID-token verification, three-way account linking with the pre- hijacking guard, login-CSRF defense, nonce/replay protection and a mandatory security checklist. For the broader library surface use google-auth instead.

google-auth

Use when a server authenticates to Google in a Node.js or Python application — OAuth 2.0 flows, verifying Google ID tokens server-side, service account authentication and keys, Application Default Credentials, Workload Identity Federation, API keys, or working with google-auth-library (Node.js) or google-auth (Python). Covers server-side ID token verification and security best practices. For end-user web sign-in only, use the google-signin skill instead.

frontend-performance

Use when building or auditing web pages for performance — running PageSpeed Insights, optimizing Lighthouse scores, fixing render-blocking resources, reducing bundle size, improving load times, or diagnosing slow page rendering. Covers Core Web Vitals (LCP, INP, CLS) and the Lighthouse diagnostics beside them (FCP, TBT, Speed Index), font loading strategies, CSS animation compositing, JavaScript bundle optimization, cache headers, code splitting, Content Security Policy, image optimization, and the contrast and heading issues that move a Lighthouse score. Not for visual design or conversion work.

/sheleg-dev — what it runs on to charge, track and sign in

• when: money, tracking, errors, sign-in or speed is being wired
• decline it: no wiring

If sheleg-dev is installed, WIRING integrations goes through it — cards (stripe-billing), crypto (crypto-payments), pixels/server events (ad-tracking), errors (error-tracking), sign-in (google-signin, google-auth), speed (frontend-performance). The webhook proves payment; the redirect only a browser. Share one event_id across both event channels or count revenue twice.

The boundary. NOT through it: paywall behavior/tiers (super-ux), checkout look (sheleg-design), words (copywriting), price (a business decision, never a skill's).

Refusal phrase: "no wiring" or «без обвязки» — avoid «без интеграций»: интеграция triggers task-pipeline.

Among the routers: super-ux owns the payment step; sheleg-dev its charge.