Notification System
Skill Profile
(Select at least one profile to enable specific modules)
Overview
A notification system delivers messages to users through various channels. This skill covers notification types (email, SMS, push, in-app), service integration (SendGrid/AWS SES, Twilio, Firebase), template management, notification preferences, queue-based delivery, retry logic, delivery tracking, rate limiting, testing, and best practices.
Why This Matters
Notification systems are critical for:
- User Engagement: Keep users informed and engaged
- Operational Reliability: Ensure messages are delivered reliably
- User Experience: Respect user preferences for channels and timing
- Cost Efficiency: Optimize delivery costs through queueing and batching
- Compliance: Meet regulatory requirements for transactional communications
- Analytics: Track delivery rates and user engagement
Poor notification system implementation leads to:
- Missed or delayed notifications
- Spamming users who opted out
- High delivery costs from inefficient sending
- Poor user experience from inconsistent messaging
- Inability to troubleshoot delivery issues
Core Concepts & Rules
1. Core Principles
- Follow established patterns and conventions
- Maintain consistency across codebase
- Document decisions and trade-offs
2. Implementation Guidelines
- Start with the simplest viable solution
- Iterate based on feedback and requirements
- Test thoroughly before deployment
Inputs / Outputs / Contracts
- Inputs:
- <e.g., env vars, request payload, file paths, schema>
- Entry Conditions:
- <Pre-requisites: e.g., Repo initialized, DB running, specific branch checked out>
- Outputs:
- <e.g., artifacts (PR diff, docs, tests, dashboard JSON)>
- Artifacts Required (Deliverables):
- <e.g., Code Diff, Unit Tests, Migration Script, API Docs>
- Acceptance Evidence:
- <e.g., Test Report (screenshot/log), Benchmark Result, Security Scan Report>
- Success Criteria:
- <e.g., p95 < 300ms, coverage ≥ 80%>
Skill Composition
- Depends on: None
- Compatible with: None
- Conflicts with: None
- Related Skills: None
Quick Start
Assumptions
- Third-party services (SendGrid, Twilio, Firebase) are available
- Redis or similar queue system is available
- User contact information is validated
- Templates are designed and tested
- Webhooks are configured for delivery tracking
Compatibility
- Works with all email providers (SendGrid, AWS SES, Mailgun)
- Compatible with all SMS providers (Twilio, Nexmo, Plivo)
- Supports all push providers (FCM, APNs, OneSignal)
- Works with all backend frameworks
- Compatible with all queue systems
Test Scenario Matrix (QA Strategy)
| Type |
Focus Area |
Required Scenarios / Mocks |
| Unit |
Core Logic |
Must cover primary logic and at least 3 edge/error cases. Target minimum 80% coverage |
| Integration |
DB / API |
All external API calls or database connections must be mocked during unit tests |
| E2E |
User Journey |
Critical user flows to test |
| Performance |
Latency / Load |
Benchmark requirements |
| Security |
Vuln / Auth |
SAST/DAST or dependency audit |
| Frontend |
UX / A11y |
Accessibility checklist (WCAG), Performance Budget (Lighthouse score) |
Technical Guardrails & Security Threat Model
1. Security & Privacy (Threat Model)
- Top Threats: Injection attacks, authentication bypass, data exposure
2. Performance & Resources
3. Architecture & Scalability
4. Observability & Reliability
Agent Directives
When Sending Notifications:
- Check user preferences for channel and type
- Render template with user-specific data
- Create notification record
- Enqueue for delivery
- Track delivery status
- Handle failures with retry logic
When Managing Templates:
- Design responsive templates
- Test on multiple devices and email clients
- Validate all variables are used
- Document template variables
- Version templates for changes
When Handling Bounces:
- Identify reason for bounce
- Update user contact information
- Disable invalid contacts
- Track bounce metrics
- Investigate if bounce rate is high
Definition of Done (DoD) Checklist
Anti-patterns
Ignoring User Preferences
- Sending to disabled channels
- Ignoring opt-out requests
- Sending unwanted notifications
No Retry Logic
- Failing on transient errors
- Not retrying failed deliveries
- Poor delivery rates
Hardcoding Content
- Not using templates
- Inconsistent messaging
- Difficult to maintain
No Delivery Tracking
- Can't measure success rates
- Can't troubleshoot issues
- Poor user experience
Reference Links & Examples
- Internal documentation and examples
- Official documentation and best practices
- Community resources and discussions
Versioning & Changelog
- Version: 1.0.0
- Changelog:
- 2026-02-22: Initial version with complete template structure
1---2name: notification-system-23description: A notification system delivers messages to users through various channels. This skill covers notification types (email, SMS, push, in-app), service integration (SendGrid/AWS SES, Twilio, Firebase), te4---5
6# Notification System
7
8## Skill Profile
9*(Select at least one profile to enable specific modules)*
10- [ ] **DevOps**
11- [x] **Backend**
12- [ ] **Frontend**
13- [ ] **AI-RAG**
14- [ ] **Security Critical**
15
16## Overview
17A notification system delivers messages to users through various channels. This skill covers notification types (email, SMS, push, in-app), service integration (SendGrid/AWS SES, Twilio, Firebase), template management, notification preferences, queue-based delivery, retry logic, delivery tracking, rate limiting, testing, and best practices.
18
19## Why This Matters
20Notification systems are critical for:
21
22- **User Engagement**: Keep users informed and engaged
23- **Operational Reliability**: Ensure messages are delivered reliably
24- **User Experience**: Respect user preferences for channels and timing
25- **Cost Efficiency**: Optimize delivery costs through queueing and batching
26- **Compliance**: Meet regulatory requirements for transactional communications
27- **Analytics**: Track delivery rates and user engagement
28
29Poor notification system implementation leads to:
30- Missed or delayed notifications
31- Spamming users who opted out
32- High delivery costs from inefficient sending
33- Poor user experience from inconsistent messaging
34- Inability to troubleshoot delivery issues
35
36## Core Concepts & Rules
37
38### 1. Core Principles
39- Follow established patterns and conventions
40- Maintain consistency across codebase
41- Document decisions and trade-offs
42
43### 2. Implementation Guidelines
44- Start with the simplest viable solution
45- Iterate based on feedback and requirements
46- Test thoroughly before deployment
47
48
49## Inputs / Outputs / Contracts
50* **Inputs**:
51 - <e.g., env vars, request payload, file paths, schema>
52* **Entry Conditions**:
53 - <Pre-requisites: e.g., Repo initialized, DB running, specific branch checked out>
54* **Outputs**:
55 - <e.g., artifacts (PR diff, docs, tests, dashboard JSON)>
56* **Artifacts Required (Deliverables)**:
57 - <e.g., Code Diff, Unit Tests, Migration Script, API Docs>
58* **Acceptance Evidence**:
59 - <e.g., Test Report (screenshot/log), Benchmark Result, Security Scan Report>
60* **Success Criteria**:
61 - <e.g., p95 < 300ms, coverage ≥ 80%>
62
63## Skill Composition
64* **Depends on**: None
65* **Compatible with**: None
66* **Conflicts with**: None
67* **Related Skills**: None
68
69## Quick Start
70#
71
72## Assumptions
73- Third-party services (SendGrid, Twilio, Firebase) are available
74- Redis or similar queue system is available
75- User contact information is validated
76- Templates are designed and tested
77- Webhooks are configured for delivery tracking
78
79## Compatibility
80- Works with all email providers (SendGrid, AWS SES, Mailgun)
81- Compatible with all SMS providers (Twilio, Nexmo, Plivo)
82- Supports all push providers (FCM, APNs, OneSignal)
83- Works with all backend frameworks
84- Compatible with all queue systems
85
86## Test Scenario Matrix (QA Strategy)
87
88| Type | Focus Area | Required Scenarios / Mocks |
89| :--- | :--- | :--- |
90| **Unit** | Core Logic | Must cover primary logic and at least 3 edge/error cases. Target minimum 80% coverage |
91| **Integration** | DB / API | All external API calls or database connections must be mocked during unit tests |
92| **E2E** | User Journey | Critical user flows to test |
93| **Performance** | Latency / Load | Benchmark requirements |
94| **Security** | Vuln / Auth | SAST/DAST or dependency audit |
95| **Frontend** | UX / A11y | Accessibility checklist (WCAG), Performance Budget (Lighthouse score) |
96
97
98## Technical Guardrails & Security Threat Model
99
100### 1. Security & Privacy (Threat Model)
101* **Top Threats**: Injection attacks, authentication bypass, data exposure
102- [ ] **Data Handling**: Sanitize all user inputs to prevent Injection attacks. Never log raw PII
103- [ ] **Secrets Management**: No hardcoded API keys. Use Env Vars/Secrets Manager
104- [ ] **Authorization**: Validate user permissions before state changes
105
106### 2. Performance & Resources
107- [ ] **Execution Efficiency**: Consider time complexity for algorithms
108- [ ] **Memory Management**: Use streams/pagination for large data
109- [ ] **Resource Cleanup**: Close DB connections/file handlers in finally blocks
110
111### 3. Architecture & Scalability
112- [ ] **Design Pattern**: Follow SOLID principles, use Dependency Injection
113- [ ] **Modularity**: Decouple logic from UI/Frameworks
114
115### 4. Observability & Reliability
116- [ ] **Logging Standards**: Structured JSON, include trace IDs `request_id`
117- [ ] **Metrics**: Track `error_rate`, `latency`, `queue_depth`
118- [ ] **Error Handling**: Standardized error codes, no bare except
119- [ ] **Observability Artifacts**:
120 - **Log Fields**: timestamp, level, message, request_id
121 - **Metrics**: request_count, error_count, response_time
122 - **Dashboards/Alerts**: High Error Rate > 5%
123
124
125## Agent Directives
126**When Sending Notifications:**
1271. Check user preferences for channel and type
1282. Render template with user-specific data
1293. Create notification record
1304. Enqueue for delivery
1315. Track delivery status
1326. Handle failures with retry logic
133
134**When Managing Templates:**
1351. Design responsive templates
1362. Test on multiple devices and email clients
1373. Validate all variables are used
1384. Document template variables
1395. Version templates for changes
140
141**When Handling Bounces:**
1421. Identify reason for bounce
1432. Update user contact information
1443. Disable invalid contacts
1454. Track bounce metrics
1465. Investigate if bounce rate is high
147
148## Definition of Done (DoD) Checklist
149
150- [ ] Tests passed + coverage met
151- [ ] Lint/Typecheck passed
152- [ ] Logging/Metrics/Trace implemented
153- [ ] Security checks passed
154- [ ] Documentation/Changelog updated
155- [ ] Accessibility/Performance requirements met (if frontend)
156
157
158## Anti-patterns
159**Ignoring User Preferences**
160- Sending to disabled channels
161- Ignoring opt-out requests
162- Sending unwanted notifications
163
164**No Retry Logic**
165- Failing on transient errors
166- Not retrying failed deliveries
167- Poor delivery rates
168
169**Hardcoding Content**
170- Not using templates
171- Inconsistent messaging
172- Difficult to maintain
173
174**No Delivery Tracking**
175- Can't measure success rates
176- Can't troubleshoot issues
177- Poor user experience
178
179## Reference Links & Examples
180
181* Internal documentation and examples
182* Official documentation and best practices
183* Community resources and discussions
184
185
186## Versioning & Changelog
187
188* **Version**: 1.0.0
189* **Changelog**:
190 - 2026-02-22: Initial version with complete template structure
191