ClawHub

Event Driven

v1.0.0

Deep event-driven architecture workflow—events vs commands, ordering and idempotency, sagas, outbox pattern, observability, and failure modes. Use when desig...

⭐ 0· 196·1 current·1 all-time
by@mike47512

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for mike47512/event-driven.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "Event Driven" (mike47512/event-driven) from ClawHub.
Skill page: https://clawhub.ai/mike47512/event-driven
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install event-driven

ClawHub CLI

Package manager switcher

npx clawhub@latest install event-driven
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
✓
Purpose & Capability
Name and description match the SKILL.md content (architecture guidance for events, sagas, outbox, observability, failure modes). The skill declares no binaries, env vars, or installs — all proportional to a documentation/consulting skill.
✓
Instruction Scope
SKILL.md is high-level guidance and checklists for designing event-driven systems. It does not instruct the agent to read local files, access credentials, call external endpoints, or perform system changes.
✓
Install Mechanism
No install spec and no code files. Because nothing is written to disk or fetched at install time, install risk is minimal.
✓
Credentials
The skill requires no environment variables, credentials, or config paths — consistent with an advice-only skill.
✓
Persistence & Privilege
always is false and the skill is user-invocable. Model invocation is allowed (the normal default) but there are no elevated privileges or requests to modify other skills or system-wide settings.
Assessment
This skill is a safe, high-level design guide and presents low technical risk because it has no install steps, code, or credential requests. Before using it in production work, verify the content matches your organization's standards and run any resulting designs/recipes by your engineering team — the skill gives conceptual guidance but does not provide implementation or enforce correctness. Because the author/source is unknown, prefer manual review of any changes you apply based on its advice; if you later add automation or installer code, re-evaluate for install/credential risks.

Like a lobster shell, security has layers — review code before you run it.

latestvk973n22scgxa5fztpjr3s9v56d83js4v
196downloads
0stars
1versions
Updated 1mo ago
v1.0.0
MIT-0
@mike47512
latest
Download

Event-Driven Architecture

Event-driven design trades tight coupling for asynchronous workflows—and introduces ordering, duplicates, schema evolution, and distributed tracing challenges.

When to Offer This Workflow

Trigger conditions:

  • Replacing long chains of synchronous HTTP calls
  • Adopting Kafka, Pub/Sub, EventBridge, NATS, etc.
  • Need for sagas, compensating transactions, or cross-service workflows

Initial offer:

Use six stages: (1) identify events, (2) contracts & versioning, (3) delivery semantics, (4) orchestration vs choreography, (5) observability, (6) failure & replay). Assume at-least-once delivery unless proven otherwise.

Stage 1: Identify Events

Goal: Distinguish domain events (facts that happened) from commands (requests). Assign owning bounded context per event type.

Exit condition: Event catalog: name, schema, producers, consumers, SLAs.

Stage 2: Contracts & Versioning

Goal: Schema registry or equivalent; backward-compatible evolution; consumers ignore unknown fields; deprecation policy for old versions.

Stage 3: Delivery Semantics

Goal: Partition keys for per-entity ordering; idempotent consumers; dedupe keys when exactly-once illusion is needed.

Stage 4: Orchestration vs Choreography

Goal: Central orchestrator (saga coordinator) vs decentralized choreography—trade visibility vs coupling.

Practices

  • Transactional outbox when DB write and event publish must align

Stage 5: Observability

Goal: Correlation ids on events; traces spanning HTTP → broker → consumer; lag and DLQ depth metrics.

Stage 6: Failure & Replay

Goal: Dead-letter queues, replay tooling, poison message handling, and idempotent replays.

Final Review Checklist

  • Event inventory with clear ownership
  • Versioned contracts and compatibility rules
  • Idempotent consumers; partition strategy documented
  • Saga/outbox where transactional consistency required
  • Tracing and replay operationalized

Tips for Effective Guidance

  • Choreography can hide flows—document critical sequences as diagrams.
  • Pair with message-queues and idempotency for implementation detail.

Handling Deviations

  • Low volume: start with a simple queue before full Kafka topology.

Comments

Loading comments...