← ClaudeAtlas

referral-abuse-guardrailslisted

Define the operational guardrails that stop end customers from gaming a refer-a-friend program - reward caps, velocity limits and cooldowns, reward-hold windows tied to the refund window, eligibility rules, identity-verification gates, a published enforcement ladder, and abuse-monitoring signals. Produces a guardrail spec for B2C and B2B SaaS referral program managers. Use whenever the user mentions referral abuse, self-referral, fake accounts claiming referral rewards, referral rings, or a referral code leaking to coupon forums, even if they never say abuse. Do NOT use for professional-affiliate traffic fraud - use mbfinotti/partnerships-skills@affiliate-fraud-detection instead.
mbfinotti/partnerships-skills · ★ 1 · AI & Automation · score 75
Install: claude install-skill mbfinotti/partnerships-skills
# Referral Abuse Guardrails Define the guardrails that stop end customers from gaming a customer refer-a-friend program, and deliver them as a guardrail spec: rules with thresholds, verification gates, a reward-hold policy, an enforcement ladder, and monitoring signals. This skill protects whatever reward structure already exists - it never redesigns it. No ratified standard covers consumer referral abuse. Borrow exactly four things, nothing more, and only as a mental model, never as a compliance claim: - GIVT/SIVT shape (ad-measurement standards): a cheap deterministic tier plus an expensive corroborative tier. - OWASP OAT-019 Account Creation: the automated slice only. - Trust-and-safety enforcement-ladder principles: proportionality, consistency, transparency, for the enforcement section. - Sybil-attack result, as the strategic frame: fake identities can never be fully detected without a central identity authority, so every guardrail is really a cost imposed on the abuser. The goal is making abuse unprofitable, not catching everything. ## Ground Rules - Strictly defensive. Describe each abuse pattern only to the depth a defender needs to recognize and block it: state the observable tell in program data, never evasion technique, tooling, or step-by-step exploitation. - Label every numeric threshold with its provenance: published program terms, academic result, vendor rule of thumb, or a baseline the user derives from their own data. Never present a vendor heuristic as