{"id":16742,"plugin_id":"plugins_6a67e30422d48191b8b02b1685c38401","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:13:43.601Z","digest":"aba849286eeb15e6521633c80511dd66ee7278c97a5643aaa179640c68ae618b","against":null,"payload":{"description":"Implement MailChannels outbound email with the official `mailchannels-sdk` package in server-side JavaScript or TypeScript. Use for direct or queued sends, attachments, Mustache payload templates, unsubscribe handling, custom headers, DKIM, domain checks, sub-accounts, metrics, usage, suppressions, webhooks, signature verification, or the local simulator. Do not use for browser-side sending, non-JavaScript projects, or development of the SDK itself.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":270},{"relative_path":"references/recipes.md","size_in_bytes":3309}],"name":"mailchannels-js","skill_md_contents":"---\nname: mailchannels-js\ndescription: Implement MailChannels outbound email with the official `mailchannels-sdk` package in server-side JavaScript or TypeScript. Use for direct or queued sends, attachments, Mustache payload templates, unsubscribe handling, custom headers, DKIM, domain checks, sub-accounts, metrics, usage, suppressions, webhooks, signature verification, or the local simulator. Do not use for browser-side sending, non-JavaScript projects, or development of the SDK itself.\n---\n\n# MailChannels JavaScript SDK\n\nUse the project's package manager, runtime conventions, mail abstraction, and\ntest style. Read [references/recipes.md](references/recipes.md) for verified\npatterns and resource names.\n\n## Workflow\n\n1. Inspect `package.json`, lockfiles, module format, TypeScript settings,\n   framework, and existing environment configuration.\n2. Install `mailchannels-sdk`. Import `MailChannels` from\n   `mailchannels-sdk`; do not invent methods from another language SDK.\n3. Load `MAILCHANNELS_API_KEY` only in trusted server code. Construct separate\n   clients for separate credentials rather than mutating shared state.\n4. Choose direct send when immediate request validation matters or queued send\n   when the application should hand work to the provider queue.\n5. Reuse the project's queue, logging, retry, and observability conventions.\n   Treat API acceptance as submission, not delivery.\n6. Handle the SDK's `{ data, error }` result explicitly. Retry only when the\n   operation and application idempotency make a retry safe.\n7. Add unit and integration tests with the local simulator or mocked transport.\n   Do not send live email from ordinary test suites.\n8. Before production, add sender-domain checks, signed webhook processing,\n   suppression handling, and explicit operator setup notes.\n\n## Guardrails\n\n- Never expose the API key to a browser, mobile client, generated page, log, or\n  committed file.\n- Use reserved example domains and fake recipients in tests.\n- Preserve raw webhook bytes and verify digest, freshness, key ID, and\n  signature before applying any event.\n- Keep application authorization, consent, approvals, budgets, and audit trails\n  even when provider-side sub-account controls are enabled.\n- Do not promise delivery, inbox placement, isolation, or plan features that\n  the current product documentation does not guarantee.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}