messaging-decision
Decide which messaging broker (RabbitMQ, Kafka, etc.) fits your requirements.
Install
mkdir -p .claude/skills/messaging-decision && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/18596" && unzip -o skill.zip -d .claude/skills/messaging-decision && rm skill.zipInstalls to .claude/skills/messaging-decision
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Decide whether a portfolio repository should use no broker, transactional outbox, RabbitMQ, Kafka/Redpanda, Redis Streams, or NATS based on delivery semantics, ordering, replay, retry/DLQ, throughput, and benchmark evidence.Key capabilities
- →Decide on messaging broker usage
- →Identify actual messaging needs
- →Choose one messaging mode and reject alternatives
- →Update `project.yaml` with messaging decision
- →Document topology and failure cases for selected broker
- →Add a benchmark to prove broker choice
How it works
This skill decides on the appropriate messaging broker by evaluating project needs against a messaging matrix. It selects a mode, documents the decision, and requires a benchmark to validate the choice.
Inputs & outputs
When to use messaging-decision
- →Choose messaging broker
- →Design event stream topology
- →Validate retry strategy
- →Implement transactional outbox
About this skill
Messaging Decision
Use a broker only when the problem needs broker semantics.
- Read
decision-brain/messaging-matrix.yamlor.portfolio/decision-brain/messaging-matrix.yaml. - Identify the actual messaging need: none, async reliability, work queue, routing, retry/DLQ, event log, replay, stream processing, fanout, or lightweight pub/sub.
- Choose one messaging mode and reject the alternatives.
- Update
project.yamlwithdecision_brain.messaging. - If a broker is selected, document topology and failure case in
sdd/technical-decision.md. - Add a benchmark that proves the broker choice: throughput, lag, retry success, lost messages under failure, or replay time.
Defaults:
- Use no broker when synchronous flow is enough.
- Use transactional outbox when reliability is needed but a broker is not central to the default proof.
- Use RabbitMQ for work queues, routing, acknowledgements, retries, DLQ, and task processing.
- Use Kafka or Redpanda for event streaming, durable logs, replay, partitions, CQRS projections, CDC, and high-throughput pipelines.
- Use Redis Streams only when Redis is already in the stack and lightweight stream semantics are enough.
- Use NATS only when lightweight pub/sub or request/reply is the core proof.
Rule: every broker choice must include rejected alternatives and a failure benchmark.
When not to use it
- →When synchronous flow is sufficient
- →When a broker is not central to the default proof for reliability
Limitations
- →Uses a broker only when the problem needs broker semantics
- →Every broker choice must include rejected alternatives
- →Every broker choice must include a failure benchmark
How it compares
This skill provides a structured, evidence-based approach to messaging broker selection, requiring explicit rejection of alternatives and a failure benchmark, unlike ad-hoc choices.
Compared to similar skills
messaging-decision side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| messaging-decision (this skill) | 0 | 18d | No flags | Advanced |
| product-map | 0 | 3mo | No flags | Intermediate |
| database-design | 6 | 6mo | Review | Intermediate |
| database-schema-designer | 6 | 6mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
product-map
esxr
Canonical enumeration of project Prisma models, API routes, components, user stories, and EIS docs. Use before creating any docs/wiki/ page to verify the source object exists. Triggers on "entities", "which prisma models", "list endpoints", "wiki bootstrap", "does <Entity> exist", "enumerate domain"
database-design
davila7
Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases.
database-schema-designer
davila7
Design robust, scalable database schemas for SQL and NoSQL databases. Provides normalization guidelines, indexing strategies, migration patterns, constraint design, and performance optimization. Ensures data integrity, query performance, and maintainable data models.
schema-designer
clidey
Help design database schemas, create tables, and plan data models. Activates when users ask to create tables, design schemas, or model data relationships.
community-feed
dadbodgeoff
Social feed with batch queries, cursor pagination, trending algorithms, and engagement tracking. Efficient database queries for infinite scroll feeds.
managing-database-sharding
jeremylongshore
Process use when you need to work with database sharding. This skill provides horizontal sharding strategies with comprehensive guidance and automation. Trigger with phrases like "implement sharding", "shard database", or "distribute data".