Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add KraitDev/skiLL.Md --skill event-driven-designgit clone --depth 1 https://github.com/KraitDev/skiLL.MdWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/kraitdev/skill.md/event-driven-design)<a href="https://agentmods.dev/skills/kraitdev/skill.md/event-driven-design"><img src="https://agentmods.dev/badge/skills/kraitdev/skill.md/event-driven-design/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/kraitdev/skill.md/event-driven-design"><img src="https://agentmods.dev/badge/skills/kraitdev/skill.md/event-driven-design.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00016 | $0.01605 |
| Opus 5.5 | $0.00006 | $0.00642 |
| Sonnet 5.5 | $0.00003 | $0.00321 |
| Haiku 4.5 | $0.00002 | $0.00161 |
Grade A, and why
event-driven-design scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
const order = await orderService.fetch(event.orderId); // Blocks on external service How it starts
The opening of the file, as written. The whole thing — 171 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Event-Driven Design
Purpose
Tightly coupled systems break and scale poorly. Event-driven architectures decouple producers from consumers by using immutable, timestamped facts as the communication mechanism. This enables systems to evolve independently, scale horizontally, and handle distributed failures gracefully.
When to use
- De-coupling monolithic microservices
- Implementing long-running asynchronous workflows (e.g., video processing, email sending)
- Triggering multiple side-effects across different domains from a single action
- Designing systems that need to replay history or audit changes
When NOT to use
- Simple synchronous request-response flows (don't add unnecessary complexity)
- Real-time bidirectional communication (use WebSockets instead)
- Workflows requiring immediate response to action
Inputs required
- Microservices or monolithic application with clear domain boundaries
- Message broker infrastructure (Kafka, RabbitMQ, EventBridge, etc.)
- Understanding of event sourcing concepts
Workflow
- Define Events: Identify state changes in the domain and model them as past-tense events (e.g.,
OrderPlaced,UserRegistered,PaymentProcessed) - Design Event Payloads: Include Event ID, Timestamp, Event Type, and minimal required data (avoid large nested objects)
- Publishing Mechanism: Have the producer system emit the event to a Message Broker without caring who consumes it
- Idempotent Consumers: Ensure consumer services can process the same event multiple times without adverse side effects
- Handle Failures: Implement Dead Letter Queues (DLQ) for events that consumers repeatedly fail to process
- Track Processing: Add idempotency keys or processed event IDs to detect duplicates
- Monitor: Set up alerts for DLQ messages and processing delays
Rules
- MUST model events as immutable facts (past tense:
OrderPlacednotPlaceOrder) - MUST NEVER modify or delete events once emitted (audit trail requirement)
- MUST make consumers idempotent (same event processed multiple times = same outcome)
- MUST avoid deeply nested, rapidly changing entity graphs in payloads
- MUST include Event ID, Timestamp, Event Type in all events
- MUST implement Dead Letter Queues for failed events
- MUST NOT use synchronous HTTP calls as part of event workflows
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 171 lines · 16 tokens per session scan A 7403d83098e5
event-driven-design is a skill published in the GitHub repository KraitDev/skiLL.Md (6 stars, last pushed 4mo ago), licensed MIT. It adds 16 tokens to every session and 1,605 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
backend-event-sourcing
Use this skill when the user says 'event sourcing', 'event store', 'event stream', 'event sourced', 'rehydrate from events', 'event replay', 'projection rebuild', 'event log', 'append-only log', 'event history'. This skill enforces: events as the single source of truth, current state derived from event replay…
flutter-dio-cache-interceptor-engineering
Use when adding, reviewing, debugging, testing, or tuning diocacheinterceptor in a Flutter or Dart Dio client. Covers CacheOptions, CachePolicy, HTTP revalidation, cache stores, offline fallback, authenticated-user key isolation, invalidation, platform compatibility, and 4.x migration. Trigger for stale Dio responses…
flutter-dio-engineering
Design, implement, review, debug, secure, test, refactor, and optimize production Flutter/Dart networking built with Dio 5.x. Use this skill whenever a Flutter task involves Dio clients, REST/HTTP APIs, BaseOptions/Options, interceptors, bearer authentication, token refresh, retries, cancellation, uploads/downloads…
golang-manual-di
Guides manual dependency injection wiring for Go services: three-tier naming taxonomy (Provide/MustProvide/Must), Must-pattern entrypoints, OS-signal-driven context lifecycle, common provider structs, infrastructure must-builders, interface-segregated bus registration, decorator/tracing wrappers, and…
terraform-infrastructure
Structures, writes, and reviews Terraform infrastructure code. Covers module layout, remote state, workspace strategy, variable and secrets handling, CI plan/apply pipeline, naming conventions, and multi-region deployment patterns (provider aliases, per-region state, failover strategies), while delegating shared risk…
health-check-endpoints
Implements liveness and readiness health check endpoints following Kubernetes probe conventions. Covers response schema, dependency checks, Kubernetes probe config, and circuit breaker integration. Invoked when the user asks to add health checks, implement a /health endpoint, or set up Kubernetes probes.