Design microservices architectures with service boundaries, event-driven communication, and resilience patterns. Use when building distributed systems, decomposing monoliths, or implementing microservices.
72
58%
Does it follow best practices?
Impact
98%
1.81xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./tests/ext_conformance/artifacts/agents-wshobson/backend-development/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'.
Improve distinctiveness by clarifying what differentiates this from general architecture skills, e.g., specifying output formats or mentioning specific patterns like saga, CQRS, or service mesh.
| 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 broader architecture or DevOps skills. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive but overly verbose reference document that reads more like a textbook chapter than an efficient skill file. It explains many concepts Claude already knows (REST, gRPC, pub/sub, circuit breakers) and duplicates information between the 'Core Concepts' summary and the detailed code sections. The code examples are illustrative but not truly executable due to undefined types and missing infrastructure, reducing their actionability.
Suggestions
Cut the 'Core Concepts' section entirely — it duplicates the code sections and explains things Claude already knows. Start directly with patterns and code.
Move the lengthy code examples (Saga, Circuit Breaker, Event Bus) into the referenced files (references/*.md, assets/*.py) and keep only a concise overview with one short example in SKILL.md.
Make code examples executable by including all necessary type definitions, imports, and a minimal runnable example rather than architectural sketches with undefined types.
Add a concrete workflow for when Claude is actually designing microservices: e.g., 1) Identify bounded contexts, 2) Define service contracts, 3) Choose communication pattern, 4) Validate with specific criteria — with explicit decision points and validation steps.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~500+ lines. Explains concepts Claude already knows well (what circuit breakers are, what REST/gRPC/GraphQL are, what pub/sub is). The bullet-point concept summaries in 'Core Concepts' are entirely redundant with the later code examples, and many patterns are textbook knowledge that doesn't need re-teaching. | 1 / 3 |
Actionability | Code examples are fairly detailed and illustrative, but they are not truly executable — they reference undefined types (Order, PaymentRequest, StepResult, SagaResult, etc.), missing imports, and rely on unshown infrastructure. They serve more as architectural templates/pseudocode than copy-paste-ready implementations. | 2 / 3 |
Workflow Clarity | The Saga pattern shows a clear multi-step process with compensation logic, which is good. However, there's no explicit validation or verification workflow for the overall process of designing/implementing microservices. No checklist for verifying service boundaries, no validation steps for testing communication patterns, and no feedback loops for the design process itself. | 2 / 3 |
Progressive Disclosure | References to external files exist in the Resources section, which is good. However, the main file is a monolithic wall of code examples that could be split into separate reference files. The 'Core Concepts' section duplicates what the code sections show, and the inline content is far too long for a SKILL.md overview. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (596 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
6e3d68c
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.