Prepare and send email with Resend by checking whether the sender domain is verified, testing the message with Resend test addresses, and confirming the full recipient and message details before sending to real inboxes. It also supports scheduled and batch sends.
Send email through Resend without surprising anyone — check the sending domain first, prove the message on Resend's test addresses, and get the user's confirmation before mail goes to a real inbox. Use when the user asks to send, schedule, or batch-send an email, test a template, or wire Resend sending into a codebase.
Run score Not tested
See how to installBefore sending with Resend, this skill checks whether the sender's domain is verified and ready. It first sends the same message to Resend test addresses and checks the delivery result. Before sending to real recipients, it presents the sender, recipients, CC, BCC, subject, and body for confirmation, and sets an idempotency key to prevent duplicate sends. It also supports scheduled messages and batch sends that keep recipients from seeing one another. If asked to add sending to an app, it extends the existing Resend sending path.
Use it to test an email template, schedule an individual message, or send to multiple people. It can also help add Resend email sending to an existing app. The confirmation step lets the user review the content and recipients before sending, while the idempotency key helps prevent duplicates after retries.
A clear confirmation from the user is required before every send to real recipients. Keep the API key in an environment variable; do not put it in the repository, client-side code, or logs. Send from the server.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 30, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Every other Resend call can be run again. send-email and send-batch-emails
put mail in someone's inbox, and nothing undoes that. Treat the send as the last
step of a short checklist.
The from address must be on a domain the account has verified for sending.
Run list-domains and find the domain of the from address:
verified: send.pending, not_started, failed, or partly verified: do not send. Run
get-domain and show the user the DNS records that are not verified yet.onboarding@resend.dev sends without a domain, but only to the account
owner's own address. It is for a first test, not for real recipients.
Before a real recipient, send the same message to Resend's test addresses.
Remove cc and bcc, and put only test addresses in to. A real address in
any recipient field gets the test email before the user confirms in step 3.
delivered@resend.dev: delivered. Add a label for each case, for example
delivered+welcome@resend.dev.bounced@resend.dev: a hard bounce.complained@resend.dev: delivered, then marked as spam.suppressed@resend.dev: suppressed as an address that bounced before.Then run get-email on the result. Its status is the truth: sent means
Resend accepted the message, delivered means the receiving server accepted
it.
Show the user the from, to, cc, bcc, subject, and body, and wait for a
clear yes. Get this confirmation every time. Approval for an earlier send does
not cover this one.
idempotencyKey (for example welcome/<user-id>), so a retry after a
timeout cannot send the message twice.scheduledAt. cancel-email can stop a scheduled email
until it is sent, and not after.send-batch-emails, at most 100 per call), or a broadcast. It is not one
email with a long to list.When the user wants their application to send mail, read how the codebase already calls Resend and extend that path. The API key comes from the environment and never goes in the repo, a client bundle, or a log line. Send from the server only.
delivered@resend.dev until the message is
right.sent as delivered. sent only means that Resend accepted it.from domain so the send works. The user picks the sender,
not the agent.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review how you use Superset and identify unused features that fit your workflow. Get a short list of suggestions, learn about each option, and set up selected features such as scheduled agents, parallel workspaces, or shared tasks.
Set up recurring tasks in Superset with an agent prompt, a schedule or event trigger, and a chosen execution workspace. After explicit confirmation, create the automation, check its saved settings, and review a real first run.
Browse pages, click controls, fill fields, and inspect screenshots or console messages through Superset's browser pane. Use it to preview a running web app, check interface behavior, and work through browser tasks in a visible session.
Build Stripe payments, subscriptions, and invoicing using verified documentation and API parameter definitions. The skill guides product selection, sandbox testing, and webhook handling, where server notifications determine payment and subscription state.
Verify a UI change or reproduce a bug in the running desktop app using the Chrome DevTools Protocol (CDP), a browser debugging interface. Follow the real user journey and compare screenshots with measurements such as route, scroll position, and persisted state.
Diagnose failed GitHub Actions runs by finding the first meaningful error, separating code problems from infrastructure issues and intermittent failures, and comparing the base branch. Get a focused report explaining the PR’s involvement and recommended next steps.