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 lugassawan/swe-workbench --skill principle-event-drivengit clone --depth 1 https://github.com/lugassawan/swe-workbenchWrote 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/lugassawan/swe-workbench/principle-event-driven)<a href="https://agentmods.dev/skills/lugassawan/swe-workbench/principle-event-driven"><img src="https://agentmods.dev/badge/skills/lugassawan/swe-workbench/principle-event-driven/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/lugassawan/swe-workbench/principle-event-driven"><img src="https://agentmods.dev/badge/skills/lugassawan/swe-workbench/principle-event-driven.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.00084 | $0.01333 |
| Opus 5.5 | $0.00034 | $0.00533 |
| Sonnet 5.5 | $0.00017 | $0.00267 |
| Haiku 4.5 | $0.00008 | $0.00133 |
Grade A, and why
principle-event-driven scanned grade A with 0 findings 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 93 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Event-Driven Architecture
The log is the source of truth: producers emit immutable events; consumers react asynchronously. This decouples services at deployment and operational boundaries and lets new consumers replay history — at the cost of eventual consistency and significantly more failure surface area than synchronous calls.
Event Sourcing
Store every state change as an immutable event; derive current state by replaying the log. The aggregate's current state is a projection, not the record of truth.
- Snapshots cap replay cost: persist a projected state checkpoint every N events and replay only from the latest snapshot.
- Projections are disposable — design them to be rebuilt by replaying; avoid hand-rolled caches that drift from the log.
- Event store must be append-only; mutating or deleting events destroys the audit trail and breaks replaying consumers.
- GDPR erasure: store PII in a side-table and tombstone the key rather than mutating event history.
CQRS (Command Query Responsibility Segregation)
Separate the write model (commands that mutate state) from the read model (queries over projections). Often paired with event sourcing but independent of it.
- Read replicas can be denormalized and tuned for specific query shapes without polluting the write model.
- Consistency lag between write and read models is a feature contract, not a bug — document the SLA.
- Avoid CQRS in simple CRUD services; indirection cost exceeds benefit until query and write shapes diverge significantly.
Sagas — Choreography vs Orchestration
Long-running transactions spanning services must be modeled as sagas with explicit compensation steps.
Choreography — each service emits events and reacts to others; no central coordinator.
- Low coupling; hard to trace and debug as the workflow grows beyond two or three participants.
Orchestration — a central saga orchestrator drives the workflow and issues commands to participants.
- Easier observability and rollback reasoning; introduces a single point of coordination and coupling.
- Prefer orchestration when compensation logic is non-trivial or the workflow has more than three participants.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 93 lines · 84 tokens per session scan A 78a47840f771
principle-event-driven is a skill published in the GitHub repository lugassawan/swe-workbench (3 stars, last pushed yesterday), licensed MIT. It adds 84 tokens to every session and 1,333 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
code-forge
Generate implementation code from an approved design blueprint or verbal requirements. Composes context anchoring, architecture, clean code, DDD, security, and test quality into an inside-out implementation workflow. Use when moving from design to code, implementing approved contracts, or when the user says…
functions-development
Build serverless Go or Python functions for Falcon Foundry apps. TRIGGER when user asks to "create a function", "write a serverless function", "build backend logic", runs foundry functions create, or needs help with FDK handler patterns, function testing, or collection integration from functions. Also TRIGGER when…
clean-ddd-hexagonal
Design or review backend domain and dependency boundaries using DDD, Clean Architecture, and ports/adapters. Use for aggregate modeling, bounded contexts, use-case isolation, or architecture refactoring; not routine CRUD changes.
postgres-drizzle
Write or review PostgreSQL schemas, queries, migrations, and Drizzle ORM code. Use for Postgres/Drizzle relations, indexing, pooling, or query performance; not for unrelated databases or generic backend work.
slack-block-kit
Build or debug Slack Block Kit payloads for messages, modals, App Home, streaming responses, and Work Object unfurls. Use for block layout, elements, or interaction schemas; not plain Slack text formatting alone.
application
Use when creating application layer artifacts for a NestJS bounded context — use cases, CQRS command/query handlers, DTOs, ports (cross-module interfaces), application services, or read model projections. Supports three patterns: plain UseCase (A), CQRS native (B), and Handler-as-Orchestrator (C).