jbvc/microservices-patterns
Design microservices architectures with service boundaries, event-driven communication, and resilience patterns. Use when building distributed systems, decomposing monoliths, or implementing microservices.
65
65%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
92%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 well-structured skill description that clearly states what it does and when to use it, with good trigger terms that match how developers naturally talk about microservices architecture. The main weakness is a slight overlap risk with broader system design or infrastructure skills due to terms like 'distributed systems' and 'resilience patterns'. Overall, it follows the pattern of the good examples closely.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'Design microservices architectures with service boundaries, event-driven communication, and resilience patterns' covers distinct architectural concerns. | 3 / 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 explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'microservices', 'distributed systems', 'decomposing monoliths', 'service boundaries', 'event-driven'. These are terms developers naturally use when seeking this kind of help. | 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, infrastructure, or DevOps. The niche is reasonably clear but not perfectly distinct. | 2 / 3 |
Total | 11 / 12 Passed |
Implementation
22%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is essentially a thin wrapper that defers all substantive content to an external playbook. The body provides no concrete patterns, code examples, decision frameworks, or specific guidance — just abstract instructions like 'identify domain boundaries' that Claude could generate without any skill file. The content fails to justify its existence as a standalone skill.
Suggestions
Add concrete, actionable content to the Instructions section — e.g., specific patterns like Strangler Fig for migration, Saga pattern for distributed transactions, or Circuit Breaker for resilience, with code or configuration examples.
Include at least one worked example showing how to decompose a domain into services with explicit boundary decisions and communication pattern choices.
Add validation checkpoints to the workflow, such as 'Verify each service owns its data store independently' or 'Confirm no synchronous circular dependencies between services.'
Provide a brief but substantive overview of key patterns (event sourcing, CQRS, API gateway) in the SKILL.md itself so it has standalone value before deferring to the playbook.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'Use this skill when' and 'Do not use this skill when' sections add some value for scoping but are somewhat verbose. The 'Master microservices architecture patterns including...' opening line is unnecessary filler that explains what Claude already knows. | 2 / 3 |
Actionability | The instructions are extremely vague and abstract — 'Identify domain boundaries,' 'Define contracts,' 'Plan resilience' — with no concrete code, commands, examples, patterns, or specific guidance. Everything actionable is deferred to an external resource file. | 1 / 3 |
Workflow Clarity | The four instruction steps are high-level platitudes with no validation checkpoints, no concrete sequencing details, and no feedback loops. For a complex multi-step domain like microservices architecture, this provides essentially no workflow guidance. | 1 / 3 |
Progressive Disclosure | There is a reference to an external resource file (implementation-playbook.md), which is appropriate progressive disclosure. However, the SKILL.md itself contains almost no substantive overview content to stand on its own — it's essentially an empty shell pointing elsewhere. | 2 / 3 |
Total | 6 / 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.
Reviewed
Table of Contents