AI referral program prompt template

Give a coding assistant a precise brief, repository inspection steps and failure cases. Get an implementation plan you can review before changing code.

01Make it yoursEditable asset

Editable implementation prompt

Replace the bracketed fields here, then copy. Edits stay in this page only and are lost when you leave or reload. No account required.

Help me implement a referral workflow in this repository.

CONTEXT
Product: [name and customer model]. Stack: [framework, auth, database, billing].
Program brief: [paste eligibility, attribution rule, both benefits, caps, qualification and refund policy].
Integration choice: [existing service and current docs OR custom implementation].

FIRST, INSPECT
Read repository instructions, schema, auth and billing handlers, tests and current integration documentation. Report the actual trust boundaries and existing behavior. Do not invent endpoints, fields, SDKs or capabilities. List missing product decisions before implementation.

PROPOSE
Map the journey: shared link → capture → authenticated identity → verified payment → qualification → reward record → delivery receipt.
Identify which system owns each step. Keep browser input untrusted and secrets on the server. Define stable identities for people/company accounts and business events. Show database constraints for duplicate prevention and tenant isolation. Separate a reward calculation from external delivery.

IMPLEMENT AFTER THE PLAN IS AGREED
Make the smallest complete change using the existing stack. Use a disposable environment and synthetic identities. Do not send real emails, issue real credits, charge money or deploy without explicit authorization.

ACCEPTANCE CASES
1. A valid new customer produces the expected attribution and benefits.
2. Duplicate and concurrent delivery of the same payment produces no duplicate benefit.
3. Out-of-order events cannot silently change the established relationship.
4. A forged amount, another tenant's ID and a self-referral are rejected or handled by the stated policy.
5. Refunds before and after delivery follow the agreed policy.
6. A failed external delivery can retry without duplicating successful delivery.
7. Logs and customer-facing errors contain no secrets.

HANDOFF
List files changed, tests actually run and their results, unsupported cases and required manual steps. Distinguish local checks from hosted acceptance. Never call an accounting row proof that a reward was delivered.

02Worked exampleIllustrative

Worked example: turn a vague request into a boundary

Replace 'build referrals for my SaaS' with 'Our customer is a company account. A trusted billing event establishes its first paid invoice. The member who shares a link acts for that company. Award one $20 company credit after the review period; a second coworker signup earns nothing. Inspect the existing billing handler and propose duplicate-event tests first.' The prompt now identifies the beneficiary, authoritative fact and a concrete failure case. It still needs the repository's real contracts before implementation.

03CustomizeYour policy

Attach the policy, not only a screenshot

A screenshot shows where the button goes. The brief explains who can earn value and why. Supply the actual program rules and provider documentation so the assistant can separate product decisions from implementation details.

Ask for evidence at each boundary

A tool connection can prove the assistant can read configuration. It does not prove that your app captures attribution, sends trusted events or delivers credits. Request a separate result for each part of the customer journey.

Keep a human release decision

Review generated code and its tests against the acceptance cases. An attractive demo is useful for feedback, but retries, authorization and reconciliation require deliberate checks. This prompt is tool-neutral; it is not a tested walkthrough of any particular coding assistant.

04Before you use itReview

Acceptance checklist

Every endpoint and field comes from the current repository or official documentation.
No production credential or customer data is pasted into the prompt.
The plan names the owner of reward delivery and the evidence of success.
The final report separates tests run from proposed tests.

Source notes

Stripe webhook delivery behavior — Duplicate and unordered provider events are concrete acceptance cases for payment-driven integrations.

Prepare the brief for your assistant →All templates