courier-notification-skills

Name: courier-notification-skills
Author: trycourier

github.com/trycourier開発15122 回インストール1 週間前に更新

リポジトリ

courier-notification-skills について

複数チャネルの Courier 通知を設計・実装するためのガイダンススキルです。開発者が関連資料を選び、SDK の使用方法や通知の安全ルールを適用できるよう支援します。

主な機能

01タスクに応じたガイド選択
02Courier の Node.js・Python SDK の形式を掲載
03チャネル共通の通知安全ルール
04テンプレート、journey、ルーティングの案内

活用シーン

01メール、SMS、プッシュ通知の実装
02実装前の Courier SDK 呼び出し確認
03通知ルーティングとエラー処理の計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/trycourier/courier-skills --skill courier-notification-skills

インストール後、Claude Code で/courier-notification-skillsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE

README.md

resources/channels/

email.md

inbox-v7-legacy.md

sms.md

ms-teams.md

push.md

whatsapp.md

inbox.md

slack.md

resources/growth/

adoption.md

engagement.md

campaigns.md

index.md

referral.md

reengagement.md

resources/guides/

mcp.md

cli.md

elemental.md

journeys.md

catalog.md

batching.md

quickstart.md

multi-channel.md

providers.md

preferences.md

migrate-from-knock.md

migrate-general.md

reliability.md

migrate-from-novu.md

詳細

Courier 通知スキル

あらゆるチャネルで、配信可能で魅力的な通知を作成するためのガイダンスです。

このスキルの使い方

タスクを特定する — ユーザーが取り組んでいるのは、どのチャネル、通知の種類、または横断的な課題ですか？
必要なものだけを読む — 以下のルーティング表を使って、タスクに関連する1～2個のファイルを見つけます。すべてのファイルを読んではいけません。
最新のドキュメントを確認する — 現在の API シグネチャと SDK メソッドについては、https://www.courier.com/docs/llms.txt を取得します。
コーディングの前に全体をまとめる — コードを書く前に、チャネル、ルーティング、エラー処理を含む実装全体を計画します。
ルールを適用する — 各リソースファイルの冒頭には、厳守すべきルールを記載した「クイックリファレンス」セクションがあります。これらは提案ではなく制約として扱ってください。
共通ルールを確認する — 通知コードを生成する前に、以下の共通ルールに違反していないことを確認します。

曖昧なリクエストへの対応

ユーザーのリクエストから特定のチャネル、通知の種類、またはガイドを明確に判断できない場合は、リソースファイルを読む前に確認の質問をしてください。推測してはいけません。誤ったルーティングは時間を無駄にし、役に立たないコードを生み出します。

必要に応じて、次の質問をしてください。

どのチャネルですか？ — 「メール、SMS、プッシュ通知、アプリ内通知、Slack、Teams、WhatsApp のうち、どのチャネルで送信しますか？」
どのような種類ですか？ — 「パスワードのリセットや注文確認など、ユーザーの操作をきっかけに送信するトランザクション通知ですか？それとも、機能のお知らせのように能動的に送信するマーケティング／グロース通知ですか？」
新規ですか、既存ですか？ — 「最初から始めますか、それとも既存の Courier コードがありますか？既存の場合、どの SDK パッケージをインストールしていますか？」
どの言語を使っていますか？ — 「TypeScript/Node.js、Python、または別の言語を使っていますか？」

4つすべてを尋ねる必要はありません。適切な1～2個のファイルにルーティングするために必要な質問だけをしてください。リクエストが特定のトピック（例：「SMS について教えて」）に明確に関係する場合は、質問を省略して該当するリソースに直接進みます。

質問3（「新規ですか、既存ですか？」）によるルーティングの違い：

回答	スキップ	読み込む
Courier を初めて使う／既存のコードがない	（なし）	quickstart.md ＋該当するチャネルまたは種類のファイル
既存 — `@trycourier/courier` または `trycourier` がインストール済み	`quickstart.md` のインストールと環境設定のセクション	チャネルまたは種類のファイルに直接進みます。`client` は構築済みとみなします。必要であれば、1行のヘルスチェックとして `courier messages list` を案内します。
既存 — Inbox v7（`@trycourier/react-*`）	v8 のガイダンス	以下の「Courier Inbox のバージョン検出」ブロックを確認してから、inbox-v7-legacy.md を読みます

標準的な SDK の形式

Courier のコードを書く前、または評価する前に、この形式を基準にしてください。以下のファイルに記載された内容がこれと矛盾するように見える場合は、このブロックを優先し、最新のドキュメントを取得して解決してください。矛盾するスニペットを貼り付けてはいけません。

Node.js（@trycourier/courier）：

import Courier from "@trycourier/courier";

// Reads process.env.COURIER_API_KEY by default
const client = new Courier();

await client.send.message({
  message: {
    to: { user_id: "user-123" },           // or { email }, { phone_number }, { list_id }, { tenant_id }, etc.
    template: "nt_01kmrbq6ypf25tsge12qek41r0", // OR content: { title, body } / { version, elements }
    data: { /* merge variables */ },
  },
}, {
  // Pass the Idempotency-Key via headers. Always set it explicitly here —
  // that is the one path guaranteed to be sent to the API across SDK
  // versions. Verify against your installed SDK version before relying on
  // any other `idempotencyKey` request option.
  headers: { "Idempotency-Key": "order-confirmation-12345" },
});

Python（trycourier）：

from courier import Courier

# Reads COURIER_API_KEY from env by default
client = Courier()

client.send.message(
    message={
        "to": {"user_id": "user-123"},
        "template": "nt_01kmrbq6ypf25tsge12qek41r0",
        "data": {},
    },
    # Pass the Idempotency-Key via extra_headers. Python does not accept
    # idempotency_key= as a keyword argument — the header is the only way.
    extra_headers={"Idempotency-Key": "order-confirmation-12345"},
)

メソッド名のクイック参照（両 SDK は同じ構造で、Node は camelCase、Python は snake_case です）：

操作	Node	Python
メッセージを送信する	`client.send.message({ message })`	`client.send.message(message=...)`
テンプレートを作成する	`client.notifications.create({ notification, state })` → トップレベルに `{ id, name, content, … }` を返します	`client.notifications.create(notification=..., state=...)` → `response.id`
テンプレートを公開する	`client.notifications.publish(templateId)`	`client.notifications.publish(template_id)`
メッセージを取得する	`client.messages.retrieve(id)`	`client.messages.retrieve(id)`
メッセージを一覧表示する	`client.messages.list({ ... })`	`client.messages.list(...)`
ユーザーをリストに登録する（追加方式）	`client.lists.subscriptions.subscribeUser(userId, { list_id })`	`client.lists.subscriptions.subscribe_user(user_id, list_id=...)`
リストの登録者を置き換える	`client.lists.subscriptions.subscribe(listId, { recipients })`	`client.lists.subscriptions.subscribe(list_id, recipients=...)`
テナントを作成／置き換える	`client.tenants.update(tenantId, body)`	`client.tenants.update(tenant_id, ...)`
ユーザーをテナントに追加する	`client.users.tenants.addSingle(tenantId, { user_id })`	`client.users.tenants.add_single(tenant_id, user_id=...)`
一括ジョブを作成する	`client.bulk.createJob({ message: { event } })`（event は必須）	`client.bulk.create_job(message={"event": ...})`
プロファイルを作成／更新する（マージ）	`client.profiles.create(userId, { profile })`	`client.profiles.create(user_id, profile=...)`
ユーザーの設定を取得する	`client.users.preferences.retrieve(userId)`	`client.users.preferences.retrieve(user_id)`
トピックに対するユーザーの設定を更新する	`client.users.preferences.updateOrCreateTopic(topicId, { user_id, topic: { status, ... } })`	`client.users.preferences.update_or_create_topic(topic_id, user_id=..., topic=...)`
ユーザーのデバイストークンを登録する	`client.users.tokens.addSingle(token, { user_id, provider_key, device })`	`client.users.tokens.add_single(token, user_id=..., provider_key=..., device=...)`
ジャーニーを作成する	`client.journeys.create({ name, nodes, enabled })`	`client.journeys.create(name=..., nodes=..., enabled=...)`
ジャーニーを置き換える（ドラフト）	`client.journeys.replace(id, { name, nodes, enabled })`	`client.journeys.replace(id, name=..., nodes=..., enabled=...)`
ジャーニーを公開する	`client.journeys.publish(id)`	`client.journeys.publish(id)`
ジャーニーを呼び出す（実行を開始する）	`client.journeys.invoke(id, { user_id, data, profile })` → `{ runId }`	`client.journeys.invoke(template_id=id, user_id=..., data=..., profile=...)` → `.run_id`
ジャーニー専用テンプレートを作成する	`POST /journeys/{id}/templates`（SDK ヘルパーなし）	`POST /journeys/{id}/templates`（SDK ヘルパーなし）
ジャーニー専用テンプレートを公開する	`POST /journeys/{id}/templates/{templateId}/publish`（SDK ヘルパーなし）	`POST /journeys/{id}/templates/{templateId}/publish`（SDK ヘルパーなし）
オートメーションをトリガーする（レガシー）	`client.automations.invoke.invokeByTemplate(templateId, { recipient, data })`	`client.automations.invoke.invoke_by_template(template_id, recipient=..., data=...)`
アドホックオートメーションをトリガーする（レガシー）	`client.automations.invoke.invokeAdHoc({ recipient, automation })`	`client.automations.invoke.invoke_ad_hoc(recipient=..., automation=...)`
ルーティング戦略を作成する	`client.routingStrategies.create({ name, routing, channels?, providers? })` → `{ id: "rs_...", ... }` を返します	`client.routing_strategies.create(name=..., routing=..., ...)`
ルーティング戦略を置き換える（完全な PUT）	`client.routingStrategies.replace(id, { name, routing, ... })`	`client.routing_strategies.replace(id, name=..., routing=..., ...)`
プロバイダーを設定する	`client.providers.create({ provider, settings, title?, alias? })`	`client.providers.create(provider=..., settings=..., ...)`
プロバイダーカタログを一覧表示する（必須の `settings` スキーマ）	`client.providers.catalog.list({ keys?, name?, channel? })`	`client.providers.catalog.list(keys=..., channel=...)`
メッセージをキャンセルする	`client.messages.cancel(messageId)`	`client.messages.cancel(message_id)`
テンプレートを取得する	`client.notifications.retrieve(templateId)`	`client.notifications.retrieve(template_id)`
テンプレートを一覧表示する	`client.notifications.list()`	`client.notifications.list()`
テンプレートを置き換える（完全な PUT）	`client.notifications.replace(templateId, { notification, state })`	`client.notifications.replace(template_id, notification=..., state=...)`
テンプレートをアーカイブする	`client.notifications.archive(templateId)`	`client.notifications.archive(template_id)`
公開済みテンプレートのコンテンツを取得する	`client.notifications.retrieveContent(templateId)`	`client.notifications.retrieve_content(template_id)`

上記の表では、最も一般的な操作を網羅しています。journeys.md、templates.md、routing-strategies.md、providers.mdには、それぞれのリソースに対する CRUD（list、retrieve、replace、archiveを含む）で使用する、完全な SDK の形状一覧が記載されています。新しい複数ステップのフローには、Automations ではなく Journeys を使用してください。詳しくはJourneysを参照してください。

存在しない形状（作らないでください）：

client.messages.archive(...) — アーカイブは REST でのみ利用できます：POST /messages/{id}/archive。注：client.notifications.archive(id) と client.routingStrategies.archive(id) / client.providers.archive(id) は存在します。この制限は messages 名前空間にのみ適用されます。
client.tenants.createOrReplace(...) — client.tenants.updateを使用してください。
client.lists.subscribe(listId, userId) — subscriptions.subscribeUserまたはsubscriptions.subscribeを使用してください。
eventなしの一括createJob({ message: { template } }) — eventは必須です。
client.users.preferences.update(...) — client.users.preferences.updateOrCreateTopic(topicId, { user_id, topic })を使用してください。
client.automations.invoke(templateId, ...) — 正しい形状はclient.automations.invoke.invokeByTemplate(...)またはclient.automations.invoke.invokeAdHoc(...)です。注：新しい複数ステップのフローには、Automations ではなく Journeys（POST /journeys）を優先してください。
Journey の管理用 SDK メソッド（client.journeys.create/replace/publish/invoke）は存在するため、生の REST よりも優先して使用してください。Journey にスコープされたテンプレート操作（POST /journeys/{id}/templates、.../publish）には、現在 SDK ヘルパーがありません。その場合は REST/curl を使用してください。Journeys はまだ MCP には含まれていません。
client.routing.create(...) / client.strategies.* — 正しい名前空間は、Node ではclient.routingStrategies.*、Python ではclient.routing_strategies.*です。
client.integrations.* — integrations名前空間はありません。プロバイダー設定はclient.providers.*に、プロバイダー種別のカタログはclient.providers.catalog.*にあります。

存在するものの、デフォルトでは使用しない形状：

client.profiles.update(userId, { patch: [...] }) — これは存在し、JSON Patch（RFC 6902）を適用します。特定のパスに対するアトミックなフィールド単位の操作（add／remove／replace／test）がユーザーから明示的に求められた場合にのみ使用してください。一般的な「これらのフィールドをプロフィールにマージする」ケースでは、client.profiles.create(userId, { profile })（POST、ディープマージ）を使用してください。
client.profiles.replace(userId, { profile }) — これは存在し、プロフィールを上書きする完全な PUT です。プロフィールを正常な既知の状態にリセットする必要がある場合にのみ使用してください。通常の書き込みには、フィールドを気付かないうちに削除してしまうことがないため、client.profiles.create（マージ）のほうが安全です。

共通ルール

OTP、パスワードリセット、セキュリティアラートの通知を一括送信したり、遅延させたりしないでください。
重複が有害となる送信（支払い、セキュリティアラート、OTP）には、冪等性キーを使用してください。
セキュリティ変更の通知で、メールアドレスや電話番号を完全な形で公開しないでください（マスキングしてください）。
セキュリティ関連のメールには、必ず「自分はこれをリクエストしていません」というリンクを含めてください。
電話番号には必ず E.164 形式を使用してください。
ユーザーが希望したチャネル、またはユースケースに適したチャネルにのみ送信してください。デフォルトですべてのチャネルに送信しないでください。
テンプレート送信では、Courier が生成したnt_... ID を正式な ID として使用してください。ID はワークスペース固有の不透明な値として扱い、送信前にエイリアスをnt_...に解決してください。

Courier Inbox のバージョン判定

Inbox の案内を提供する前に、ユーザーが使用している SDK のバージョンを特定してください。

v7 の目印を確認する — 次のいずれかがあるか確認します：@trycourier/react-provider、@trycourier/react-inbox、@trycourier/react-toast、@trycourier/react-hooks、<CourierProvider>、useInbox()、useToast()、<Inbox />（<CourierInbox /> ではありません）、clientKey プロパティ、renderMessage プロパティ。利用可能であれば package.json も確認してください。
v8 の目印を確認する — 次のいずれかがあるか確認します：@trycourier/courier-react、@trycourier/courier-react-17、@trycourier/courier-ui-inbox、useCourier()、<CourierInbox />、<CourierToast />、courier.shared.signIn()、registerFeeds、listenForUpdates。
判断できない場合は尋ねる — 「どのバージョンの Courier Inbox SDK を使用していますか？package.json に @trycourier/react-inbox があれば v7、@trycourier/courier-react があれば v8 です。」

新規プロジェクトでは必ず v8 を使用してください。v7 はレガシーです。 ユーザーが v7 を使用している場合：

新しい v7 コードを書かないでください。 適切な対応は v8 へのアップグレードです。
v7 のコードに触れる前に resources/channels/inbox-v7-legacy.md を読んでください。認識パターンと移行手順が記載されています。
ステップごとのガイド https://www.courier.com/docs/sdk-libraries/courier-react-v8-migration-guide を使って移行するよう案内してください。
v8 はバンドルサイズが小さく、サードパーティ依存関係がなく、ダークモードが組み込まれており、モダンな UI を備えています。
v7 と v8 の API はまったく異なります。v7 のコードは v8 では動作せず、その逆も同様です。
唯一の例外： v8 は現時点で Tags と Pins に対応していません。ユーザーがこれらに依存している場合は、一時的に v7 を使い続ける必要があるかもしれませんが、v8 が対応したら移行する計画を立ててください。

Courier 公式ドキュメント

最新の API シグネチャ、SDK メソッド、またはこれらのリソースで扱われていない機能が必要な場合：

https://www.courier.com/docs/llms.txt を取得します。Courier のすべてのドキュメントページについて、URL と説明を含む構造化された Markdown インデックスが返されます。
インデックスから該当するページを探し、そのページの URL を取得して詳細を確認します。
ベストプラクティスには、このスキルのパターンを優先して使用し、API の詳細には llms.txt を使用します。

llms.txt を使用する場合：

これらのリソースに記載されていないメソッドの正確なシグネチャが必要な場合（例：client.audiences.create()）
開発者から、このスキルで扱っていない Courier の機能について質問された場合（例：Audiences、Brands、Translations）
このスキルのコード例が現在の SDK バージョンに合っているか確認する必要がある場合

llms.txt を使用しない場合：

回答がすでにこれらのリソースファイルにある場合（生のドキュメントより、このスキルの推奨パターンを優先してください）
ベストプラクティスや通知の設計に関する質問の場合（llms.txt は役に立ちません）

アーキテクチャの概要

[User Action / System Event]
            │
            ▼
    ┌───────────────┐
    │ Notification  │
    │   Trigger     │
    └───────┬───────┘
            │
            ▼
    ┌───────────────┐
    │   Routing     │──── User Preferences
    │   Decision    │──── Channel Availability
    └───────┬───────┘──── Urgency Level
            │
            ▼
    ┌───────────────────────────────────────┐
    │           Channel Selection           │
    ├───────┬───────┬───────┬───────┬──────┤
    │ Email │  SMS  │ Push  │ Inbox │ Chat │
    └───┬───┴───┬───┴───┬───┴───┬───┴───┬──┘
        │       │       │       │       │
        ▼       ▼       ▼       ▼       ▼
    [Delivery] [Delivery] [Delivery] [Delivery] [Delivery]
        │       │       │       │       │
        └───────┴───────┴───────┴───────┘
                        │
                        ▼
                ┌───────────────┐
                │   Webhooks    │
                │   & Events    │
                └───────────────┘

クイックリファレンス

チャネル別

以下を行う場合	次の場合に選んでください	参照先
メールの送信、到達性の改善、SPF/DKIM/DMARC の設定	受領書、確認通知、長文コンテンツ、添付ファイル、リッチフォーマットなど、長期間保持できる詳細な記録が必要な場合。到達性は送信者のレピュテーション（SPF/DKIM/DMARC）に左右され、リアルタイムではありません。	メール
SMS の送信、10DLC の登録への対応	短く、時間的制約のあるメッセージを幅広く迅速に届けたい場合。OTP、予約リマインダー、配送状況の更新などに適しています。米国では 10DLC の登録が必要です。文字数に制限があり、メッセージごとに費用がかかります。	SMS
プッシュ通知の送信、iOS／Android の違いへの対応	アプリを利用中のユーザーに通知したい場合。アクティビティ通知、リアルタイムのアラート、再エンゲージメントなどに適しています。デバイストークンと OS の許可が必要です。iOS と Android では許可の仕組みが異なり、ユーザーが許可を無効にしている場合は通知が届きません。	プッシュ
アプリ内通知センターの構築	既読状態、デバイス間の同期、受信トレイ UI を備えた、永続的なアプリ内通知が必要な場合。アプリ内でのみ表示されます。Courier Inbox SDK が必要です（v7 と v8 の違いは重要です。ファイルのヘッダーと上記の Inbox バージョン検出セクションを参照してください）。	Inbox（v8） — v8 を優先してください。既存の v7 コード（`@trycourier/react-inbox`、`<CourierProvider>`、`useInbox`）がある場合は、変更する前にInbox v7（レガシー）を参照してください。
Block Kit を使った Slack メッセージの送信	受信者が Slack ユーザーまたはチャンネルの場合。社内アラート、チーム通知、ChatOps などに適しています。OAuth とボットの設定が必要です。Block Kit には独自の JSON 形式があり、ワークスペースごとにレート制限があります。	Slack
Microsoft Teams メッセージの送信	受信者が Microsoft Teams を使用している場合。用途は Slack と同様ですが、組織が異なります。コネクタまたはボットが必要です。Adaptive Cards には独自の形式があります。	MS Teams
テンプレートを使った WhatsApp メッセージの送信	規制対象の市場、カスタマーサポート、エンゲージメントの高い地域（LATAM、EU、IN）で利用する場合。リッチメディアとテンプレートに対応します。24 時間のカスタマーサービス対応時間外では、承認済みのメッセージテンプレートが必要です。料金はカテゴリ別の会話単位です。	WhatsApp

トランザクションの種類別

以下を行う場合	参照先
パスワードリセット、OTP、認証、セキュリティアラートの構築	認証
注文確認、配送、配達状況の更新の構築	注文
領収書、請求書、支払い督促、サブスクリプション通知の構築	請求
予約確認、リマインダー、日程変更の構築	予約
ウェルカムメッセージ、プロフィールの更新、設定変更の構築	アカウント
トランザクション通知の原則を理解する	トランザクションの概要

グロースの種類別

以下を行う場合	参照先
アクティベーションフロー、セットアップガイド、最初の価値提供の構築	オンボーディング
機能告知、機能発見、使い方の案内の構築	利用促進
アクティビティ通知、定着、習慣化の仕組みの構築	エンゲージメント
再獲得、非アクティブ状態、カート放棄への対策	再エンゲージメント
紹介の招待、特典、バイラルループの構築	紹介
プロモーション、セール、アップグレードキャンペーンの構築	キャンペーン
グロース通知の原則を理解する	グロースの概要

横断的なガイド

次の操作を行うには…	参照先
最初の通知を送信する	クイックスタート
複数のチャネルに振り分け、フォールバックを設定する	マルチチャネル
ユーザーの通知設定を管理する	設定
再試行、冪等性、エラー復旧に対応する	信頼性
通知をまとめ、ダイジェストを作成する	バッチ処理
頻度を制御し、通知疲れを防ぐ	スロットリング
アプリの種類に応じた通知を計画する	カタログ
CLI を使って臨時の操作、デバッグ、エージェントのワークフローを実行する	CLI
MCP サーバーを使って、AI エージェントから構造化された API アクセスを行う	MCP サーバー
API を使ってテンプレートを管理する（作成、公開、バージョン管理）	テンプレート
API を使ってルーティング戦略を作成する（`rs_...`、プロバイダーの優先順位）	ルーティング戦略
API を使ってプロバイダーを設定する（SendGrid、Twilio など、カタログの検出）	プロバイダー
Elemental コンテンツ形式を理解する（要素の種類、制御フロー、ローカライズ）	Elemental
複数ステップの通知ジャーニーを構築する（遅延、分岐、シーケンス）	ジャーニー
再利用可能なコードパターン（同意、通知を控える時間帯、マスキング、再試行）	パターン
あらゆる通知システムから Courier に移行する	一般的な移行
Knock から Courier に移行する	Knock からの移行
Novu から Courier に移行する	Novu からの移行

詳細な説明がないトピック（公式ドキュメントを取得してください）

これらの分野には、専用のガイドがまだありません。ユーザーから質問された場合は、WebFetch で以下のページを取得してください。記憶を頼りに API の形式を推測してはいけません。迷った場合は、まず https://www.courier.com/docs/llms.txt を取得し、そこに記載された URL を使用してください。

トピック	取得先
オーディエンス（属性ベースのターゲティング）	https://www.courier.com/docs/platform/users/audiences
オートメーション（従来のダッシュボードワークフロー。新しい複数ステップのフローにはジャーニーを使用してください）	https://www.courier.com/docs/automations/overview
ブランド（ロゴ、色、再利用可能なビジュアルアイデンティティ）	https://www.courier.com/docs/platform/content/brands
テナント（マルチテナント B2B、テナントごとのブランディングや設定）	https://www.courier.com/docs/platform/tenants/tenants-overview（コードについてはパターンの「テナント」セクションも参照してください）
イベント／イベントマッピング	https://www.courier.com/docs/platform/automations/inbound-events（および Send API の `event` フィールド）
翻訳／i18n（テンプレートごとの `locales` ブロック以外）	https://www.courier.com/docs/platform/content/elemental/locales（要素レベル）または https://www.courier.com/docs/api-reference/translations/get-a-translation（API）

タスク別の最小ファイルセット

一般的なタスクでは、以下の特定のファイルだけを読む必要があります。

タスク	読むファイル
OTP/2FA の実装	authentication.md, sms.md
パスワードのリセット	authentication.md, email.md
注文通知	orders.md, multi-channel.md
メールの設定と到達性	email.md
SMS の設定	sms.md（10DLC を含む）
プッシュ通知の設定	push.md
アプリ内受信トレイの設定	inbox.md — v8 が主要版です。既存の v7 コードの場合のみ inbox-v7-legacy.md を参照してください
オンボーディングシーケンス	onboarding.md, journeys.md
セキュリティアラート	authentication.md, multi-channel.md
ダイジェスト／バッチ処理	batching.md, preferences.md
支払い／請求通知	billing.md, reliability.md
トライアル終了／サブスクリプション更新のリマインダー	billing.md（Trial Ending Journey）、journeys.md
予約リマインダー	appointments.md, journeys.md
WhatsApp テンプレート	whatsapp.md
Slack／Teams の連携	slack.md または ms-teams.md
Courier を初めて使う場合／最初の通知	quickstart.md
CLI のデバッグ／アドホック操作	cli.md
SMS 配信のデバッグ	cli.md, sms.md
メール到達性のデバッグ	cli.md, email.md
一般的な配信エラー	cli.md, reliability.md
MCP サーバーの設定	mcp.md, cli.md
任意のシステムからの移行	migrate-general.md, quickstart.md
Knock からの移行	migrate-from-knock.md, quickstart.md
Novu からの移行	migrate-from-novu.md, quickstart.md
テンプレートの CRUD／プログラムによるテンプレート操作	templates.md, patterns.md
プログラムによるルーティング戦略の作成	routing-strategies.md, templates.md
API によるプロバイダーの設定（SendGrid／Twilio など）	providers.md, multi-channel.md
Elemental コンテンツ形式（要素の種類、制御フロー）	elemental.md
インライン送信とテンプレート送信	templates.md, quickstart.md
リスト、一括送信、マルチテナント	patterns.md
プロバイダーのフェイルオーバー設定	multi-channel.md
Webhook の設定と署名検証	reliability.md
設定トピックとオプトアウト	preferences.md
受信トレイの JWT 認証と React の設定	inbox.md — v8 が主要版です。既存の v7 コードの場合のみ inbox-v7-legacy.md を参照してください
`to` フィールド／宛先の指定について	quickstart.md
マルチチャネル通知の構築	multi-channel.md, preferences.md
送信の信頼性を高める	reliability.md, patterns.md
通知疲れの軽減	throttling.md, batching.md, preferences.md
テンプレートとマルチチャネルルーティング	templates.md, multi-channel.md
プログラムによる複数ステップのジャーニー構築	journeys.md, elemental.md
カート放棄シーケンス	reengagement.md, journeys.md
予約リマインダーの段階的送信	appointments.md, journeys.md
エスカレーション（アプリ内 → プッシュ → メール）	multi-channel.md, journeys.md
呼び戻し／再エンゲージメントシーケンス	reengagement.md, journeys.md

意思決定ガイド

何を構築しますか？

特定の通知（OTP、注文確認、パスワードリセットなど） → 上記のタスク別の最小ファイルセットの表を使い、読むべきファイルを1～2個に絞ってください。
新しい通知チャネル（メール、SMS、プッシュ通知、Slackなど） → チャネルごとのガイドはチャネル別をご覧ください。
複数ステップの通知シーケンス（オンボーディングの段階的な配信、エスカレーション、リマインダーの段階的な配信、カート放棄、再獲得） → ジャーニーから始めてください。ジャーニーを使うと、API経由で遅延、分岐、送信を含む完全なDAGをコードとして定義できます。
通知インフラストラクチャ（ルーティング、設定、信頼性、バッチ処理） → 該当するガイドは横断的なガイドをご覧ください。
新しいアプリで構築する通知を計画する → カタログ、メール、マルチチャネルの順にご覧ください。
グロース／ライフサイクル通知（オンボーディング、エンゲージメント、紹介） → まずグロースの概要で同意要件を確認し、その後、該当する種類の通知をご覧ください。
Courierを初めて使う場合、または初めて通知を送信する場合 → クイックスタートから始めてください。
配信の問題をデバッグする → 推測する前に、必ずCLI（courier messages list、courier messages content）から始め、実際の配信状態を確認してください。その後、メールが迷惑メールに振り分けられる場合はメール、SMSが届かない場合はSMS、一般的な失敗については信頼性をご覧ください。
アドホックな操作、CI/CD、AI エージェントのワークフロー → エディターが対応している場合（Cursor、Claude Code、Claude Desktop、Windsurf、VSCode）はMCPを使用してください。MCP サーバーをご覧ください。シェルのみの環境、CI/CD、またはMCPを利用できない場合はCLIを使用してください。CLIをご覧ください。どちらも同じAPIキーを使用し、同じAPI機能を利用できます。
テンプレートをプログラムで管理する、またはElemental（CourierのJSONテンプレート言語）を理解する → 作成、公開、バージョン管理、ローカライズを含むCRUDの全ライフサイクルについてはテンプレートをご覧ください。要素（text、action、image、meta、channel、group）、制御フロー（if、loop、ref）、ロケール処理の詳細についてはElementalをご覧ください。
再利用可能なコードパターン（同意確認、通知を避ける時間帯、冪等性、フォールバック） → TypeScript、Python、CLI、curlでのコピーして使える実装はパターンをご覧ください。
他の通知システムからCourierへの移行 → Knockからの移行：Knockからの移行。Novuからの移行：Novuからの移行。その他のシステム（独自構築、SendGridの直接利用、Twilioの直接利用など）からの移行：一般的な移行。

Markdown 対応

ログインしてコメント

基本情報

作者: trycourier
リポジトリ: trycourier/courier-skills
カテゴリ: 開発
インストール数: 122
GitHub スター: 15

問題を報告