npm - vybekiit - Versions diffs - 0.7.0 → 0.7.2 - Mend

vybekiit 0.7.0 → 0.7.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (94) hide show

package/dist/global-skills/email-best-practices/README.md DELETED Viewed

@@ -1,63 +0,0 @@
-```
-  ╔══════════════════════════════════════╗
-  ║   _____ __  __    _    ___ _         ║
-  ║  | ____|  \/  |  / \  |_ _| |        ║
-  ║  |  _| | |\/| | / _ \  | || |        ║
-  ║  | |___| |  | |/ ___ \ | || |___     ║
-  ║  |_____|_|  |_/_/   \_\___|_____|    ║
-  ║                                      ║
-  ║           Best Practices             ║
-  ╚══════════════════════════════════════╝
-```
-# Email Best Practices Skill
-A comprehensive agent skill for building production-ready email systems. Covers everything from DNS authentication to webhook processing, with a focus on deliverability, compliance, and reliability.
-## Installation
-```bash
-npx skills add resend/email-best-practices
-```
-## What This Skill Covers
-**Getting Started**
-- Planning which emails your app needs (password reset, verification, order confirmations)
-- Setting up email authentication (SPF, DKIM, DMARC) so emails reach inboxes
-**Sending Emails**
-- Transactional email design (subject lines, content structure, mobile-first)
-- Marketing email best practices (consent, segmentation, unsubscribe)
-- Compliance requirements by region (CAN-SPAM, GDPR, CASL)
-**Production Infrastructure**
-- Idempotency and retry logic to prevent duplicates
-- Webhook processing for delivery events
-- Suppression lists and list hygiene automation
-## Structure
-```
-email-best-practices/
-├── SKILL.md                             # Start here - routes to the right resource
-└── references/
-    ├── deliverability.md                # SPF/DKIM/DMARC, sender reputation
-    ├── transactional-emails.md          # Password resets, OTPs, confirmations
-    ├── transactional-email-catalog.md   # Email combinations by app type
-    ├── marketing-emails.md              # Newsletters, campaigns, consent
-    ├── email-capture.md                 # Validation, verification, opt-in
-    ├── compliance.md                    # CAN-SPAM, GDPR, CASL
-    ├── email-types.md                   # Transactional vs marketing
-    ├── sending-reliability.md           # Idempotency, retry logic, errors
-    ├── webhooks-events.md               # Delivery events, webhook setup
-    └── list-management.md               # Suppression lists, hygiene
-```
-## Quick Start
-Open `SKILL.md` - it has a routing table that directs you to the right resource based on what you need to do.
-## License
-MIT

package/dist/global-skills/email-best-practices/references/accessibility.md DELETED Viewed

@@ -1,189 +0,0 @@
-# Email Accessibility
-Emails must be readable by screen readers, dark-mode clients, translation tools, and AI agents — not just sighted readers on a default inbox. The rules below are mechanical. Apply them every time.
-## Rules
-### Set `lang` and `dir` on `<html>` and on `<body>`'s direct children (Serious)
-Both attributes are needed in **two places**: on `<html>` *and* on the direct children of `<body>`. Several email clients strip the attributes from `<html>`, which is why duplicating them on the body's children is the single most common accessibility failure in production email.
-```html
-<html lang="en" dir="ltr">
-  <head>
-    <title>Your weekly product updates</title>
-  </head>
-  <body>
-    <div lang="en" dir="ltr">
-      <!-- email content -->
-    </div>
-  </body>
-</html>
-```
-- `lang`: a [BCP 47 language tag](https://developer.mozilla.org/en-US/docs/Glossary/BCP_47_language_tag) (`en`, `pt-BR`, `ja`, `ar`)
-- `dir`: `ltr`, `rtl`, or `auto`
-**Fallbacks when the correct values aren't available** (use only when you genuinely don't know):
-- `dir="auto"` — lets the user agent infer direction from content
-- `lang="und"` — marks the language as undetermined
-Both fallbacks are worse than the correct value but much better than nothing. For multi-locale templates, pass the locale through; do not hardcode `en`.
-### Mark layout tables as presentational (Serious)
-Any `<table>` used for layout must have `role="presentation"` (or the equivalent `role="none"`). Otherwise screen readers announce "table, row 1 of N" for every layout row and the email becomes unusable. Prefer avoiding layout tables entirely; when you can't, mark them.
-```html
-<table role="presentation" cellpadding="0" cellspacing="0" border="0">
-  <tr>
-    <td>...</td>
-  </tr>
-</table>
-```
-Leave a `<table>` without `role="presentation"` only when the data is genuinely tabular (line items, comparison rows). Tabular data should also use `<th scope="col">` for column headers.
-### Use a single `<h1>` and nest headings in order (Mild)
-Most emails should have one `<h1>` that names the email, with subheadings nested in order:`<h1>` → `<h2>` → `<h3>`. Never skip levels. Never fake a heading with bold `<p>`.
-```html
-<h1>Order confirmation</h1>
-  <h2>Items</h2>
-  <h2>Shipping</h2>
-    <h3>Address</h3>
-    <h3>Tracking</h3>
-```
-Headings are how assistive tech and AI clients navigate and summarize the email.
-**Exception:** very short messages (SMS-style notifications, single-sentence alerts) may not need a heading at all. If the email body is one or two sentences, skip the `<h1>` rather than wrap a heading around the only content.
-### Every link must have discernible text (Serious)
-Every `<a>` must contain text content that a screen reader can announce. The most common failure is a linked image with no alt text.
-A **linked image is never decorative.** It's functional, so its `alt` must describe what clicking does, not just what the image looks like.
-```html
-<!-- Wrong: linked image with no accessible name -->
-<a href="/order/123">
-  <img src="view-order.png" alt="">
-</a>
-<!-- Right: alt describes the action -->
-<a href="/order/123">
-  <img src="view-order.png" alt="View order #123">
-</a>
-<!-- Also right: visible text alongside the image -->
-<a href="/order/123">
-  <img src="icon.png" alt="">
-  View order #123
-</a>
-```
-When the visible link text can't carry enough information, add visually hidden text inside the `<a>` (see [goodemailcode.com/email-accessibility/visually-hidden-text](https://www.goodemailcode.com/email-accessibility/visually-hidden-text)). `aria-label` and `title` on `<a>` have limited support in email clients. Prefer real text content or visually hidden text.
-### Link text must describe the destination (Moderate)
-Even when a link has text, it must describe where the link goes. Never use "click here," "learn more," "read more," or bare URLs. Screen reader users often navigate by jumping between link texts with no surrounding context.
-```html
-<!-- Wrong -->
-<a href="...">click here</a>
-<a href="...">https://resend.com/blog/...</a>
-<!-- Right -->
-<a href="...">Read the 2026 accessibility report</a>
-```
-### Write meaningful alt text — and use `alt=""` for decorative images (Critical)
-Two distinct rules, both mandatory. `alt` must always be present; the value depends on the image's role.
-**Meaningful images** (product shots, charts, screenshots, anything carrying information): describe purpose and key details in context.
-```html
-<!-- Wrong: redundant, vague -->
-<img src="..." alt="image">
-<img src="..." alt="photo of a bike">
-<!-- Right: purpose + key details -->
-<img src="..." alt="Red bicycle leaning against a brick wall on a rainy street">
-```
-**Decorative images** (spacers, dividers, background flourishes, pure branding ornaments): use an empty `alt=""`. This tells screen readers to skip them. Never omit the attribute entirely — omitting it and `alt=""` are not equivalent; some screen readers announce the filename when `alt` is absent.
-```html
-<img src="divider.png" alt="" role="presentation">
-```
-If an image conveys no information that isn't already in the surrounding text, it is decorative. If it's inside an `<a>`, it is **not** decorative — see the "Every link must have discernible text" rule.
-### Include a `<title>` tag (Serious)
-Many clients and assistive technologies read `<title>` before anything else. It's also shown when the email is viewed as a web page. Treat it like the subject line, not the brand name.
-```html
-<head>
-  <title>Your weekly product updates from Resend</title>
-</head>
-```
-If the per-email title is hard to populate, a generic but specific fallback like `"Email from {Brand Name}"` still beats nothing.
-### Hit 4.5:1 color contrast, then check dark mode (Serious)
-- Body text and links: **4.5:1** minimum against the background (WCAG AA)
-- Large text (≥18pt, or ≥14pt bold): **3:1** minimum
-- Never rely on color alone to convey meaning (error states, status badges) — pair it with text or an icon
-Verify with the [WebAIM Contrast Checker](https://webaim.org/resources/contrastchecker/) or browser devtools.
-**Dark mode.** Outlook, Apple Mail, and others force dark mode and derive dark colors from your light ones. Healthy starting contrast keeps the auto-inverted version readable. Always preview in dark mode before shipping.
-## Priority order
-When you can't fix everything, fix in this order:
-1. **Critical** — missing or misused `alt` on images
-2. **Serious** — `lang`/`dir` (on `<html>` and body children), `role="presentation"` on layout tables, links without discernible text, missing `<title>`, color contrast
-3. **Moderate** — non-descriptive link text ("click here")
-4. **Mild** — missing `<h1>` (skip the fix for very short messages)
-## Authoring checklist
-Run this on every template:
-- [ ] `<html>` has `lang` and `dir`; direct children of `<body>` also have `lang` and `dir`
-- [ ] `<title>` set on `<head>`, specific to this email (not the brand name)
-- [ ] Layout `<table>` elements have `role="presentation"` (or `role="none"`)
-- [ ] At most one `<h1>` (or none, for very short messages); `<h2>`/`<h3>` nested in order
-- [ ] Every `<a>` has discernible text — visible text, descriptive alt on linked images, or visually hidden text
-- [ ] Every link describes its destination — no "click here," "learn more," or bare URLs
-- [ ] Every meaningful image has descriptive `alt`; every decorative image has an explicit `alt=""`
-- [ ] No linked image with `alt=""` (linked images are functional, never decorative)
-- [ ] Body text passes 4.5:1 contrast and stays readable in dark mode
-- [ ] Plain-text alternative is sent alongside the HTML version
-## Testing
-- **Automated.** Run the email through [Parcel's accessibility checker](https://parcel.io/docs/dev-tools/accessibility-checker) (the same tool the EMC report uses; available on the free plan). It catches most of the rules above.
-- **Screen reader pass.** macOS VoiceOver (`Cmd+F5`) or NVDA on Windows. Listen top to bottom; if anything is confusing, fix the markup.
-- **Contrast.** [WebAIM Contrast Checker](https://webaim.org/resources/contrastchecker/).
-- **Dark mode.** Send a test to Outlook (Windows/web), Apple Mail with dark appearance, Gmail iOS and Android.
-Automated tests do not catch everything. They will not tell you whether alt text actually matches the image, whether headings make semantic sense, or whether text inside an image is readable on narrow viewports. Even the three brands that passed every automated check in the EMC 2026 report had judgment-level issues like generic alt text on decorative images, alt text that didn't match the image, and 10px footer text. Treat automation as a floor, not a ceiling.
-## Related
-- [Transactional Emails](./transactional-emails.md) — content patterns for password resets, OTPs, receipts
-- [Marketing Emails](./marketing-emails.md) — newsletter and campaign best practices
-- [Compliance](./compliance.md) — legal requirements that overlap with accessibility (e.g., clear unsubscribe text)
-## Tooling
-When generating templates with React Email, the latest version handles several of the structural rules: `<Html>` sets `lang`/`dir`, `<Img>` defaults to `alt=""`, `<Markdown>` tables render `role="presentation"`, and `<Preview>` emits a `<title>`. Upgrade with `npm install react-email@latest`. The content rules — heading hierarchy, descriptive alt and link text, contrast, the linked-image rule — still have to be applied by hand.

package/dist/global-skills/email-best-practices/references/compliance.md DELETED Viewed

@@ -1,125 +0,0 @@
-# Email Compliance
-Legal requirements for email by jurisdiction. **Not legal advice—consult an attorney for your specific situation.**
-## Quick Reference
-| Law | Region | Key Requirement | Penalty |
-|-----|--------|-----------------|---------|
-| CAN-SPAM | US | Opt-out mechanism, physical address | $53k/email |
-| GDPR | EU | Explicit opt-in consent | €20M or 4% revenue |
-| CASL | Canada | Express consent, opt-out mechanism | $1M (individual) to $10M (organization) CAD |
-## CAN-SPAM (United States)
-**Requirements:**
-- Accurate header info (From, To, Reply-To)
-- Non-deceptive subject lines
-- Physical mailing address in every email
-- Clear opt-out mechanism
-- Honor opt-out within 10 business days
-**Transactional emails:** Can send without opt-in if related to a transaction and not promotional.
-## GDPR (European Union)
-**Requirements:**
-- Explicit opt-in consent (not pre-checked boxes)
-- Consent must be freely given, specific, informed
-- Easy to withdraw consent (as easy as giving it)
-- Right to access data and deletion ("right to be forgotten")
-- Process unsubscribe immediately
-**Consent records:** Document who, when, how, and what they consented to.
-**Transactional emails:** Can send based on contract fulfillment or legitimate interest.
-## CASL (Canada)
-**Consent types:**
-- **Express consent:** Explicit opt-in (ideal)
-- **Implied consent:** Existing business relationship (2 years) or inquiry (6 months)
-**Requirements:**
-- Clear sender identification that will be valid for 60 days after send
-- Unsubscribe functional for 60 days after send
-- Process unsubscribe no later than 10 business days
-- Keep consent records 3 years after expiration
-## Other Regions
-| Region | Law | Key Points |
-|--------|-----|------------|
-| Australia | Spam Act 2003 | Consent required, honor unsubscribe within 5 days |
-| UK | PECR + GDPR | Same as GDPR |
-| Brazil | LGPD | Similar to GDPR, explicit consent for marketing |
-## Unsubscribe Requirements Summary
-| Law | Timing | Notes |
-|-----|--------|-------|
-| CAN-SPAM | 10 business days | Must work 30 days after send |
-| GDPR | Immediately | Must be as easy as opting in |
-| CASL | 10 business days | Must work 60 days after send |
-**Universal best practices:** Prominent link, one-click when possible, no login required, free, confirm action.
-### List-Unsubscribe Header (Required for Bulk Senders)
-Gmail, Yahoo, and Microsoft require `List-Unsubscribe` headers. Without them, bulk emails may be rejected or spam-filtered.
-**Required headers:**
-```typescript
-headers: {
-  'List-Unsubscribe': '<https://example.com/unsubscribe>',
-  'List-Unsubscribe-Post': 'List-Unsubscribe=One-Click',
-}
-```
-**Your unsubscribe endpoint must:**
-- Accept POST requests — return `200` or `202` with a blank page
-- Display standard unsubscribe page for GET requests
-- Stop sending within 48 hours of the request
-## Managing preferences vs Unsubscribe from all
-Most legistlations require a one-click unsubscribe. `Managing preferences` is a nice-to-have and can lead to lower unsubscribe rate but doesn't replace `Unsubscribe`. If possible, offer both.
-## Consent Management
-**Record:**
-- Email address
-- Date/time of consent
-- Method (form, checkbox)
-- What they consented to
-- Source (which page/form)
-**Storage:** Database with timestamps, audit trail of changes, link to user account.
-## Data Retention
-| Law | Requirement |
-|-----|-------------|
-| GDPR | Keep only as long as necessary, delete when no longer needed |
-| CASL | Keep consent records 3 years after expiration |
-**Best practice:** Have clear retention policy, honor deletion requests promptly, review and clean regularly.
-## Privacy Policy Must Include
-- What data you collect
-- How you use data
-- Who you share data with
-- User rights (access, deletion)
-- How to contact about privacy
-## International Sending
-**Best practice:** Follow the most restrictive requirements (usually GDPR) to ensure compliance across all regions.
-## Related
-- [Email Capture](./email-capture.md) - Implement consent forms and double opt-in
-- [Marketing Emails](./marketing-emails.md) - Consent and unsubscribe requirements
-- [List Management](./list-management.md) - Handle unsubscribes and deletion requests

package/dist/global-skills/email-best-practices/references/deliverability.md DELETED Viewed

@@ -1,121 +0,0 @@
-# Email Deliverability
-Maximizing the chances that your emails are delivered successfully to the recipients.
-## Email Authentication
-**Required by Gmail/Yahoo/Microsoft** - unauthenticated emails will be rejected or spam-filtered.
-### SPF (Sender Policy Framework)
-Specifies which servers can send email for your domain.
-```
-v=spf1 include:amazonses.com ~all
-```
-- Add TXT record to DNS
-- Use `~all` (soft fail)
-### DKIM (DomainKeys Identified Mail)
-Cryptographic signature proving email authenticity.
-- Your email service will provide you with a TXT record
-### DMARC
-Policy for handling SPF/DKIM failures + reporting.
-```
-v=DMARC1; p=none; rua=mailto:dmarc@example.com
-```
-**Rollout:** `p=none` (monitor) → `p=quarantine; pct=25` → `p=reject`
-Learn more: https://resend.com/blog/dmarc-policy-modes
-### Verify Your Setup
-Check DNS records directly:
-```bash
-# SPF record
-dig TXT example.com +short
-# DKIM record (replace 'resend' with your selector)
-dig TXT resend._domainkey.example.com +short
-# DMARC record
-dig TXT _dmarc.example.com +short
-```
-**Expected output:** Each command should return your configured record. No output = record missing.
-## Sender Reputation
-### IP Warming
-New IP/domain? Gradually increase volume:
-| Week | Daily Volume |
-|------|-------------|
-| 1 | 50-100 |
-| 2 | 200-500 |
-| 3 | 1,000-2,000 |
-| 4 | 5,000-10,000 |
-Start with engaged users. Send consistently. Don't rush.
-Learn more: https://resend.com/docs/knowledge-base/warming-up
-### Maintaining Reputation
-**Do:** Send to engaged users, keep bounce <4%, complaints <0.1%, remove inactive subscribers.
-**Don't:** Send to purchased lists, ignore bounces/complaints, send inconsistent volumes
-## Bounce Handling
-| Type | Cause | Action |
-|------|-------|--------|
-| Hard bounce | Permanent failure to deliver | Remove immediately |
-| Soft bounce | Transient failure to deliver | Retry: 1h → 4h → 24h, remove after 3-5 failures |
-**Targets:** <1% good, 1-3% acceptable, 3-4% concerning, >4% critical
-## Complaint Handling
-**Targets:** <0.01% excellent, 0.01-0.05% good, >0.05% critical
-**Reduce complaints:**
-- Only send to opted-in users
-- Make unsubscribe easy and immediate
-- Use clear sender names and "From" addresses
-**Feedback loops:** Set up with Gmail (Postmaster Tools), Yahoo, Microsoft SNDS. Remove complainers immediately.
-## Infrastructure
-**Dedicated sending domain:** Use different subdomains for different sending purposes (e.g., `t.example.com` for transactional emails and `m.example.com` for marketing emails).
-**DNS TTL:** Low (300s) during setup, high (3600s+) after stable.
-## Troubleshooting
-**Emails going to spam?** Check in order:
-1. Authentication (SPF, DKIM, DMARC)
-2. List-Unsubscribe header — required by Gmail/Yahoo since Feb 2024 (see [Compliance](./compliance.md))
-3. Sender reputation (blacklists, complaint rates)
-4. Content
-5. Sending patterns (sudden volume spikes)
-**Diagnostic tools:**
-- [Google Postmaster Tools](https://postmaster.google.com) - Domain reputation and spam rates
-- [mail-tester.com](https://www.mail-tester.com) - Send a test email, get deliverability score
-- [MXToolbox](https://mxtoolbox.com/blacklists.aspx) - Check blacklist status
-## Related
-- [List Management](./list-management.md) - Handle bounces and complaints to protect reputation
-- [Sending Reliability](./sending-reliability.md) - Retry logic and error handling

package/dist/global-skills/email-best-practices/references/email-capture.md DELETED Viewed

@@ -1,129 +0,0 @@
-# Email Capture Best Practices
-Collecting email addresses responsibly with validation, verification, and proper consent.
-## Email Validation
-### Client-Side
-**HTML5:**
-```html
-<input type="email" required>
-```
-**Best practices:**
-- Validate on blur or with short debounce
-- Show clear error messages
-- Don't be too strict (allow unusual but valid formats)
-- Client-side validation ≠ deliverability
-### Server-Side (Recommended)
-Always validate server-side—client-side can be bypassed.
-**Check:**
-- Email format (RFC 5322)
-- Domain exists (DNS lookup)
-- Domain has MX records
-- Optionally: disposable email detection
-Recommended tools: https://resend.com/blog/best-email-verification-apis
-## Double opt-in
-Confirms address belongs to user and is deliverable.
-### Process
-1. User submits email
-2. Send verification email with unique link/token
-3. User clicks link
-4. Mark as verified
-5. Allow access/add to list
-**Timing:** Send immediately, include expiration (24-48 hours), allow resend after 60 seconds, limit resend attempts (3/hour).
-### Single vs Double Opt-In
-| | Single Opt-In | Double Opt-In |
-|--|---------------|---------------|
-| **Process** | Add to list immediately | Require email confirmation first |
-| **Pros** | Lower friction, faster growth | Verified addresses, better engagement, meets GDPR/CASL |
-| **Cons** | Higher invalid rate, lower engagement | Some users don't confirm |
-| **Use for** | Account creation, transactional | Marketing lists, newsletters |
-**Recommendation:** Double opt-in for all marketing emails.
-## Form Design
-### Email Input
-- Use `type="email"` for mobile keyboard
-- Include placeholder ("you@example.com")
-- Clear error messages ("Please enter a valid email address" not "Invalid")
-### Consent Checkboxes (Marketing)
-- **Unchecked by default** (required)
-- Specific language about what they're signing up for
-- Separate checkboxes for different email types
-- Link to privacy policy
-```
-☐ Subscribe to our weekly newsletter with product updates
-☐ Send me promotional offers and deals
-```
-**Don't:** Pre-check boxes, use vague language, hide in terms.
-### Form Layout
-- Keep simple and focused
-- One primary action
-- Clear value proposition
-- Mobile-friendly
-- Accessible (labels, ARIA)
-## Error Handling
-### Invalid Email
-- Show clear error message
-- Suggest corrections for common typos (@gmial.com → @gmail.com)
-- Allow user to fix and resubmit
-### Already Registered
-- Accounts: "This email is already registered. [Sign in]"
-- Marketing: "You're already subscribed! [Manage preferences]"
-- Don't reveal if account exists (security)
-### Rate Limiting
-- Limit verification emails (3/hour per email)
-- Rate limit form submissions
-- Use CAPTCHA sparingly if needed
-- Monitor for abuse patterns
-## Verification Emails
-**Content:**
-- Clear purpose ("Verify your email address")
-- Prominent verification button
-- Expiration time
-- Resend option
-- "I didn't request this" notice
-- Don't include OTP/2FA codes in subject line or preview text as it discourages opens
-**Design:**
-- Mobile-friendly
-- Large, tappable button
-- Clear call-to-action
-See [Transactional Emails](./transactional-emails.md) for detailed email design guidance.
-## Related
-- [Compliance](./compliance.md) - Legal requirements for consent (GDPR, CASL)
-- [Marketing Emails](./marketing-emails.md) - What happens after capture
-- [Deliverability](./deliverability.md) - How validation improves sender reputation