ワンクリックでManusで任意のスキルを実行

constructive-notifications

スター0

フォーク1

更新日2026年6月7日 05:07

Notification system — inbox, delivery, channels, preferences, bounce/complaint handling, suppression list, and digest batching. Use when asked to 'add notifications', 'notification preferences', 'bounce handling', 'complaint handling', 'suppression list', 'delivery log', 'notification channels', 'digest batching', 'quiet hours', 'webhook ingestion', 'SES bounces', 'SendGrid webhooks', 'channel deactivation', or when working with notifications_module in blueprints.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

constructive-io

constructive-io/constructive-skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Constructive Notifications

Multi-channel notification system with inbox, delivery tracking, bounce/complaint handling, address suppression, and digest batching.

When to Apply

Use this skill when:

Adding notifications to a Constructive app
Configuring notification channels (email, push, SMS, webhook)
Setting up bounce/complaint webhook handlers (SES, SendGrid, Twilio)
Working with the suppression list (blocking sends to hard-bounced/complained addresses)
Implementing notification preferences, quiet hours, or digest batching
Debugging delivery failures or channel deactivation
Understanding the notification table graph and delivery lifecycle

Module Setup

Include notifications_module in your module list. The full preset includes it by default.

import { getModulePreset } from '@constructive-io/node-type-registry';

// Option A: use a preset that includes it
const preset = getModulePreset('full');

// Option B: add it explicitly
const modules = [...baseModules, 'notifications_module'];

Feature Flags

Control which sub-features are generated (zero dead code when off):

Flag	Default	What it gates
`has_channels`	`true`	Device endpoints, delivery log, suppression list
`has_preferences`	`true`	Per-user channel toggles by category/topic
`has_settings_extension`	`false`	Quiet hours, digest frequency, master switch on user/org settings
`has_digest_metadata`	`false`	Group collapsing, digest buckets, deliver_after scheduling
`has_subscriptions`	`false`	(reserved for future topic subscription table)

Table Graph

notifications_module (config)
├── notifications              (public, RLS: AuthzComposite)
│   └── notification_read_state (public, RLS: AuthzDirectOwner)
├── notification_preferences    (public, RLS: AuthzDirectOwner) [has_preferences]
├── notification_channels       (public, RLS: AuthzDirectOwner) [has_channels]
├── notification_delivery_log   (private, no RLS)               [has_channels]
└── notification_suppressions   (private, no RLS)               [has_channels]

Public tables are exposed via GraphQL with RLS. Private tables (delivery_log, suppressions) are internal — your delivery worker and webhook handlers interact with them directly via SQL.

Delivery Status Lifecycle

pending → sent → delivered
                → bounced      (async webhook, hard/soft bounce)
                → complained   (async webhook, recipient marked as spam)
           → failed            (immediate failure)
           → throttled         (rate-limited by provider)
→ grouped                      (collapsed into digest)

Key distinction: bounced (mailbox doesn't exist) and complained (recipient clicked "Report Spam") are different signals requiring different responses. Both create suppression entries, but complaint rates > 0.1% trigger ISP penalties.

References

File	Content
deliverability.md	Webhook setup (SES/SendGrid/Twilio), suppression management, channel deactivation, monitoring queries
tables.md	All 6 tables with columns, types, defaults, and descriptions

Cross-References

SQL-level generator internals: constructive-db-notifications skill in constructive-db
Realtime subscriptions (separate system): constructive-realtime
Background job triggers: constructive-jobs
Billing/limits for rate caps: constructive-billing

このリポジトリの他の Skills

同じリポジトリ

constructive-blueprints

constructive-io/constructive-skills

Declarative schema definition — blueprints, node type registry, presets, and the blueprint definition format. Use when asked to 'create a blueprint', 'blueprint template', 'construct blueprint', 'copy template', 'blueprint definition', 'definition hash', 'table hashes', 'schema marketplace', 'blueprint provisioning', 'module presets', 'what modules should I install', 'auth:email preset', 'b2b preset', or when working with blueprint JSONB definitions.

2026-07-120

constructive-features

constructive-io/constructive-skills

Feature catalog for Constructive apps — one scannable index of every capability (auth methods, authorization, multi-tenancy, data modeling, storage, search, AI, GraphQL, ops) with pointers to the authoritative skill or toggle that owns it. Use when asked "what can a Constructive app do", "what features are available", "which skill covers X", "is there built-in support for Y", "how do I enable read-only mode / magic links / passkeys / SSO / pgvector / search / uploads", or when orienting to the platform for the first time.

2026-07-120

constructive-security

constructive-io/constructive-skills

Authorization — Safegres protocol, 23 Authz* policy types, RLS, grants, permissions, permission defaults, GuardStepUp, read-only access, storage policies, and the secureTableProvision workflow. Use when asked to 'add security', 'RLS', 'grants', 'policies', 'Safegres', 'Authz*', 'AuthzEntityMembership', 'AuthzDirectOwner', 'AuthzMemberOwner', 'AuthzComposite', 'AuthzSystemOnly', 'AuthzHumanOnly', 'AuthzValueAllowed', 'AuthzValueExists', 'AuthzValueMatch', 'system-only policy', 'system-only writes', 'human-only mutation', 'block agents from writing', 'read-only mode', 'secure table provision', 'storage policies', 'bucket security', 'permission model', 'permission defaults', 'default_permissions', 'GuardStepUp', 'step-up auth', 'guard step-up', 'require step-up', 'MFA guard', 'named permissions', or when working with authorization in blueprints or the ORM.

2026-07-120

constructive-builder

constructive-io/constructive-skills

Build a Constructive app end-to-end from a brief. Use when asked to build/scaffold an app on Constructive, create a CRUD app, provision a data model with RLS, wire Blocks + auth flows, or verify an app with Chrome QA / agent-browser — keep time-to-app under 10 minutes on a warm hub. Drives the four mainline phases (1 Backend Up, 2 Data Model Provisioned, 3 Frontend + SDK, 4 UI / Blocks) and supports the three policy tiers: owner-scoped, public-read + owner-write, and b2b org-membership. Triggers: "build a Constructive app", "scaffold an app on Constructive", "provision a data model with RLS", "wire Blocks and auth flows", "verify the app with agent-browser". Builds ANY CRUD app generically from a brief — it is NOT for editing the Constructive platform itself (constructive / constructive-db).

2026-07-040

constructive-agents

constructive-io/constructive-skills

AI — agent module, LLM providers, RAG pipelines, embeddings, agentic-kit multi-provider client, Search* blueprint nodes (SearchUnified, SearchVector), ProcessFileEmbedding/ProcessImageEmbedding/ProcessChunks. Use when asked to 'add AI search', 'build RAG pipeline', 'embedding worker', 'agentic-kit', 'LLM integration', 'Ollama', 'Anthropic', 'OpenAI', 'file embedding', 'image embedding', 'chunking', 'SearchUnified', 'SearchVector', 'multiplayer agents', 'shared agents', 'multi-agent', 'agent_id', or when working with AI features in blueprints.

2026-07-040

constructive-auth

constructive-io/constructive-skills

Identity, login, sessions, MFA, devices, identity linking — auth flow (sign-up/sign-in/JWT), auth settings (MFA, anonymous sessions, CAPTCHA, cookie auth, rate limits), device settings (tracking, trusted devices, approval gate), identity linking (link_identity, account collision resolution, allow_link_by_email, primary auth method), and service-level auth config. Use when asked to 'sign up', 'sign in', 'auth flow', 'MFA', 'magic link', 'passkeys', 'device approval', 'trusted devices', 'session management', 'cookie auth', 'anonymous sessions', 'CAPTCHA', 'rate limits', 'bootstrap user', 'JWT', 'link identity', 'identity linking', 'account collision', 'allow_link_by_email', 'primary auth method', 'connected accounts', or when working with authentication.

2026-07-040

name	constructive-notifications
description	Notification system — inbox, delivery, channels, preferences, bounce/complaint handling, suppression list, and digest batching. Use when asked to 'add notifications', 'notification preferences', 'bounce handling', 'complaint handling', 'suppression list', 'delivery log', 'notification channels', 'digest batching', 'quiet hours', 'webhook ingestion', 'SES bounces', 'SendGrid webhooks', 'channel deactivation', or when working with notifications_module in blueprints.
metadata	{"author":"constructive-io","version":"1.0.0"}

Constructive Notifications

Multi-channel notification system with inbox, delivery tracking, bounce/complaint handling, address suppression, and digest batching.

When to Apply

Use this skill when:

Adding notifications to a Constructive app
Configuring notification channels (email, push, SMS, webhook)
Setting up bounce/complaint webhook handlers (SES, SendGrid, Twilio)
Working with the suppression list (blocking sends to hard-bounced/complained addresses)
Implementing notification preferences, quiet hours, or digest batching
Debugging delivery failures or channel deactivation
Understanding the notification table graph and delivery lifecycle

Module Setup

Include notifications_module in your module list. The full preset includes it by default.

import { getModulePreset } from '@constructive-io/node-type-registry';

// Option A: use a preset that includes it
const preset = getModulePreset('full');

// Option B: add it explicitly
const modules = [...baseModules, 'notifications_module'];

Feature Flags

Control which sub-features are generated (zero dead code when off):

Flag	Default	What it gates
`has_channels`	`true`	Device endpoints, delivery log, suppression list
`has_preferences`	`true`	Per-user channel toggles by category/topic
`has_settings_extension`	`false`	Quiet hours, digest frequency, master switch on user/org settings
`has_digest_metadata`	`false`	Group collapsing, digest buckets, deliver_after scheduling
`has_subscriptions`	`false`	(reserved for future topic subscription table)

Table Graph

notifications_module (config)
├── notifications              (public, RLS: AuthzComposite)
│   └── notification_read_state (public, RLS: AuthzDirectOwner)
├── notification_preferences    (public, RLS: AuthzDirectOwner) [has_preferences]
├── notification_channels       (public, RLS: AuthzDirectOwner) [has_channels]
├── notification_delivery_log   (private, no RLS)               [has_channels]
└── notification_suppressions   (private, no RLS)               [has_channels]

Public tables are exposed via GraphQL with RLS. Private tables (delivery_log, suppressions) are internal — your delivery worker and webhook handlers interact with them directly via SQL.

Delivery Status Lifecycle

pending → sent → delivered
                → bounced      (async webhook, hard/soft bounce)
                → complained   (async webhook, recipient marked as spam)
           → failed            (immediate failure)
           → throttled         (rate-limited by provider)
→ grouped                      (collapsed into digest)

References

File	Content
deliverability.md	Webhook setup (SES/SendGrid/Twilio), suppression management, channel deactivation, monitoring queries
tables.md	All 6 tables with columns, types, defaults, and descriptions

Cross-References

SQL-level generator internals: constructive-db-notifications skill in constructive-db
Realtime subscriptions (separate system): constructive-realtime
Background job triggers: constructive-jobs
Billing/limits for rate caps: constructive-billing