بنقرة واحدة
uw-analyze-messaging
Use when analyzing event-driven systems, message queues, async processing, and pub/sub patterns
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Use when analyzing event-driven systems, message queues, async processing, and pub/sub patterns
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | uw-analyze-messaging |
| description | Use when analyzing event-driven systems, message queues, async processing, and pub/sub patterns |
| allowed-tools | ["Read","Grep","Glob","Bash(mkdir:*, ls:*)","Write(docs/unwind/**)","Edit(docs/unwind/**)"] |
Output: docs/unwind/layers/messaging/ (folder with index.md + section files)
Principles: See analysis-principles.md - completeness, machine-readable, link to source, no commentary, incremental writes.
docs/unwind/layers/messaging/
├── index.md # Topic overview, event flow diagram
├── events.md # Event definitions & schemas
├── producers.md # Message producers
└── consumers.md # Message consumers with retry config
For large codebases (10+ topics), split by topic:
docs/unwind/layers/messaging/
├── index.md
├── order-events.md
├── user-events.md
└── ...
Step 1: Setup
mkdir -p docs/unwind/layers/messaging/
Write initial index.md:
# Messaging Layer
## Sections
- [Events](events.md) - _pending_
- [Producers](producers.md) - _pending_
- [Consumers](consumers.md) - _pending_
## Topics
_Analysis in progress..._
Step 2: Analyze and write events.md
events.md immediatelyindex.mdStep 3: Analyze and write producers.md
producers.md immediatelyindex.mdStep 4: Analyze and write consumers.md
consumers.md immediatelyindex.mdStep 5: Finalize index.md Add topic table and event flow diagram
# Messaging Layer
## Configuration
[KafkaConfig.java](https://github.com/owner/repo/blob/main/src/config/KafkaConfig.java)
```java
@Configuration
public class KafkaConfig {
@Value("${kafka.bootstrap-servers}")
private String bootstrapServers;
@Bean
public ProducerFactory<String, Object> producerFactory() {
Map<String, Object> config = new HashMap<>();
config.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
config.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
config.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, JsonSerializer.class);
return new DefaultKafkaProducerFactory<>(config);
}
}
| Topic | Partitions | Producers | Consumers |
|---|---|---|---|
| order-events | 6 | OrderService | NotificationService, AnalyticsService |
| user-events | 3 | UserService | EmailService |
public record OrderCreatedEvent(
String eventId,
Instant timestamp,
Long orderId,
Long userId,
List<OrderItemDto> items,
BigDecimal total
) {}
JSON Schema:
{
"type": "object",
"properties": {
"eventId": { "type": "string", "format": "uuid" },
"timestamp": { "type": "string", "format": "date-time" },
"orderId": { "type": "integer" },
"userId": { "type": "integer" },
"items": { "type": "array" },
"total": { "type": "number" }
},
"required": ["eventId", "timestamp", "orderId", "userId", "total"]
}
[Continue for ALL events...]
@Component
@RequiredArgsConstructor
public class OrderEventPublisher {
private final KafkaTemplate<String, Object> kafkaTemplate;
public void publishOrderCreated(Order order) {
OrderCreatedEvent event = new OrderCreatedEvent(
UUID.randomUUID().toString(),
Instant.now(),
order.getId(),
order.getUser().getId(),
mapItems(order.getItems()),
order.getTotal()
);
kafkaTemplate.send("order-events", order.getId().toString(), event);
}
}
NotificationEventConsumer.java
@Component
@RequiredArgsConstructor
public class NotificationEventConsumer {
private final NotificationService notificationService;
@KafkaListener(topics = "order-events", groupId = "notification-service")
@Retryable(maxAttempts = 3)
public void handleOrderEvent(OrderCreatedEvent event) {
notificationService.sendOrderConfirmation(event.orderId());
}
@DltHandler
public void handleDlt(OrderCreatedEvent event) {
log.error("Failed to process event after retries: {}", event.eventId());
}
}
[Continue for ALL consumers...]
graph LR
OrderService -->|publish| order-events
order-events -->|consume| NotificationService
order-events -->|consume| AnalyticsService
UserService -->|publish| user-events
user-events -->|consume| EmailService
## Mandatory Tagging
**Every event, producer, consumer, and handler must have a [MUST], [SHOULD], or [DON'T] tag in its heading.**
Default categorizations for messaging layer:
- **[MUST]**: Event schemas, core producers, core consumers, webhook handlers
- **[SHOULD]**: Scheduled jobs, retry logic, dead letter handling
- **[DON'T]**: Message broker configuration, serialization config
Example:
```markdown
### OrderCreatedEvent [MUST]
### OrderEventPublisher [MUST]
### DailyResetJob [SHOULD]
### KafkaConfig [DON'T]
See analysis-principles.md section 9 for full tagging rules.
If docs/unwind/layers/messaging/ exists, compare current state and add ## Changes Since Last Review section to index.md.
Use after unwind:uw-plan to EXECUTE the rebuild — interview the user about scope/order/target, dispatch technology-agnostic per-layer builder agents that reproduce the [MUST] contracts in the target stack, hold rebuild state in a local file, and maintain a source→target verification graph that measures completeness. Supports a loop-until-verified mode.
Use to visually explore the rebuild knowledge graph. Builds and launches the Unwind dashboard (React + React Flow + ELK) pointed at docs/unwind/rebuild-graph.json with coverage, priority, and contract views.
Optional. Publish the Unwind dashboard to the scanned project's GitHub Pages gh-pages branch so it's viewable at https://<owner>.github.io/<repo>/unwind/. Builds the dashboard at the correct sub-path and commits it into an `unwind/` subdir — never blatting an existing gh-pages branch. Confirms the target, then pushes.
Use when dispatched by unwind:uw-build to rebuild ONE layer/slice of a codebase in the target stack. Technology-agnostic builder that reproduces the layer's [MUST] contracts (API surface, data model, business rules) as idiomatic target-stack code and records the source→target mapping for verification.
Use when starting any reverse engineering task - establishes how to find and use Unwind skills for codebase analysis, service mapping, and documentation
Use after layer analysis is complete to interview the user about the rebuild strategy (target stack, what to keep vs rebuild, phasing, risk) and generate a data-grounded REBUILD-PLAN.md that records those decisions.