本文へ移動
cccskills
無料GitHub で公開

lifecycle-messaging

Email/SMS lifecycle and deliverability framework for SMB Product-Builder products that send transactional or lifecycle messages (booking reminders, CRM sequences, receipts, win-back). Codifies provider selection (Resend/Postmark/Twilio/SendGrid), domain auth (SPF/DKIM/DMARC), consent and compliance (TCPA, CAN-SPAM, CASL, quiet hours, double opt-in), suppression-list discipline, and the transactional-vs-marketing split. Applied by integrations-engineer and senior-dev whenever a feature sends messages — so deliverability and consent are designed in, not bolted on after the first spam complaint.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md5.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Lifecycle messaging — deliverable, consented, compliant

Messages that don't arrive (poor deliverability) or that arrive without consent (TCPA/ CAN-SPAM violations) are both fatal for an SMB product. This skill makes both correct by construction. Design the consent + deliverability posture before the first send.

1. Transactional vs marketing — split them

Decide per message which bucket it is; they have different rules and should use different sending identities (often different subdomains / providers):

TransactionalMarketing / lifecycle
Examplesreceipt, booking confirm/reminder, password resetwin-back, promo, newsletter, nurture step
Consentimplied by the transactionexplicit opt-in required
Unsubscribenot required (but honor STOP)required, one-click, honored fast
Sending domaintxn. subdomainmail./news. subdomain

Never send marketing content on the transactional channel "because it delivers better" — that's how the transactional domain gets burned.

2. Provider selection (pick one, justify it)

  • Email — Postmark (best transactional deliverability, strict on marketing), Resend (DX-first, good default), SendGrid (scale). Default: Resend for transactional, add a marketing-grade ESP only when lifecycle volume justifies it.
  • SMS — Twilio (messaging service + sender pool), or Telnyx. Use a Messaging Service, not a single number, for scale + failover. A2P 10DLC registration is required for US application-to-person SMS — register the brand/campaign before sending.

3. Domain authentication (non-negotiable for email)

  • SPF — sender IP authorized in DNS.
  • DKIM — provider signing key published; messages signed.
  • DMARC — start p=none with rua reporting, ramp to p=quarantine→p=reject once aligned. Without DMARC alignment, lifecycle mail lands in spam.
  • Warm up a new sending domain gradually; never blast from a cold domain.

4. Consent + compliance (US-first)

  • CAN-SPAM (email) — valid physical postal address, accurate From/Subject, working one-click unsubscribe honored within 10 days.
  • TCPA (SMS/voice) — prior express written consent for marketing SMS; honor STOP/UNSTOP/ HELP keywords automatically; respect quiet hours (no marketing 9pm–8am recipient local time). Keep proof of consent (timestamp, source).
  • CASL (if CA recipients) — express opt-in + identification + unsubscribe.
  • Double opt-in for marketing lists where feasible — protects deliverability and proves consent.

5. Suppression discipline (the deliverability lifeline)

Maintain a single suppression list the sender checks before every send:

  • hard bounces → suppress permanently
  • spam complaints (FBL) → suppress + investigate
  • unsubscribes / STOP → suppress for that channel immediately
  • never re-import a suppressed address from a migration without re-consent

A send that ignores suppression is the fastest path to a blocklist.

6. Reliability patterns

  • Idempotent sends keyed on the domain event (a reminder for booking X sends once, even on retry) — coordinate the key with integrations-engineer.
  • Status-callback / webhook reconciliation: record delivered/bounced/failed; surface failures, don't swallow them.
  • Rate-limit + queue lifecycle sends; never loop-send.
  • Quiet-hours + timezone are computed from the recipient's locale, not the server's.

Output

When applied, contribute a Messaging section to the integration contract (docs/integrations/INTEGRATE-{slug}.md):

## Messaging
- channels: email <provider> / sms <provider>
- identities: txn = <subdomain>, marketing = <subdomain/ESP>
- domain auth: SPF/DKIM/DMARC plan = <state>
- consent: <implied/explicit per message type>; STOP/HELP = handled
- quiet hours: <recipient-local window>; 10DLC: <registered?>
- suppression: <store> checked pre-send
- idempotency key: <derivation>

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

great_cto's own committed aesthetic — the instrument panel. Dark five-step surface ladder, exactly one accent, two faces divided by MEANING (Geist speaks, Geist Mono is machine-truth), tabular numerals, and a dash that is not a nought. Twelve checkable rules measured from packages/board and greatcto.systems, not designed for this file. Use when building or extending any great_cto surface — the board, the site, a report, a share page.

日本語の概要は準備中です。原文の説明を表示しています。

avelikiy/great_cto1032026年10月12日 更新

Catalogue of known SDLC anti-patterns that great_cto agents must actively reject when reviewing architecture, plans, code, or post-mortems. Used by architect (pre-impl), pm (planning), senior-dev (impl), l3-support (post-incident).

日本語の概要は準備中です。原文の説明を表示しています。

avelikiy/great_cto1032026年10月12日 更新

anydesign

無料

Analyze images, websites, and Figma files to extract their design and generate a `design.md` with token system, component inventory, and reconstruction notes. Use this skill whenever the user wants to understand, document, replicate, or audit the design of something visual: a screenshot, a URL, a Figma link, a Pinterest reference, a mockup, a competitor's site, a component, a dashboard, a landing page. Also when they ask 'extract the design system from X', 'document the style of Y', 'analyze this visually', 'convert this image into tokens', 'help me replicate this design', 'what palette does this site use', 'how is this built'. Also for single elements: 'copy this navbar', 'recreate this illustration', 'give me a prompt to regenerate this graphic' — element mode outputs a focused element.md, with token-grounded image-model prompts when the element is visual art. If the user brings any visual source and wants to understand it at a design level — this skill should activate.

日本語の概要は準備中です。原文の説明を表示しています。

avelikiy/great_cto1032026年10月12日 更新

Shared review framework that every domain reviewer (pci, oracle, gov, edtech, healthcare, mlops, etc.) MUST follow. Defines the output artifact (TM-{slug}.md), mandatory sections, severity scale, verdict format, the workflow scaffold (when-invoked, Step-0 read-inputs, HANDOFF), and the "domain heuristic vs generic check" boundary. Eliminates duplication across the ~30 reviewer prompts.

日本語の概要は準備中です。原文の説明を表示しています。

avelikiy/great_cto1032026年10月12日 更新

Structured idea generation + multi-LLM debate for the product-owner stage. Diverge (generate genuinely different bets), debate (a 4-persona panel on 4 models argues over 2 rounds), converge (synthesize a recommendation). Used by product-owner before architect; available to architect for design-space exploration.

日本語の概要は準備中です。原文の説明を表示しています。

avelikiy/great_cto1032026年10月12日 更新

Run the great_cto controlled Codex lifecycle with controller-owned writes, verifier evidence, human gates and optional artifact release.

日本語の概要は準備中です。原文の説明を表示しています。

avelikiy/great_cto1032026年10月12日 更新

avelikiy のスキルをすべて見る

このスキルの問題を報告する