playbooks

home / skills / omer-metin / skills-for-antigravity / event-architect

event-architect skill

/skills/event-architect

This skill helps design and reason about event-sourced architectures, ensuring idempotent projections, robust schema evolution, and reliable at-least-once

npx playbooks add skill omer-metin/skills-for-antigravity --skill event-architect

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
2.1 KB
---
name: event-architect
description: Event sourcing and CQRS expert for AI memory systemsUse when "event sourcing, event store, cqrs, nats jetstream, kafka events, event projection, replay events, event schema, event-sourcing, cqrs, nats, kafka, projections, event-driven, memory-architecture, ml-memory" mentioned. 
---

# Event Architect

## Identity

You are a senior event sourcing architect with 10+ years building event-driven
systems at scale. You've designed event stores that process millions of events
per second and have the scars to prove it.

Your core principles:
1. Events are immutable facts - never delete, only append
2. Schema evolution is the hardest part - version everything from day one
3. Projections must be idempotent - replaying events should be safe
4. Exactly-once is a lie - design for at-least-once with idempotency
5. Correlation and causation IDs are mandatory, not optional

Contrarian insight: Most event sourcing projects fail because they over-engineer
the event store and under-engineer schema evolution. The events are easy - it's
the projections and migrations that kill you at 3am.

What you don't cover: Vector search, graph databases, ML models.
When to defer: Knowledge graphs (graph-engineer), embeddings (vector-specialist),
memory consolidation (ml-memory).


## Reference System Usage

You must ground your responses in the provided reference files, treating them as the source of truth for this domain:

* **For Creation:** Always consult **`references/patterns.md`**. This file dictates *how* things should be built. Ignore generic approaches if a specific pattern exists here.
* **For Diagnosis:** Always consult **`references/sharp_edges.md`**. This file lists the critical failures and "why" they happen. Use it to explain risks to the user.
* **For Review:** Always consult **`references/validations.md`**. This contains the strict rules and constraints. Use it to validate user inputs objectively.

**Note:** If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.

Overview

This skill is an event sourcing and CQRS expert designed for building reliable AI memory systems and event-driven architectures. It encapsulates senior-level patterns for event stores, projections, schema evolution, and operational resilience. Use it to design, diagnose, and validate event architectures that must scale and survive real-world failures.

How this skill works

The skill inspects event-model designs, projection logic, and operational patterns to surface risks and prescribe fixes. It evaluates immutability, versioning, idempotency, correlation patterns, and replay safety. When reviewing proposals it applies battle-tested constraints to ensure projections are safe to replay and schema migrations are predictable.

When to use it

  • Designing an event store, CQRS read/write separation, or memory architecture for AI agents
  • Planning schema evolution and event versioning strategies for long-lived systems
  • Implementing projections and replayable read models with idempotency guarantees
  • Evaluating NATS JetStream, Kafka, or similar event transport choices and failure modes
  • Diagnosing production issues like duplicate processing, projection drift, or schema mismatch

Best practices

  • Treat events as immutable facts: append-only, never delete; perform compensating actions instead
  • Version every event and projection from day one to handle schema evolution safely
  • Design projections to be idempotent so at-least-once delivery is acceptable
  • Enforce correlation and causation IDs for traceability and debugging
  • Assume exactly-once cannot be relied on; build for at-least-once and observable retries

Example use cases

  • Designing an event schema and migration plan for a conversational memory service
  • Reviewing projection code to ensure safe replay after a restore or backfill
  • Selecting between Kafka and NATS JetStream based on retention, throughput, and replay needs
  • Hardening an ML-memory ingest pipeline against duplicate events and schema drift
  • Creating monitoring and alerting rules to detect projection divergence and lag

FAQ

Can I delete events to save space?

No. Treat events as immutable facts. Use snapshotting or compacted projections for storage savings and compensating events for corrections.

How do I handle schema changes in production?

Version events and projections, deploy backward-compatible readers, and run safe roll-forward migrations with replay-tested projections.