Event Style Guide
Skill Profile
(Select at least one profile to enable specific modules)
Overview
Event-driven design conventions: event envelope, naming, versioning, and schema evolution rules that enable safe system decoupling.
Why This Matters
- Interoperability: All services understand same event format
- Evolution: Change schema without breaking consumers
- Debugging: Trace events across services
- Contract: Clear agreement between producers/consumers
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
Quick Start
Assumptions
- Event-driven architecture in use
- Message broker available (Kafka, RabbitMQ, etc.)
- Schema registry for event definitions
- Multiple services producing/consuming events
- Need for schema evolution without breaking changes
Compatibility
- CloudEvents: 1.0 spec
- Kafka: 2.8+
- RabbitMQ: 3.9+
- Schema Registry: Confluent 7.0+
- TypeScript: 4.5+
Test Scenario Matrix
| Scenario |
Input |
Expected Output |
Verification |
| Create event |
Domain event data |
Valid event envelope |
Schema validation |
| Version change |
Breaking schema change |
New version event |
Version in type |
| Consumer receives |
Event from broker |
Processed idempotently |
No duplicate processing |
| Schema evolution |
New optional field |
Old consumers still work |
Backward compatibility |
| Retry failure |
Non-retryable error |
Sent to DLQ |
DLQ inspection |
Technical Guardrails
Agent Directives & Error Recovery
(ข้อกำหนดสำหรับ AI Agent ในการคิดและแก้ปัญหาเมื่อเกิดข้อผิดพลาด)
- Thinking Process: Analyze root cause before fixing. Do not brute-force.
- Fallback Strategy: Stop after 3 failed test attempts. Output root cause and ask for human intervention/clarification.
- Self-Review: Check against Guardrails & Anti-patterns before finalizing.
- Output Constraints: Output ONLY the modified code block. Do not explain unless asked.
Definition of Done
An event is complete when:
Anti-patterns
- No versioning: Can't evolve schemas
- Massive payloads: Events too large
- Missing correlation: Can't trace flows
- Shared events: Tight coupling between services
- Hidden contracts: Schema in code but no registry/docs
- No idempotency: Duplicate processing causes issues
- Breaking changes without version: Breaks consumers
- Mixed metadata: Metadata in payload instead of envelope
Reference Links
Versioning & Changelog
- Version: 1.0.0
- Changelog:
- 2026-02-22: Initial version with complete template structure
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: amnadtaowsoam-cerebraskills-event-style-guide3description: Event Style Guide4---56# Event Style Guide78## Skill Profile9*(Select at least one profile to enable specific modules)*10- [ ] **DevOps**11- [x] **Backend**12- [ ] **Frontend**13- [ ] **AI-RAG**14- [ ] **Security Critical**1516## Overview17Event-driven design conventions: event envelope, naming, versioning, and schema evolution rules that enable safe system decoupling.1819## Why This Matters20- **Interoperability**: All services understand same event format21- **Evolution**: Change schema without breaking consumers22- **Debugging**: Trace events across services23- **Contract**: Clear agreement between producers/consumers2425## Core Concepts & Rules2627### 1. Core Principles28- Follow established patterns and conventions29- Maintain consistency across codebase30- Document decisions and trade-offs3132### 2. Implementation Guidelines33- Start with the simplest viable solution34- Iterate based on feedback and requirements35- Test thoroughly before deployment363738## Inputs / Outputs / Contracts39* **Inputs**:40 - <e.g., env vars, request payload, file paths, schema>41* **Entry Conditions**:42 - <Pre-requisites: e.g., Repo initialized, DB running, specific branch checked out>43* **Outputs**:44 - <e.g., artifacts (PR diff, docs, tests, dashboard JSON)>45* **Artifacts Required (Deliverables)**:46 - <e.g., Code Diff, Unit Tests, Migration Script, API Docs>47* **Acceptance Evidence**:48 - <e.g., Test Report (screenshot/log), Benchmark Result, Security Scan Report>49* **Success Criteria**:50 - <e.g., p95 < 300ms, coverage ≥ 80%>5152## Skill Composition53* **Depends on**: [api-style-guide](./api-style-guide/SKILL.md), [logging-metrics-tracing-standard](./logging-metrics-tracing-standard/SKILL.md)54* **Compatible with**: [service-standards-blueprint](./service-standards-blueprint/SKILL.md), [messaging-queue](../../08-messaging-queue/)55* **Conflicts with**: None56* **Related Skills**: [event-contract-generator](../67-codegen-scaffolding-automation/event-contract-generator/SKILL.md), [distributed-tracing](../../14-monitoring-observability/distributed-tracing/SKILL.md)5758## Quick Start59#6061## Assumptions62- Event-driven architecture in use63- Message broker available (Kafka, RabbitMQ, etc.)64- Schema registry for event definitions65- Multiple services producing/consuming events66- Need for schema evolution without breaking changes6768## Compatibility69- **CloudEvents**: 1.0 spec70- **Kafka**: 2.8+71- **RabbitMQ**: 3.9+72- **Schema Registry**: Confluent 7.0+73- **TypeScript**: 4.5+7475## Test Scenario Matrix76| Scenario | Input | Expected Output | Verification |77|----------|-------|-----------------|--------------|78| Create event | Domain event data | Valid event envelope | Schema validation |79| Version change | Breaking schema change | New version event | Version in type |80| Consumer receives | Event from broker | Processed idempotently | No duplicate processing |81| Schema evolution | New optional field | Old consumers still work | Backward compatibility |82| Retry failure | Non-retryable error | Sent to DLQ | DLQ inspection |8384## Technical Guardrails85#8687## Agent Directives & Error Recovery88*(ข้อกำหนดสำหรับ AI Agent ในการคิดและแก้ปัญหาเมื่อเกิดข้อผิดพลาด)*8990- **Thinking Process**: Analyze root cause before fixing. Do not brute-force.91- **Fallback Strategy**: Stop after 3 failed test attempts. Output root cause and ask for human intervention/clarification.92- **Self-Review**: Check against Guardrails & Anti-patterns before finalizing.93- **Output Constraints**: Output ONLY the modified code block. Do not explain unless asked.949596## Definition of Done97An event is complete when:9899- [ ] Event follows envelope standard100- [ ] Event naming follows convention101- [ ] Version included in event type102- [ ] Schema registered in registry103- [ ] Correlation ID present104- [ ] Unique event ID (UUID v4)105- [ ] Consumer implements idempotency106- [ ] Dead letter handling configured107- [ ] Documentation complete108- [ ] Examples provided109110## Anti-patterns1111. **No versioning**: Can't evolve schemas1122. **Massive payloads**: Events too large1133. **Missing correlation**: Can't trace flows1144. **Shared events**: Tight coupling between services1155. **Hidden contracts**: Schema in code but no registry/docs1166. **No idempotency**: Duplicate processing causes issues1177. **Breaking changes without version**: Breaks consumers1188. **Mixed metadata**: Metadata in payload instead of envelope119120## Reference Links121- [CloudEvents Specification](https://cloudevents.io/)122- [Event-Driven Architecture Patterns](https://www.confluent.io/blog/)123- [Schema Evolution Best Practices](https://docs.confluent.io/platform/current/schema-registry/)124- [Kafka Documentation](https://kafka.apache.org/documentation/)125- [RabbitMQ Tutorials](https://www.rabbitmq.com/tutorials.html)126127## Versioning & Changelog128129* **Version**: 1.0.0130* **Changelog**:131 - 2026-02-22: Initial version with complete template structure132133---134> Converted and distributed by [TomeVault](https://tomevault.io/claim/amnadtaowsoam) — claim your Tome and manage your conversions.135<!-- tomevault:4.0:skill_md:2026-04-13 -->