Designs distributed system architectures, decomposes monoliths into bounded-context services, recommends communication patterns, and produces service boundary diagrams and resilience strategies. Use when designing distributed systems, decomposing monoliths, or implementing microservices patterns — including service boundaries, DDD, saga patterns, event sourcing, CQRS, service mesh, or distributed tracing.
91
92%
Does it follow best practices?
Impact
89%
1.08xAverage score across 6 eval scenarios
Passed
No known issues
Domain-driven monolith decomposition
Capability-based services
73%
73%
No shared databases
100%
100%
Database per service stated
100%
100%
Cross-service data via APIs
100%
100%
Leaf-first migration order
100%
100%
No distributed monolith
100%
90%
Async for cross-aggregate ops
100%
100%
No shared business logic library
100%
100%
Reasonable service count
100%
100%
Anti-patterns section present
100%
100%
Resilience patterns implementation
Circuit breaker present
100%
100%
Exponential backoff retry
100%
100%
Jitter in retry delays
0%
100%
Idempotency key used
100%
100%
Bulkhead isolation
100%
100%
Timeout configured
100%
87%
Only transient errors retried
100%
100%
Correlation ID propagated
100%
100%
Liveness endpoint
100%
100%
Readiness endpoint
100%
100%
Graceful fallback on circuit open
28%
57%
RESILIENCE_NOTES.md present
100%
100%
Observability and API design
Structured JSON logging
100%
100%
Correlation ID in logs
100%
100%
Prometheus metrics exposed
100%
100%
RED method metrics
100%
100%
OpenTelemetry tracing
100%
100%
Trace export configured
75%
100%
Correlation ID in trace span
0%
100%
URL versioning used
0%
0%
Cursor-based pagination
0%
0%
Liveness health endpoint
100%
100%
Readiness health endpoint
100%
42%
SLO definition present
100%
100%
Saga orchestration with compensation
execute() and compensate() per step
100%
100%
Saga state persisted
100%
100%
State updated after each step
100%
100%
Compensations execute in reverse
100%
100%
Idempotency check per step
70%
100%
No 2PC used
100%
100%
Async service communication
0%
0%
Graceful fallback on failure
57%
100%
Correlation ID propagated
85%
57%
Incomplete sagas resume on restart
100%
100%
No synchronous long-running chain
71%
71%
DESIGN_NOTES.md present
100%
100%
Event sourcing and CQRS
Events immutable and append-only
100%
100%
Event schema has causationId
0%
0%
Event schema has correlationId
0%
100%
Event store SQL schema correct
77%
100%
Index on (aggregate_id, version)
85%
100%
Snapshot table defined
100%
100%
Snapshot strategy documented
100%
100%
State reconstruction uses snapshot
100%
100%
CQRS read model separated
100%
100%
Read model updated via event handler
100%
100%
Event versioning present
100%
100%
Temporal query supported
100%
100%
Past tense event naming
100%
100%
gRPC internal APIs and event schema design
gRPC for internal API
100%
100%
Protobuf service definition
100%
100%
gRPC error status codes used
12%
0%
Event schema has eventId
100%
100%
Event schema has eventVersion
100%
100%
Event schema has correlationId
0%
100%
Event schema has causationId
0%
0%
Past tense domain event names
100%
100%
Domain events contain minimal data
71%
100%
Kafka chosen for multi-consumer events
100%
100%
REST for external/public API
100%
100%
Integration events versioned and backward-compatible
100%
100%
ARCHITECTURE.md present
100%
100%
5b76101
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.