{"id":"e81bb1c2-9f9c-41fa-a713-923324ab2362","entityType":"agent","slug":"clawhub-athola-nm-archetypes-architecture-paradigm-event-driven","name":"architecture-paradigm-event-driven","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven","canonicalPath":"/agent/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven","generatedAt":"2026-10-10T03:21:39.615Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T00:30:29.988Z","emptyReason":null},"description":"Applies event-driven async messaging to decouple producers and consumers Skill: architecture-paradigm-event-driven Owner: athola Summary: Applies event-driven async messaging to decouple producers and consumers Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:07.630Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:04.541Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:28:53.527Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:01.434Z | user Release v1.9.16 v1.9.15 | 202","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.8K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-archetypes-architecture-paradigm-event-driven","sourceUrl":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-event-driven","homepage":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-event-driven","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":41,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Applies event-driven async messaging to decouple producers and consumers Skill: architecture-paradigm-event-driven Owner: athola Summary: Applies event-driven a"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:30:29.988Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:30:29.988Z","emptyReason":null},"stars":null,"forks":null,"downloads":1835,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.8K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:30:29.988Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T00:30:29.988Z","lastCrawledAt":"2026-10-10T00:30:29.988Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T00:30:29.988Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:05:07.630Z","changelog":"Release v1.9.19","fileCount":3,"zipByteSize":3557},{"version":"1.9.18","createdAt":"2026-08-15T21:29:04.541Z","changelog":"Release v1.9.18","fileCount":3,"zipByteSize":3749},{"version":"1.9.17","createdAt":"2026-07-30T05:28:53.527Z","changelog":"Release v1.9.17","fileCount":3,"zipByteSize":3651},{"version":"1.9.16","createdAt":"2026-07-14T19:46:01.434Z","changelog":"Release v1.9.16","fileCount":3,"zipByteSize":3593},{"version":"1.9.15","createdAt":"2026-07-04T21:20:11.805Z","changelog":"Release v1.9.15","fileCount":3,"zipByteSize":3577},{"version":"1.9.14","createdAt":"2026-06-30T17:50:45.842Z","changelog":"Release v1.9.14","fileCount":3,"zipByteSize":3717},{"version":"1.9.13","createdAt":"2026-06-27T16:15:18.378Z","changelog":"Release v1.9.13","fileCount":3,"zipByteSize":3479},{"version":"1.9.12","createdAt":"2026-06-19T03:08:36.933Z","changelog":"Release v1.9.12","fileCount":3,"zipByteSize":3718}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-archetypes-architecture-paradigm-event-driven","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T03:21:39.613Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-event-driven/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T00:30:29.988Z","emptyReason":null},"readme":"Skill: architecture-paradigm-event-driven\n\nOwner: athola\n\nSummary: Applies event-driven async messaging to decouple producers and consumers\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:05:07.630Z | user\n\nRelease v1.9.19\n\nv1.9.18 | 2026-08-15T21:29:04.541Z | user\n\nRelease v1.9.18\n\nv1.9.17 | 2026-07-30T05:28:53.527Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:46:01.434Z | user\n\nRelease v1.9.16\n\nv1.9.15 | 2026-07-04T21:20:11.805Z | user\n\nRelease v1.9.15\n\nv1.9.14 | 2026-06-30T17:50:45.842Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:15:18.378Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:08:36.933Z | user\n\nRelease v1.9.12\n\nv1.8.6 | 2026-06-07T21:22:36.833Z | user\n\nRelease v1.9.11\n\nv1.8.5 | 2026-05-09T02:15:19.959Z | user\n\nRelease v1.9.5\n\nv1.8.4 | 2026-05-06T14:15:04.113Z | user\n\nRelease v1.9.4\n\nv1.8.3 | 2026-04-10T05:45:31.807Z | user\n\nRelease v1.8.3\n\nv1.8.2 | 2026-04-06T22:06:49.969Z | user\n\nRelease v1.8.2\n\nvv1.8.2 | 2026-04-06T16:19:20.105Z | user\n\nRelease v1.8.2\n\nArchive index:\n\nArchive v1.9.19: 3 files, 3557 bytes\n\nFiles: skill-card.md (1851b), SKILL.md (4224b), _meta.json (168b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``message-broker`` -- Kafka, NATS, RabbitMQ; the durable channel between producers and consumers\n- ``event-stream-processor`` -- Flink, Faust, or similar; consumes streams and emits derived events\n- ``distributed-tracing`` -- OpenTelemetry-style correlation IDs across asynchronous hops\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749507630\n}\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nApplies event-driven async messaging to decouple producers and consumers.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and architects use this skill for guidance on when and how to apply event-driven architecture to asynchronous, loosely coupled, real-time, or multi-subscriber systems.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can activate for broad architecture terms.\n\nMitigation: Confirm the activation scope is appropriate before installing it in environments where general architecture prompts are common.\n\nRisk: Event-driven architecture guidance may be unsuitable for simple request-response systems or systems requiring strong transactional consistency.\n\nMitigation: Apply the skill only after checking the documented when-to-use and when-not-to-use conditions.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven)\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown guidance for architecture decisions, adoption steps, deliverables, and risks]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Does not run code or request sensitive access.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata; artifact frontmatter lists 1.9.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.18: 3 files, 3749 bytes\n\nFiles: skill-card.md (2280b), SKILL.md (4224b), _meta.json (168b)\n\nFile v1.9.18:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``message-broker`` -- Kafka, NATS, RabbitMQ; the durable channel between producers and consumers\n- ``event-stream-processor`` -- Flink, Faust, or similar; consumes streams and emits derived events\n- ``distributed-tracing`` -- OpenTelemetry-style correlation IDs across asynchronous hops\n\nFile v1.9.18:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.9.18\",\n  \"publishedAt\": 1786829344541\n}\n\nFile v1.9.18:skill-card.md\n\n## Description:\n\nApplies event-driven async messaging to decouple producers and consumers.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and architects use this skill to decide when event-driven architecture is appropriate and to plan event schemas, broker topology, failure handling, observability, and deliverables for loosely coupled asynchronous systems.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad architecture triggers may surface this skill in general architecture conversations where a more specific pattern is preferable.\n\nMitigation: Confirm that the system actually needs asynchronous, loosely coupled, or multi-subscriber behavior before applying the event-driven recommendations.\n\nRisk: Event-driven designs can create hidden coupling through undocumented event meanings or fields.\n\nMitigation: Use an event catalog or schema registry with clear ownership, versioning, and consumer-driven contract checks.\n\nRisk: Operational complexity can make failed or lagging consumers difficult to diagnose.\n\nMitigation: Plan observability, dead-letter queues, retry behavior, idempotent consumers, and replay procedures before production use.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven)\n- [Night Market archetypes source](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown, Configuration]\n\n**Output Format:** [Markdown prose with architecture recommendations, checklists, and risk mitigations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Documentation-only guidance; no code execution, data access, persistence, or privileged authority requested.]\n\n## Skill Version(s):\n\n1.9.18 (source: server release metadata; artifact frontmatter says 1.9.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 3 files, 3651 bytes\n\nFiles: skill-card.md (2144b), SKILL.md (4224b), _meta.json (168b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``message-broker`` -- Kafka, NATS, RabbitMQ; the durable channel between producers and consumers\n- ``event-stream-processor`` -- Flink, Faust, or similar; consumes streams and emits derived events\n- ``distributed-tracing`` -- OpenTelemetry-style correlation IDs across asynchronous hops\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785389333527\n}\n\nFile v1.9.17:skill-card.md\n\n## Description: <br>\nApplies event-driven async messaging to decouple producers and consumers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architects use this skill to decide when event-driven architecture fits a system and to plan async messaging, event schemas, broker topology, failure handling, and observability. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate in broad architecture, scalability, or resilience conversations and steer the agent toward event-driven patterns. <br>\nMitigation: Verify that loose coupling, asynchronous processing, and multi-subscriber event flow fit the project before adopting the recommendations. <br>\nRisk: Event-driven designs can add operational complexity around ordering, retries, dead-letter queues, schema changes, and observability. <br>\nMitigation: Require explicit event schemas, ownership, broker topology, idempotent consumers, failure handling, and monitoring before treating the guidance as implementation-ready. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven) <br>\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Guidance, Configuration] <br>\n**Output Format:** [Markdown guidance with structured sections and bullet lists] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Non-executable architecture guidance; no tools, API keys, or shell commands required.] <br>\n\n## Skill Version(s): <br>\n1.9.17 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.16: 3 files, 3593 bytes\n\nFiles: skill-card.md (2025b), SKILL.md (4224b), _meta.json (168b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``message-broker`` -- Kafka, NATS, RabbitMQ; the durable channel between producers and consumers\n- ``event-stream-processor`` -- Flink, Faust, or similar; consumes streams and emits derived events\n- ``distributed-tracing`` -- OpenTelemetry-style correlation IDs across asynchronous hops\n\nFile v1.9.16:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.9.16\",\n  \"publishedAt\": 1784058361434\n}\n\nFile v1.9.16:skill-card.md\n\n## Description: <br>\nApplies event-driven async messaging to decouple producers and consumers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architects use this skill to decide when to apply event-driven architecture and outline adoption steps for asynchronous, loosely coupled systems. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Architecture guidance can be incomplete or unsuitable for a specific production system. <br>\nMitigation: Review recommendations against system requirements, consistency needs, operational capacity, and security controls before adopting them. <br>\nRisk: Event-driven designs can introduce hidden coupling and operational complexity. <br>\nMitigation: Use event catalogs or schema registries, consumer-driven contract tests, observability, retry policies, and dead-letter handling when applying the guidance. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven) <br>\n- [Project homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown, Configuration guidance] <br>\n**Output Format:** [Markdown guidance with architecture recommendations and checklists] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [No executable tools, API calls, credential access, or file writes are evident from the reviewed artifact.] <br>\n\n## Skill Version(s): <br>\n1.9.16 (source: ClawHub release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.15: 3 files, 3577 bytes\n\nFiles: skill-card.md (2064b), SKILL.md (4224b), _meta.json (168b)\n\nFile v1.9.15:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``message-broker`` -- Kafka, NATS, RabbitMQ; the durable channel between producers and consumers\n- ``event-stream-processor`` -- Flink, Faust, or similar; consumes streams and emits derived events\n- ``distributed-tracing`` -- OpenTelemetry-style correlation IDs across asynchronous hops\n\nFile v1.9.15:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.9.15\",\n  \"publishedAt\": 1783200011805\n}\n\nFile v1.9.15:skill-card.md\n\n## Description: <br>\nApplies event-driven async messaging to decouple producers and consumers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architects use this skill to decide when event-driven architecture is appropriate and to plan event schemas, broker topology, failure handling, observability, and operational deliverables. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad architecture triggers may surface this skill when event-driven design is not appropriate. <br>\nMitigation: Apply the skill's 'When NOT To Use' guidance before adopting event-driven design, especially for simple request-response systems or workloads requiring strong transactional consistency. <br>\nRisk: Architecture recommendations can add operational complexity if adopted without a matching workload need. <br>\nMitigation: Review proposed event schemas, broker topology, failure handling, and observability plans against the target system before implementation. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven) <br>\n- [Project homepage from ClawHub metadata](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Architecture recommendations, adoption steps, deliverables, and risk mitigations.] <br>\n\n## Skill Version(s): <br>\n1.9.15 (source: ClawHub release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.14: 3 files, 3717 bytes\n\nFiles: skill-card.md (2287b), SKILL.md (4224b), _meta.json (168b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``message-broker`` -- Kafka, NATS, RabbitMQ; the durable channel between producers and consumers\n- ``event-stream-processor`` -- Flink, Faust, or similar; consumes streams and emits derived events\n- ``distributed-tracing`` -- OpenTelemetry-style correlation IDs across asynchronous hops\n\nFile v1.9.14:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.9.14\",\n  \"publishedAt\": 1782841845842\n}\n\nFile v1.9.14:skill-card.md\n\n## Description: <br>\nApplies event-driven async messaging to decouple producers and consumers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineers use this skill to evaluate event-driven architecture for asynchronous, loosely coupled systems, especially real-time, bursty, or multi-subscriber workloads. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may be invoked during broad architecture or scalability discussions where event-driven design is not the best fit. <br>\nMitigation: Confirm the workload needs asynchronous processing, loose coupling, or multi-subscriber event handling before applying its guidance. <br>\nRisk: Event-driven designs can create hidden coupling through undocumented event semantics or fields. <br>\nMitigation: Maintain a formal event catalog or schema registry and validate event schemas as part of architecture governance. <br>\nRisk: Operational complexity can make failed, delayed, or stuck consumers difficult to diagnose. <br>\nMitigation: Plan observability, dead-letter handling, retries, idempotent consumers, and consumer-lag monitoring before production use. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven) <br>\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown, Configuration] <br>\n**Output Format:** [Markdown prose with structured architecture recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only output; no commands, API calls, credentials, or file writes are produced by the skill itself.] <br>\n\n## Skill Version(s): <br>\n1.9.14 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.13: 3 files, 3479 bytes\n\nFiles: skill-card.md (1792b), SKILL.md (4224b), _meta.json (168b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``message-broker`` -- Kafka, NATS, RabbitMQ; the durable channel between producers and consumers\n- ``event-stream-processor`` -- Flink, Faust, or similar; consumes streams and emits derived events\n- ``distributed-tracing`` -- OpenTelemetry-style correlation IDs across asynchronous hops\n\nFile v1.9.13:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.9.13\",\n  \"publishedAt\": 1782576918378\n}\n\nFile v1.9.13:skill-card.md\n\n## Description: <br>\nApplies event-driven async messaging to decouple producers and consumers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architects use this skill to assess when event-driven architecture is appropriate and to plan adoption steps for asynchronous, loosely coupled systems. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate during unrelated architecture conversations and provide event-driven architecture guidance where it is not relevant. <br>\nMitigation: Disable the skill or narrow its triggers if it activates outside event-driven architecture decision work. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven) <br>\n- [Homepage metadata](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Guidance-only content for event-driven architecture decisions; no executable code, persistence, credential handling, or automatic actions are present in the artifact.] <br>\n\n## Skill Version(s): <br>\n1.9.13 (source: ClawHub release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.12: 3 files, 3718 bytes\n\nFiles: skill-card.md (2270b), SKILL.md (4224b), _meta.json (168b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``message-broker`` -- Kafka, NATS, RabbitMQ; the durable channel between producers and consumers\n- ``event-stream-processor`` -- Flink, Faust, or similar; consumes streams and emits derived events\n- ``distributed-tracing`` -- OpenTelemetry-style correlation IDs across asynchronous hops\n\nFile v1.9.12:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.9.12\",\n  \"publishedAt\": 1781838516933\n}\n\nFile v1.9.12:skill-card.md\n\n## Description: <br>\nApplies event-driven async messaging to decouple producers and consumers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architects use this skill for guidance on when and how to apply event-driven architecture, including event modeling, broker selection, failure handling, observability, and operational deliverables. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad architecture triggers may surface this skill for tasks that are not specifically about event-driven design. <br>\nMitigation: Confirm the task involves asynchronous messaging, pub/sub, brokers, event streams, or loose coupling before applying its recommendations. <br>\nRisk: Event-driven systems can create hidden coupling through undocumented event semantics or fields. <br>\nMitigation: Maintain an event catalog or schema registry and validate event contracts before implementation. <br>\nRisk: Asynchronous pipelines can be difficult to diagnose when failures or stuck consumers are not observable. <br>\nMitigation: Define dead-letter queues, retries, idempotency, tracing, and operational dashboards as part of the architecture review. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-event-driven) <br>\n- [Metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown, Configuration] <br>\n**Output Format:** [Markdown prose, checklists, and architecture recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Instruction-only; no tools, commands, API keys, or runtime dependencies detected.] <br>\n\n## Skill Version(s): <br>\n1.9.12 (source: ClawHub release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.8.6: 3 files, 3640 bytes\n\nFiles: skill-card.md (2242b), SKILL.md (4224b), _meta.json (167b)\n\nFile v1.8.6:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``message-broker`` -- Kafka, NATS, RabbitMQ; the durable channel between producers and consumers\n- ``event-stream-processor`` -- Flink, Faust, or similar; consumes streams and emits derived events\n- ``distributed-tracing`` -- OpenTelemetry-style correlation IDs across asynchronous hops\n\nFile v1.8.6:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.8.6\",\n  \"publishedAt\": 1780867356833\n}\n\nFile v1.8.6:skill-card.md\n\n## Description: <br>\nThis skill applies event-driven async messaging guidance to decouple producers and consumers. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architecture teams use this skill to decide when event-driven architecture fits a system and to plan event modeling, broker topology, failure handling, and observability. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may be selected for broad architecture or scalability prompts where event-driven messaging is not the intended approach. <br>\nMitigation: Invoke it explicitly for event-driven messaging advice and compare recommendations against simpler request-response designs and transactional consistency needs. <br>\nRisk: Event-driven architecture guidance can introduce hidden coupling or operational complexity if applied without governance. <br>\nMitigation: Require event schemas, ownership, versioning, observability, failure handling, and review of proposed architecture decisions before implementation. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-event-driven) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown, configuration] <br>\n**Output Format:** [Markdown guidance with architecture decision steps and implementation considerations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [No executable code, credentials, persistence, or hidden data access were identified in the server security evidence.] <br>\n\n## Skill Version(s): <br>\n1.8.6 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.8.5: 3 files, 3574 bytes\n\nFiles: skill-card.md (2421b), SKILL.md (3805b), _meta.json (167b)\n\nFile v1.8.5:SKILL.md\n\n---\nname: architecture-paradigm-event-driven\ndescription: |\n  Apply event-driven async messaging to decouple producers and consumers. Use for real-time processing\nversion: 1.9.5\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.\n- **Operational Complexity and \"Noise\"**:\n  - **Mitigation**: Without strong observability, diagnosing failed or \"stuck\" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.\n- **\"Event Storming\" Analysis Paralysis**:\n  - **Mitigation**: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.\n## Troubleshooting\n\n### Common Issues\n\n**Command not found**\nEnsure all dependencies are installed and in PATH\n\n**Permission errors**\nCheck file permissions and run with appropriate privileges\n\n**Unexpected behavior**\nEnable verbose logging with `--verbose` flag\n\nFile v1.8.5:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.8.5\",\n  \"publishedAt\": 1778292919959\n}\n\nFile v1.8.5:skill-card.md\n\n## Description: <br>\nApply event-driven async messaging to decouple producers and consumers for real-time processing. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architects use this skill to evaluate when event-driven architecture is appropriate and to plan adoption steps such as event modeling, topology selection, broker configuration, failure handling, and observability. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The activation terms are broad and may trigger on generic architecture, scalability, or resilience prompts. <br>\nMitigation: Confirm that the task involves asynchronous, loosely coupled, event-driven systems before applying the guidance. <br>\nRisk: The artifact references a fuller Claude Code plugin that may include executable behavior not present in this instruction-only skill. <br>\nMitigation: Review and scan the separate plugin before installing or relying on that fuller version. <br>\nRisk: Event-driven systems can introduce hidden coupling and operational complexity if events and consumers are poorly governed. <br>\nMitigation: Use an event catalog or schema registry, consumer contract checks, dead-letter handling, retry policies, and observability for consumer lag and failures. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-event-driven) <br>\n- [OpenClaw metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown, Configuration] <br>\n**Output Format:** [Markdown prose with structured architecture recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Instruction-only guidance; evidence reports no code, tool calls, credential access, or MCP references.] <br>\n\n## Skill Version(s): <br>\n1.8.5 (source: server release metadata; artifact frontmatter reports 1.9.5) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>","readmeExcerpt":"Skill: architecture-paradigm-event-driven Owner: athola Summary: Applies event-driven async messaging to decouple producers and consumers Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:07.630Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:04.541Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:28:53.527Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:01.434Z | user Release v1.9.16 v1.9.15 | 202","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: architecture-paradigm-event-driven\ndescription: Applies event-driven async messaging to decouple producers and consumers\nversion: 1.9.8\ntriggers:\n  - architecture\n  - event-driven\n  - asynchronous\n  - decoupling\n  - scalability\n  - resilience\n  - designing real-time or multi-subscriber systems needing loose coupling\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Event-Driven Architecture Paradigm\n\n\n## When To Use\n\n- Building async, loosely-coupled systems\n- Systems with complex event processing pipelines\n\n## When NOT To Use\n\n- Simple request-response applications without async needs\n- Systems requiring strong transactional consistency\n\n## When to Employ This Paradigm\n- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.\n- When multiple, distinct subsystems must react to the same business or domain events.\n- When system extensibility is a high priority, allowing new components to be added without modifying existing services.\n\n## Adoption Steps\n1. **Model the Events**: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.\n2. **Select the Right Topology**: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).\n3. **Engineer the Event Platform**: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.\n4. **Plan for Failure Handling**: Implement production-grade mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.\n5. **Instrument for Observability**: Implement detailed monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).\n- A centralized schema repository with automated CI validation and consumer-driven contract tests.\n- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.\n\n## Risks & Mitigations\n- **Hidden Coupling through Events**:\n  - **Mitigation**: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal eve"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-event-driven\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749507630\n}"},{"path":"skill-card.md","content":"## Description:\n\nApplies event-driven async messaging to decouple producers and consumers.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and architects use this skill for guidance on when and how to apply event-driven architecture to asynchronous, loosely coupled, real-time, or multi-subscriber systems.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can activate for broad architecture terms.\n\nMitigation: Confirm the activation scope is appropriate before installing it in environments where general architecture prompts are common.\n\nRisk: Event-driven architecture guidance may be unsuitable for simple request-response systems or systems requiring strong transactional consistency.\n\nMitigation: Apply the skill only after checking the documented when-to-use and when-not-to-use conditions.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-event-driven)\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown guidance for architecture decisions, adoption steps, deliverables, and risks]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Does not run code or request sensitive access.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata; artifact frontmatter lists 1.9.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Applies event-driven async messaging to decouple producers and consumers Skill: architecture-paradigm-event-driven Owner: athola Summary: Applies event-driven async messaging to decouple producers and consumers Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:07.630Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:04.541Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:28:53.527Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:01.434Z | user Release v1.9.16 v1.9.15 | 202","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1039,"uniquenessScore":55,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T00:30:29.988Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T00:30:29.988Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T03:21:39.615Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}