vybekiit 0.7.19 → 0.7.21

package/dist/global-skills/email-best-practices/tests/scenarios/03-retry-idempotency.md

@@ -1,36 +0,0 @@
-# Scenario 3: Retry Logic + Idempotency
-
-## Prompt
-
-```
-You are an AI coding assistant. A developer asks you:
-
-"I'm using the Resend API to send transactional emails. I need to implement retry logic with idempotency to prevent duplicate sends. Show me a TypeScript implementation with idempotency keys, exponential backoff, and proper error code handling."
-
-Include specific HTTP error codes and which ones to retry vs not retry, idempotency key generation strategies, and backoff timing.
-```
-
-## Expected Correctness Criteria
-
-### Idempotency keys (sending-reliability.md)
-- [ ] Event-based key example: `order-confirm-${orderId}` (recommended)
-- [ ] Request-scoped example: `reset-${userId}-${resetRequestId}`
-- [ ] UUID fallback: `crypto.randomUUID()` — generate once, reuse on retry
-- [ ] Warns against `Date.now()` or random values generated fresh on each attempt
-- [ ] Key expiration: 24 hours — complete retry logic within this window
-
-### Error codes (sending-reliability.md)
-- [ ] Retry: 5xx (server error), 429 (rate limit), network timeout, DNS failure
-- [ ] Do NOT retry: 400 (bad request), 401 (unauthorized), 403 (forbidden), 404 (not found), 422 (validation)
-
-### Backoff (sending-reliability.md)
-- [ ] Exponential: 1s -> 2s -> 4s -> 8s
-- [ ] Cap at 30 seconds
-- [ ] Jitter to prevent thundering herd
-- [ ] Max retries: 3
-
-### Timeout (sending-reliability.md)
-- [ ] AbortController pattern with 10-30 second timeout
-
-### Queuing (sending-reliability.md)
-- [ ] Queue pattern for critical emails: write pending -> attempt send -> mark sent/schedule retry -> mark failed + alert

package/dist/global-skills/email-best-practices/tests/scenarios/04-webhook-bounce-handling.md

@@ -1,52 +0,0 @@
-# Scenario 4: Webhook Bounce/Complaint Handling
-
-## Prompt
-
-```
-You are an AI coding assistant. A developer asks you:
-
-"I need to set up Resend webhooks to handle bounces and complaints. Show me how to implement this with signature verification using svix, idempotent event processing, and proper bounce/complaint handling (when to suppress, when to retry). Include TypeScript code."
-
-Be specific about: svix verification headers, hard vs soft bounce handling thresholds, and complaint handling requirements.
-```
-
-## Expected Correctness Criteria
-
-### Webhook setup (webhooks-events.md)
-- [ ] Endpoint must return 2xx within 5 seconds
-- [ ] Return 200 immediately, process asynchronously
-
-### Svix verification (webhooks-events.md)
-- [ ] Import from 'svix'
-- [ ] Headers: `svix-id`, `svix-timestamp`, `svix-signature`
-- [ ] Verify before processing, return 400 on invalid signature
-
-### Idempotent processing (webhooks-events.md)
-- [ ] Use event ID to deduplicate
-- [ ] Check if already processed before handling
-- [ ] Mark as processed after handling
-
-### Event types (webhooks-events.md)
-- [ ] `email.sent`, `email.delivered`, `email.bounced`, `email.complained`, `email.opened`, `email.clicked`
-
-### Bounce handling (webhooks-events.md + list-management.md)
-- [ ] Hard bounce: suppress immediately, remove from all lists
-- [ ] Soft bounce: track count, suppress after 3 failures
-- [ ] Suppression entry schema includes: email, reason, created_at, source_email_id
-
-### Complaint handling (webhooks-events.md + list-management.md)
-- [ ] Immediate suppression — no exceptions
-- [ ] Remove from all lists
-- [ ] Log for analysis
-
-### Suppression unsuppress rules (list-management.md)
-- [ ] Hard bounce: cannot unsuppress (address invalid)
-- [ ] Complaint: cannot unsuppress (legal requirement)
-- [ ] Soft bounce (3x): can unsuppress after 30-90 days
-- [ ] Manual removal: only if user requests
-
-### Pre-send check (list-management.md)
-- [ ] Always check suppression before sending
-
-### Retry behavior (webhooks-events.md)
-- [ ] Non-2xx triggers retries: ~30s -> ~1min -> ~5min (continues ~24 hours)

package/dist/global-skills/email-best-practices/tests/scenarios/05-new-saas-email-plan.md

@@ -1,51 +0,0 @@
-# Scenario 5: New SaaS Email Infrastructure Plan
-
-## Prompt
-
-```
-You are an AI coding assistant. A developer asks you:
-
-"I'm building a new SaaS app and need to plan my entire email infrastructure. I need to know: (1) what types of transactional emails I should plan for, (2) how to set up DNS authentication, (3) how to warm up my sending domain, (4) how to handle bounces/complaints in production, and (5) what compliance requirements I need for international users. Give me a comprehensive implementation roadmap."
-
-Be specific about: IP warming schedules (daily volumes by week), bounce rate thresholds, complaint rate thresholds, DNS record formats, and legal requirements by region.
-```
-
-## Expected Correctness Criteria
-
-### Email planning (transactional-email-catalog.md)
-- [ ] References the transactional email catalog for SaaS planning
-- [ ] Covers at minimum: verification, password reset, OTP/2FA, security alerts, billing
-
-### DNS authentication (deliverability.md)
-- [ ] SPF, DKIM, DMARC records with examples
-- [ ] DMARC rollout strategy (none -> quarantine; pct=25 -> reject)
-- [ ] Dedicated subdomains for transactional vs marketing
-
-### Warming (deliverability.md)
-- [ ] Correct weekly schedule: 50-100 / 200-500 / 1k-2k / 5k-10k
-- [ ] Start with engaged users, send consistently
-
-### Bounce/complaint handling (deliverability.md + list-management.md + webhooks-events.md)
-- [ ] Bounce thresholds: <1% good, >4% critical
-- [ ] Complaint thresholds: <0.01% excellent, >0.05% critical
-- [ ] Hard bounce: immediate suppression
-- [ ] Soft bounce: suppress after 3 failures
-- [ ] Complaint: immediate suppression
-- [ ] Pre-send suppression check
-
-### Compliance (compliance.md)
-- [ ] Covers CAN-SPAM, GDPR, CASL
-- [ ] Correct penalty amounts
-- [ ] Correct unsubscribe timing by region
-- [ ] Recommends GDPR as global standard
-
-### Data retention (list-management.md)
-- [ ] Send attempts: 90 days
-- [ ] Bounce/complaint events: 3 years
-- [ ] Suppression list: indefinite
-- [ ] Email content: 30 days
-- [ ] Consent records: 3 years after expiry
-
-### Cross-resource synthesis
-- [ ] Agent references multiple resource files (not just one)
-- [ ] "Start Here" routing from SKILL.md is followed