Design microservices architectures with service boundaries, event-driven communication, and resilience patterns. Use when building distributed systems, decomposing monoliths, or implementing microservices.
57
48%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/microservices-patterns/skills/microservices-patterns/SKILL.mdQuality
Discovery
82%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description that clearly communicates both what the skill does and when to use it, with good trigger terms for the microservices domain. Its main weaknesses are that the capabilities listed are somewhat conceptual rather than concrete discrete actions, and there is moderate overlap risk with adjacent architecture or distributed systems skills.
Suggestions
Make capabilities more concrete by listing specific deliverables, e.g., 'Define service boundaries, design API contracts, create event schemas, implement circuit breakers and retry policies'.
Add more distinctive trigger terms or narrow the scope to reduce overlap with general architecture skills, e.g., mention specific patterns like 'saga pattern', 'CQRS', 'service mesh', or specific file types/diagrams produced.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (microservices) and some actions ('design architectures', 'service boundaries', 'event-driven communication', 'resilience patterns'), but these are more like architectural concepts than concrete discrete actions. Compare to the level 3 example which lists very specific operations like 'extract text', 'fill forms', 'merge documents'. | 2 / 3 |
Completeness | Clearly answers both 'what' (design microservices architectures with service boundaries, event-driven communication, and resilience patterns) and 'when' (use when building distributed systems, decomposing monoliths, or implementing microservices) with an explicit 'Use when...' clause. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'microservices', 'distributed systems', 'decomposing monoliths', 'service boundaries', 'event-driven', 'resilience patterns'. These cover the main terms a user working in this domain would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | While 'microservices' is a fairly specific domain, terms like 'distributed systems' and 'resilience patterns' could overlap with skills focused on general system design, cloud architecture, or infrastructure. The description could conflict with a broader software architecture skill. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
14%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads more like a textbook chapter on microservices patterns than an actionable skill for Claude. It is highly redundant (core concepts duplicated in detail sections), verbose with explanations of well-known concepts, and lacks executable code or clear workflows. The content would benefit from dramatic trimming, splitting into referenced files, and adding concrete step-by-step guidance for actual implementation tasks.
Suggestions
Remove the 'Core Concepts' section entirely since it duplicates the detailed sections below, or replace the detailed sections with references to separate files (e.g., SAGA.md, CIRCUIT_BREAKER.md)
Add a clear sequenced workflow for the primary use case (e.g., 'Decomposing a monolith: Step 1: Identify bounded contexts → Step 2: Define API contracts → Step 3: Extract service → Step 4: Validate independence')
Make code examples executable by defining the missing types (SagaStep, DomainEvent, etc.) or use real library APIs with complete imports
Split the monolithic content into a concise overview SKILL.md with links to pattern-specific files (COMMUNICATION.md, RESILIENCE.md, SAGAS.md)
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with significant redundancy. The 'Core Concepts' section duplicates content that appears again in detail later (e.g., service decomposition, communication patterns, resilience patterns are listed twice). Bullet-point summaries of concepts Claude already knows (what REST is, what a circuit breaker does) waste tokens. The 'When to Use This Skill' section is unnecessary padding. | 1 / 3 |
Actionability | Code examples are provided and somewhat concrete, but they rely on undefined types (DomainEvent, Order, SagaStep, PaymentRequest, etc.) and decorators (@circuit) making them non-executable pseudocode. The examples illustrate patterns conceptually but cannot be copy-pasted and run. | 2 / 3 |
Workflow Clarity | There is no clear sequenced workflow for actually implementing microservices. The content presents isolated patterns without guidance on how to sequence decomposition, when to validate boundaries, or how to verify the architecture works. For a skill involving distributed systems with destructive/complex operations like monolith decomposition and saga patterns, the absence of validation checkpoints and step-by-step processes is a significant gap. | 1 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. All patterns are inlined in a single long document (~300+ lines) with no navigation aids or links to separate detailed guides. Content like the full circuit breaker implementation or saga pattern could be split into referenced files. | 1 / 3 |
Total | 5 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
88da5ff
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.