[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZF0RTDNEN6G859YNPDWY2":3,"skill-same:01M6WZF0RTDNEN6G859YNPDWY2":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6WZF0RTDNEN6G859YNPDWY2","event-driven-architecture",null,"Event-driven systems — pub\u002Fsub, event sourcing, CQRS, sagas, broker selection, reliability. Use when designing or migrating to an event-driven system, choosing a message broker, implementing event sourcing or CQRS, designing sagas, or reviewing async architectures for reliability and ordering.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fevent-driven-architecture\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"event driven","event driven architecture","event","architecture","driven","cqrs","when","sourcing","for","implementing","v1","broker","architectures","selection","async","reliability","use","work","system","event sourcing","2026-11-10 10:12:30",false,"---\nname: event-driven-architecture\ndescription: |\n  Event-driven systems — pub\u002Fsub, event sourcing, CQRS, sagas, broker selection, reliability. Use when designing or migrating to an event-driven system, choosing a message broker, implementing event sourcing or CQRS, designing sagas, or reviewing async architectures for reliability and ordering.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-event-driven-architecture\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Event-Driven Architecture\n\n## Intro\n\nEvent-driven design decouples producers from consumers via a message\nbroker. Done well it scales independently, audits naturally, and\nabsorbs bursts; done badly it creates implicit, untraceable spaghetti.\nPick it only when synchronous request-response would not be simpler\nand sufficient.\n\n## Overview\n\n### When event-driven fits\n\nGood fit:\n\n- Loose coupling needed between services\n- Complex workflows spanning multiple services\n- Real-time processing requirements\n- Independent scaling of producers and consumers\n- Audit-trail requirements (event sourcing)\n\nPoor fit:\n\n- Simple CRUD with strong consistency needs\n- Low throughput where synchronous calls are perfectly fine\n- Small monolith with no distribution requirement\n\nThe honest test: \"Would synchronous request-response be simpler and\nsufficient?\" If yes, do not introduce events for their own sake.\n\n### Messaging patterns\n\nThe deeper diagrams live in `references\u002Fmessaging-patterns.md`.\n\n| Pattern | Use case | Guarantee |\n|---|---|---|\n| Pub\u002FSub | Fan-out notifications, event broadcasting | At-least-once per subscriber |\n| Point-to-Point | Task distribution, work queues | At-least-once with ack |\n| Request-Reply | Async RPC, query with callback | Correlation-based |\n| Competing Consumers | Load balancing across workers | At-least-once, single delivery in group |\n\n### Choosing a broker\n\n- **Apache Kafka** — log-based, very high throughput, replay\n  capability. Best for event sourcing, stream processing, high-volume\n  pipelines. Operationally heavy; prefer managed (Confluent, MSK).\n- **RabbitMQ** — mature, flexible routing via exchanges and bindings.\n  Best for task queues, complex topologies, RPC-style patterns.\n  Lower throughput than Kafka but richer routing.\n- **NATS** — lightweight, low latency, simple ops. Best for\n  microservice communication, IoT, edge. JetStream adds persistence.\n- **Amazon SQS\u002FSNS** — fully managed, zero ops. SQS for queues, SNS\n  for pub\u002Fsub. Limited features but reliable.\n- **Redis Streams** — good for lightweight streaming when Redis is\n  already in the stack. Not a Kafka replacement at scale.\n\nDecision factors: throughput, ordering guarantees, replay, ops\nbudget, existing infrastructure.\n\n### Event sourcing and CQRS\n\n**Event sourcing** stores state as an append-only sequence of\nimmutable events (`OrderPlaced`, `ItemAdded`, `OrderShipped`).\nCurrent state is derived by replaying events; snapshots avoid\nreplaying full history. Never delete events — emit compensating\nevents (`OrderCancelled`) instead.\n\n**CQRS** separates the write model (commands, validation, business\nrules) from read models (denormalized projections optimized per query\nshape). Read models lag writes; design UIs to handle eventual\nconsistency. CQRS without event sourcing is valid and simpler — only\nadd event sourcing when you genuinely need full audit or temporal\nqueries.\n\n### Sagas for distributed transactions\n\nFor workflows spanning multiple services, use sagas instead of 2PC:\n\n- **Orchestration** — a central coordinator tells each service what\n  to do and handles compensation on failure. Easier to understand and\n  debug; the flow is in one place. Risk: orchestrator becomes a god\n  service.\n- **Choreography** — services react to each other's events with no\n  central coordinator. Better decoupling. Risk: hard to track the\n  overall flow without distributed tracing.\n\nChoose orchestration when the workflow logic is complex, visibility\nmatters, and there are fewer than ~5-6 steps. Choose choreography\nwhen services are truly independent, the flow is simple, and teams\nown their services independently.\n\n### Reliability essentials\n\n- **Idempotent consumers** — every consumer must handle duplicates\n  safely. Use idempotency keys (event ID + consumer ID) with a\n  dedup store.\n- **Dead letter queues** — route messages that fail processing after\n  N retries to a DLQ. Monitor depth. Build tooling to inspect and\n  replay.\n- **Outbox pattern** — write events to an outbox table in the same\n  DB transaction as the state change, then publish asynchronously.\n  Prevents lost events when the broker is down.\n- **Schema evolution** — use a schema registry. Make changes\n  additive: add fields, never remove or rename. Version event types.\n- **Ordering** — Kafka guarantees order within a partition, RabbitMQ\n  does not guarantee cross-queue order. Design consumers to tolerate\n  out-of-order delivery where possible.\n\n### Example workflows\n\n- **Order processing pipeline:** Kafka backbone, event sourcing on\n  the order aggregate. Orchestration saga for fulfillment with\n  compensating actions (refund on payment failure, release inventory\n  on shipment failure). Avro schemas in a registry.\n- **Sync to async migration:** map the call graph; identify\n  fire-and-forget interactions vs queries. Pub\u002Fsub for notifications,\n  request-reply for queries. Start with the outbox pattern to avoid\n  dual-write issues. RabbitMQ if routing is rich.\n- **Debugging duplicates \u002F out-of-order:** check consumer\n  idempotency keys. Verify Kafka partition key strategy (related\n  events on the same partition?). Inspect consumer group rebalancing\n  and commit\u002Fack strategy. Drain the DLQ for poison messages.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Non-idempotent consumers.** Webhook delivery and message broker delivery are both at-least-once. A consumer that processes a payment or sends an email without checking whether it already processed this event ID will charge customers twice or send duplicate notifications when the message is redelivered. Every consumer must check a deduplicated event ID before processing and be safe to run twice on the same event.\n- **No dead letter queue.** A consumer that fails repeatedly on a poison message (malformed payload, an invariant the code cannot handle) will retry indefinitely, blocking the queue for all subsequent messages. Route messages that exceed the retry limit to a DLQ and alert on its depth — otherwise one bad message stops the entire consumer group.\n- **Dual write — writing to the database and the broker without an outbox.** If the broker publish succeeds but the database commit fails (or vice versa), producers and consumers have diverged state. Use the transactional outbox pattern: write the event to a database table in the same transaction as the state change, then publish from the outbox asynchronously.\n- **Publishing events before the state is persisted.** If a service publishes `OrderShipped` and then fails to commit the database update, the event has leaked into the world without a corresponding state change. Consumers will react to a shipment that the system does not record. Commit state first; publish only after a successful commit.\n- **Removing or renaming fields in published event schemas.** A consumer running an old version that reads a field that was renamed will silently process empty data or crash. Published event schemas are a contract — make changes additive only: add new optional fields, never remove or rename existing ones. Use a schema registry to enforce this.\n- **Choreographed sagas with no distributed tracing.** A saga implemented as 6 services reacting to each other's events produces a workflow that is invisible unless you can correlate trace IDs across events. Debugging \"why did the payment never succeed\" means manually correlating log entries across 6 services and 20 minutes of event history. Wire distributed tracing before deploying choreography-based sagas.\n- **Choosing event-driven architecture when synchronous request-response is simpler.** Events introduce eventual consistency, ordering ambiguity, and significant operational complexity (brokers, schemas, DLQs, monitoring). The threshold question is: \"Would synchronous request-response be simpler and sufficient?\" If yes, use it. Events are not a default for microservices — they are a tool for specific problems.\n\n## Full reference\n\n### Pub\u002FSub topology\n\n```\n                    +-> [Subscriber A]\n[Producer] -> [Topic]\n                    +-> [Subscriber B]\n                    +-> [Subscriber C]\n```\n\nEach subscriber maintains its own offset. At-least-once per\nsubscriber. Slow subscribers can cause backpressure or lag — monitor\nconsumer lag per subscription. Broker support: Kafka topics, RabbitMQ\nfanout exchanges, NATS subjects, SNS topics.\n\n### Point-to-Point work queue\n\n```\n[Producer] -> [Queue] -> [Consumer A]  (msg 1, 3, 5)\n                      -> [Consumer B]  (msg 2, 4, 6)\n```\n\nExactly one consumer processes each message. At-least-once with\nacknowledgment — unacked messages return to the queue. Ordering is\nnot guaranteed across consumers; use a single consumer or partition\nkeys when order matters.\n\n### Request-Reply\n\n```\n[Requester] --request--> [Queue A] --> [Responder]\n[Requester] \u003C--reply---- [Queue B] \u003C-- [Responder]\n            (correlation ID matches request to reply)\n```\n\nCorrelation ID links request to reply. Always set a timeout for\nmissing replies. Use only when the decoupling benefit is real;\notherwise prefer a synchronous call.\n\n### Dead letter queue\n\n```\n[Queue] -> [Consumer] --fail (retry 1)--> [Consumer]\n                      --fail (retry 2)--> [Consumer]\n                      --fail (retry 3)--> [DLQ]\n                                            |\n                                    [Inspect \u002F replay]\n```\n\nConfigure max retries (typically 3-5) with exponential backoff. Alert\non DLQ depth > 0. Build inspection and replay tooling. Broker\nsupport: RabbitMQ dead-letter exchanges, SQS DLQ, Kafka requires\ncustom retry topics.\n\n### Event sourcing example stream\n\nOrder #42:\n\n```\n1: OrderPlaced   { items: [...], total: 99.00 }\n2: PaymentTaken  { method: \"card\", ref: \"abc\" }\n3: ItemRemoved   { item: \"widget\", new_total: 79.00 }\n4: OrderShipped  { tracking: \"XYZ123\" }\n```\n\nReplay events 1-4 to reconstruct current state. Snapshot every N\nevents (commonly 100-500) to avoid full replay. Add fields freely;\nnever remove fields from published events. The event store is not a\nquery database — use CQRS projections for read patterns.\n\n### CQRS topology\n\n```\n[Client]\n   |\n   +--command--> [Command Handler] -> [Write Model \u002F Event Store]\n   |                                       |\n   |                                 (events projected)\n   |                                       |\n   +--query---> [Query Handler] -> [Read Model DB]\n```\n\nMultiple read models are common — one for list views, one for\nsearch, one for analytics — each rebuilt from events and optimized\nfor its query shape. Typical projection lag is milliseconds to\nseconds.\n\n### Anti-patterns\n\n- **Events for everything** — synchronous calls are fine when\n  request-response is the natural shape.\n- **Non-idempotent consumers** — duplicate delivery is inevitable.\n- **No DLQ** — poison messages block the queue forever.\n- **Dual writes** — writing to DB and broker without an outbox\n  loses events on failure.\n- **Removing or renaming event fields** — breaks every consumer\n  pinned to old schema.\n- **Querying the event store** for read patterns — that is what CQRS\n  projections exist for.\n- **Choreographed sagas with no tracing** — debugging becomes\n  archaeology.\n- **Orchestrator god service** — when one orchestrator owns every\n  workflow, it becomes the new monolith.\n","# Event-Driven Architecture\n\n## Intro\n\nEvent-driven design decouples producers from consumers via a message\nbroker. Done well it scales independently, audits naturally, and\nabsorbs bursts; done badly it creates implicit, untraceable spaghetti.\nPick it only when synchronous request-response would not be simpler\nand sufficient.\n\n## Overview\n\n### When event-driven fits\n\nGood fit:\n\n- Loose coupling needed between services\n- Complex workflows spanning multiple services\n- Real-time processing requirements\n- Independent scaling of producers and consumers\n- Audit-trail requirements (event sourcing)\n\nPoor fit:\n\n- Simple CRUD with strong consistency needs\n- Low throughput where synchronous calls are perfectly fine\n- Small monolith with no distribution requirement\n\nThe honest test: \"Would synchronous request-response be simpler and\nsufficient?\" If yes, do not introduce events for their own sake.\n\n### Messaging patterns\n\nThe deeper diagrams live in `references\u002Fmessaging-patterns.md`.\n\n| Pattern | Use case | Guarantee |\n|---|---|---|\n| Pub\u002FSub | Fan-out notifications, event broadcasting | At-least-once per subscriber |\n| Point-to-Point | Task distribution, work queues | At-least-once with ack |\n| Request-Reply | Async RPC, query with callback | Correlation-based |\n| Competing Consumers | Load balancing across workers | At-least-once, single delivery in group |\n\n### Choosing a broker\n\n- **Apache Kafka** — log-based, very high throughput, replay\n  capability. Best for event sourcing, stream processing, high-volume\n  pipelines. Operationally heavy; prefer managed (Confluent, MSK).\n- **RabbitMQ** — mature, flexible routing via exchanges and bindings.\n  Best for task queues, complex topologies, RPC-style patterns.\n  Lower throughput than Kafka but richer routing.\n- **NATS** — lightweight, low latency, simple ops. Best for\n  microservice communication, IoT, edge. JetStream adds persistence.\n- **Amazon SQS\u002FSNS** — fully managed, zero ops. SQS for queues, SNS\n  for pub\u002Fsub. Limited features but reliable.\n- **Redis Streams** — good for lightweight streaming when Redis is\n  already in the stack. Not a Kafka replacement at scale.\n\nDecision factors: throughput, ordering guarantees, replay, ops\nbudget, existing infrastructure.\n\n### Event sourcing and CQRS\n\n**Event sourcing** stores state as an append-only sequence of\nimmutable events (`OrderPlaced`, `ItemAdded`, `OrderShipped`).\nCurrent state is derived by replaying events; snapshots avoid\nreplaying full history. Never delete events — emit compensating\nevents (`OrderCancelled`) instead.\n\n**CQRS** separates the write model (commands, validation, business\nrules) from read models (denormalized projections optimized per query\nshape). Read models lag writes; design UIs to handle eventual\nconsistency. CQRS without event sourcing is valid and simpler — only\nadd event sourcing when you genuinely need full audit or temporal\nqueries.\n\n### Sagas for distributed transactions\n\nFor workflows spanning multiple services, use sagas instead of 2PC:\n\n- **Orchestration** — a central coordinator tells each service what\n  to do and handles compensation on failure. Easier to understand and\n  debug; the flow is in one place. Risk: orchestrator becomes a god\n  service.\n- **Choreography** — services react to each other's events with no\n  central coordinator. Better decoupling. Risk: hard to track the\n  overall flow without distributed tracing.\n\nChoose orchestration when the workflow logic is complex, visibility\nmatters, and there are fewer than ~5-6 steps. Choose choreography\nwhen services are truly independent, the flow is simple, and teams\nown their services independently.\n\n### Reliability essentials\n\n- **Idempotent consumers** — every consumer must handle duplicates\n  safely. Use idempotency keys (event ID + consumer ID) with a\n  dedup store.\n- **Dead letter queues** — route messages that fail processing after\n  N retries to a DLQ. Monitor depth. Build tooling to inspect and\n  replay.\n- **Outbox pattern** — write events to an outbox table in the same\n  DB transaction as the state change, then publish asynchronously.\n  Prevents lost events when the broker is down.\n- **Schema evolution** — use a schema registry. Make changes\n  additive: add fields, never remove or rename. Version event types.\n- **Ordering** — Kafka guarantees order within a partition, RabbitMQ\n  does not guarantee cross-queue order. Design consumers to tolerate\n  out-of-order delivery where possible.\n\n### Example workflows\n\n- **Order processing pipeline:** Kafka backbone, event sourcing on\n  the order aggregate. Orchestration saga for fulfillment with\n  compensating actions (refund on payment failure, release inventory\n  on shipment failure). Avro schemas in a registry.\n- **Sync to async migration:** map the call graph; identify\n  fire-and-forget interactions vs queries. Pub\u002Fsub for notifications,\n  request-reply for queries. Start with the outbox pattern to avoid\n  dual-write issues. RabbitMQ if routing is rich.\n- **Debugging duplicates \u002F out-of-order:** check consumer\n  idempotency keys. Verify Kafka partition key strategy (related\n  events on the same partition?). Inspect consumer group rebalancing\n  and commit\u002Fack strategy. Drain the DLQ for poison messages.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Non-idempotent consumers.** Webhook delivery and message broker delivery are both at-least-once. A consumer that processes a payment or sends an email without checking whether it already processed this event ID will charge customers twice or send duplicate notifications when the message is redelivered. Every consumer must check a deduplicated event ID before processing and be safe to run twice on the same event.\n- **No dead letter queue.** A consumer that fails repeatedly on a poison message (malformed payload, an invariant the code cannot handle) will retry indefinitely, blocking the queue for all subsequent messages. Route messages that exceed the retry limit to a DLQ and alert on its depth — otherwise one bad message stops the entire consumer group.\n- **Dual write — writing to the database and the broker without an outbox.** If the broker publish succeeds but the database commit fails (or vice versa), producers and consumers have diverged state. Use the transactional outbox pattern: write the event to a database table in the same transaction as the state change, then publish from the outbox asynchronously.\n- **Publishing events before the state is persisted.** If a service publishes `OrderShipped` and then fails to commit the database update, the event has leaked into the world without a corresponding state change. Consumers will react to a shipment that the system does not record. Commit state first; publish only after a successful commit.\n- **Removing or renaming fields in published event schemas.** A consumer running an old version that reads a field that was renamed will silently process empty data or crash. Published event schemas are a contract — make changes additive only: add new optional fields, never remove or rename existing ones. Use a schema registry to enforce this.\n- **Choreographed sagas with no distributed tracing.** A saga implemented as 6 services reacting to each other's events produces a workflow that is invisible unless you can correlate trace IDs across events. Debugging \"why did the payment never succeed\" means manually correlating log entries across 6 services and 20 minutes of event history. Wire distributed tracing before deploying choreography-based sagas.\n- **Choosing event-driven architecture when synchronous request-response is simpler.** Events introduce eventual consistency, ordering ambiguity, and significant operational complexity (brokers, schemas, DLQs, monitoring). The threshold question is: \"Would synchronous request-response be simpler and sufficient?\" If yes, use it. Events are not a default for microservices — they are a tool for specific problems.\n\n## Full reference\n\n### Pub\u002FSub topology\n\n```\n                    +-> [Subscriber A]\n[Producer] -> [Topic]\n                    +-> [Subscriber B]\n                    +-> [Subscriber C]\n```\n\nEach subscriber maintains its own offset. At-least-once per\nsubscriber. Slow subscribers can cause backpressure or lag — monitor\nconsumer lag per subscription. Broker support: Kafka topics, RabbitMQ\nfanout exchanges, NATS subjects, SNS topics.\n\n### Point-to-Point work queue\n\n```\n[Producer] -> [Queue] -> [Consumer A]  (msg 1, 3, 5)\n                      -> [Consumer B]  (msg 2, 4, 6)\n```\n\nExactly one consumer processes each message. At-least-once with\nacknowledgment — unacked messages return to the queue. Ordering is\nnot guaranteed across consumers; use a single consumer or partition\nkeys when order matters.\n\n### Request-Reply\n\n```\n[Requester] --request--> [Queue A] --> [Responder]\n[Requester] \u003C--reply---- [Queue B] \u003C-- [Responder]\n            (correlation ID matches request to reply)\n```\n\nCorrelation ID links request to reply. Always set a timeout for\nmissing replies. Use only when the decoupling benefit is real;\notherwise prefer a synchronous call.\n\n### Dead letter queue\n\n```\n[Queue] -> [Consumer] --fail (retry 1)--> [Consumer]\n                      --fail (retry 2)--> [Consumer]\n                      --fail (retry 3)--> [DLQ]\n                                            |\n                                    [Inspect \u002F replay]\n```\n\nConfigure max retries (typically 3-5) with exponential backoff. Alert\non DLQ depth > 0. Build inspection and replay tooling. Broker\nsupport: RabbitMQ dead-letter exchanges, SQS DLQ, Kafka requires\ncustom retry topics.\n\n### Event sourcing example stream\n\nOrder #42:\n\n```\n1: OrderPlaced   { items: [...], total: 99.00 }\n2: PaymentTaken  { method: \"card\", ref: \"abc\" }\n3: ItemRemoved   { item: \"widget\", new_total: 79.00 }\n4: OrderShipped  { tracking: \"XYZ123\" }\n```\n\nReplay events 1-4 to reconstruct current state. Snapshot every N\nevents (commonly 100-500) to avoid full replay. Add fields freely;\nnever remove fields from published events. The event store is not a\nquery database — use CQRS projections for read patterns.\n\n### CQRS topology\n\n```\n[Client]\n   |\n   +--command--> [Command Handler] -> [Write Model \u002F Event Store]\n   |                                       |\n   |                                 (events projected)\n   |                                       |\n   +--query---> [Query Handler] -> [Read Model DB]\n```\n\nMultiple read models are common — one for list views, one for\nsearch, one for analytics — each rebuilt from events and optimized\nfor its query shape. Typical projection lag is milliseconds to\nseconds.\n\n### Anti-patterns\n\n- **Events for everything** — synchronous calls are fine when\n  request-response is the natural shape.\n- **Non-idempotent consumers** — duplicate delivery is inevitable.\n- **No DLQ** — poison messages block the queue forever.\n- **Dual writes** — writing to DB and broker without an outbox\n  loses events on failure.\n- **Removing or renaming event fields** — breaks every consumer\n  pinned to old schema.\n- **Querying the event store** for read patterns — that is what CQRS\n  projections exist for.\n- **Choreographed sagas with no tracing** — debugging becomes\n  archaeology.\n- **Orchestrator god service** — when one orchestrator owns every\n  workflow, it becomes the new monolith.\n",{"name":5,"metadata":44,"description":51},{"processkit":45},{"id":46,"created":47,"version":48,"category":49,"apiVersion":50},"SKILL-event-driven-architecture",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Event-driven systems — pub\u002Fsub, event sourcing, CQRS, sagas, broker selection, reliability. Use when designing or migrating to an event-driven system, choosing a message broker, implementing event sourcing or CQRS, designing sagas, or reviewing async architectures for reliability and ordering.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fevent-driven-architecture","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add projectious-work\u002Fprocesskit --skill event-driven-architecture",{"tool":65,"command":66},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill event-driven-architecture",{"tool":68,"command":69},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill event-driven-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fevent-driven-architecture\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fmessaging-patterns.md","REFERENCE","参考文档",6059,"https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fevent-driven-architecture\u002Freferences\u002Fmessaging-patterns.md",[80,106,126,146,163,181],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":91,"publishedAt":39},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[92,93,94,95,96,97,36,98,99,100,82,101,102,103,29,104,105],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":39},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[112],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},[92,114,115,116,117,118,97,36,119,120,99,121,122,123,101,124,125],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":39},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[92,133,134,94,95,135,97,36,136,137,138,139,101,140,21,141,142,143,144,145],"proposition","proposition management","index","log","world","record","query","creation","interface","updates","facts","claims","WSJF",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":39},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[92,100,153,94,97,154,155,119,156,136,99,157,158,101,159,160,21,161,29,162],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":39},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[170,171,172,173,97,174,175,176,36,177,178,179,180],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":39},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[92,188,189,94,95,135,97,154,36,98,136,190,99,138,101,160,21,141,191,105],"capability","capability management","queries","changes"]