Workflow·Email

email-sdk

Use when adding, reviewing, or documenting Email SDK integrations in TypeScript/Bun apps: adapter selection, fallbacks, CLI smoke tests…

You say
Buy it · $99 Read it before you buy $99 Written by opencoredev · unverified publisher
Context cost
1.8k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 7.0 kBtext throughout, nothing executable
Licence
MITpaid listing
Last change
no release on file
Servers it uses
Noneruns standalone

What it does

Use when adding, reviewing, or documenting Email SDK integrations in TypeScript/Bun apps. Dynamically refreshes the current Email SDK docs/source before implementation, then covers adapter selection, fallbacks, CLI smoke tests, hooks, and secret-safe observability.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

emailsdktypescripttransactional
Filed under

Email

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md7.0 kB · 120 lines
--- name: email-sdk description: Use when adding, reviewing, or documenting Email SDK integrations in TypeScript/Bun apps. Dynamically refreshes the current Email SDK docs/source before implementation, then covers adapter selection, fallbacks, CLI smoke tests, hooks, and secret-safe observability. ---
6# Email SDK
7
8Use this skill when an agent works with this repository or wires @opencoredev/email-sdk into another TypeScript app.
9
10This skill is intentionally dynamic: do not treat the examples below as the full current API or template catalog. First refresh the local package docs/source for the installed version, then implement against what the repo, dependency, and current machine-readable documentation actually expose.
11
12## Refresh Current Docs
13
14Before changing code, inspect the most relevant current sources:
15
161. If you are inside this repo, read:
17 - README.md
18 - packages/email-sdk/README.md
19 - packages/email-sdk/package.json
20 - apps/fumadocs/content/docs/**/*.mdx
21 - packages/email-sdk/src/index.ts
22 - the specific adapter file in packages/email-sdk/src/<adapter>.ts
23 - packages/email-sdk/src/types.ts, core.ts, and errors.ts when message shape, routing, retries, hooks, or error handling matter.
242. If you are inside an app that has @opencoredev/email-sdk installed, inspect:
25 - the app lockfile and node_modules/@opencoredev/email-sdk/package.json
26 - node_modules/@opencoredev/email-sdk/README.md
27 - node_modules/@opencoredev/email-sdk/dist/*.d.ts
28 - the app's existing email, notification, queue, environment, and test patterns.
293. If local docs are missing or the task depends on version-sensitive behavior, fetch the current published package metadata/docs before implementing:
30 - bun pm view @opencoredev/email-sdk
31 - bun email-sdk version when the CLI is installed in the target app
32 - https://email-sdk.dev/docs/llms.txt to discover the current documentation tree
33 - the exact raw Markdown page at https://email-sdk.dev/docs/<path>.md
34 - the repository docs or package README for the exact version in use.
35
36Prefer the raw .md endpoints over scraping rendered HTML. They return Content-Type: text/markdown, preserve current internal links, and include the page title and canonical route.
37
38For React Email UI or template work:
39
401. Fetch https://email-sdk.dev/docs/ui.md first.
412. Follow its current category and template links instead of relying on a hard-coded template list.
423. Fetch the chosen template page as raw Markdown, for example https://email-sdk.dev/docs/ui/account/verification-code.md.
434. Use the documented shadcn@latest add registry URL when installation is requested, or copy the Manual source from the same page.
445. Keep templates on the actual @opencoredev/email-sdk/react primitives and verify both light and dark email themes when changing presentation.
45
46When local source and external docs disagree, prefer the code/types for the exact installed version and mention the mismatch.
47
48## Defaults
49
50- Prefer bun and bunx.
51- Keep the core dependency-free.
52- Import adapters from separate entry points such as @opencoredev/email-sdk/resend, @opencoredev/email-sdk/smtp, and the adapter-specific entry point shown by the current package exports.
53- Do not add Nodemailer for SMTP; Email SDK includes its own SMTP transport.
54- SMTP auth on non-secure ports upgrades with STARTTLS by default. Only use allowInsecureAuth for trusted local test servers.
55- Adapters must either map a normalized EmailMessage field or reject it clearly. Never silently drop CC, BCC, reply-to, headers, tags, metadata, or attachments.
56- Keep adapter credentials in environment variables.
57- Never log API keys, SMTP passwords, raw tokens, full message bodies, or unnecessary recipient data.
58- Preserve the host app's architecture for queues, templates, env validation, retries, and tests.
59
60## Integration Pattern
61
62Entry point names like @opencoredev/email-sdk/resend and @opencoredev/email-sdk/smtp are illustrative. Verify the exact exports from the installed version before copying these imports.
63
64Prefer wiring Email SDK as a production send pipeline: one normalized message shape, explicit adapter routes, fail-fast field support, retries, compatible fallback routes, secret-safe observability, tests, and CLI verification.
65
66```ts
67import { createEmailClient } from "@opencoredev/email-sdk";
68import { resend } from "@opencoredev/email-sdk/resend";
69import { smtp } from "@opencoredev/email-sdk/smtp";
70
71export const email = createEmailClient({
72 adapters: [
73 resend({ apiKey: process.env.RESEND_API_KEY! }),
74 smtp({
75 host: process.env.SMTP_HOST!,
76 port: Number(process.env.SMTP_PORT ?? 587),
77 auth: {
78 user: process.env.SMTP_USER!,
79 pass: process.env.SMTP_PASS!,
80 },
81 }),
82 ],
83 fallback: { adapters: ["smtp"] },
84 retry: { maxAttempts: 2 },
85});
86```
87
88## Fallback and retry guidance
89
90- Choose fallback routes only after checking the current field support docs or adapter source.
91- Use fallback only when the backup adapter can send the same class of email and preserve the fields that matter to the app.
92- Do not treat SMTP as a universal backup; it is best for simple text/html sends with address fields and headers.
93- Use idempotency keys for externally visible transactional sends that may be retried or sent through fallback routes.
94- Use hooks or observabilityPlugin() for redacted route, attempt, retry, success, and error events.
95- Add tests with memoryAdapter(), failingAdapter(), and capturePlugin() when fallback or retry behavior matters.
96- Use the CLI doctor and send --dry-run before live provider authentication checks.
97- Use the separate email-sdk-migrate skill for v0-to-v1 application migrations instead of applying static find-and-replace rules.
98
99Inside this repo, the main public docs for this pattern are:
100
101- apps/fumadocs/content/docs/guides/production-send-pipeline.mdx
102- apps/fumadocs/content/docs/concepts/fallbacks-and-retries.mdx
103- apps/fumadocs/content/docs/adapters/field-support.mdx
104
105## Validation
106
107- For SDK changes, run bun test in packages/email-sdk.
108- For docs changes, run bun run check-types and bun run build from the repo root when practical.
109- For app integrations, run the narrowest test/typecheck that covers the send path.
110- For real provider authentication checks, use the repository's non-sending live:* scripts when available. Do not send external mail without the user's separate approval.
111
112## Review Checklist
113
114- Does every send include from, to, subject, and either html or text?
115- Are fallbacks configured only for adapters that can send the same class of email?
116- Are idempotency keys used for externally visible transactional sends?
117- Are provider errors surfaced instead of swallowed?
118- Are hooks used for metadata and status, not secret or full-body logging?
119- Does each adapter payload have a test when its field mapping changes?
120
In the file
SKILL.md914 words
Files1
LicenceMIT
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈80
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
1,670
on trigger
The instruction body, read only when the skill fires.
0.88%
of a 200k window
Ten skills this size would take about 9% of the window before you open a file.
050k100k150k200k context window

1.8k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

If this is not it

13 other skills in Email

What is in the bundle

1 file, 7.0 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md7.0 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The MIT licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

$99 once
email-sdk · MIT · opencoredev
one-time
Price$99 once
LicenceMIT — the author’s, unchanged by this purchase
Paid throughStripe, once, on the card you add at the checkout
Keeps workingfor good — the files are yours once they are on disk
Updatesevery update its author ships, delivered through this account

You can read the whole bundle before paying — the SKILL.md above is the product, not a preview of it. What the money buys is the delivery: the folder packaged and handed to your machine by key, every update its author ships, and our support if it does not do what this listing says. The terms of use are MIT, set by the author and unchanged by buying it here.

Payment runs through Stripe, on a page like this one rather than a redirect. Once there is an account it joins the same mcprush invoice as everything else you run, so there is never a second card to enter.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
Price$99
Referenceopencoredev/email-sdk

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Who wrote it

OP
opencoredev

Publishes on mcprush.

0 servers listed1 skill listednot claimed
Profile
Publisher
Servers0