CtrlK
BlogDocsLog inGet started
Tessl Logo

microservices-patterns

Design microservices architectures with service boundaries, event-driven communication, and resilience patterns. Use when building distributed systems, decomposing monoliths, or implementing microservices.

46

Quality

48%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./plugins/microservices-patterns/skills/microservices-patterns/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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 than an actionable skill for Claude. It is excessively verbose, duplicates content between overview and detail sections, explains well-known concepts Claude already understands, and lacks any coherent workflow or validation steps. The code examples, while present, are incomplete and non-executable.

Suggestions

Remove the 'Core Concepts' section entirely since it duplicates the detailed sections below, and trim each pattern to just the code example with a one-line description of when to use it.

Make code examples fully executable by defining all referenced types (SagaStep, DomainEvent, etc.) or use standard library types, and add required imports.

Add a decision workflow: 'When decomposing a monolith: 1. Identify bounded contexts → 2. Define service contracts → 3. Implement communication pattern → 4. Validate with integration tests → 5. Deploy with circuit breakers' with explicit validation checkpoints.

Split detailed pattern implementations into separate referenced files (e.g., SAGA.md, CIRCUIT_BREAKER.md) and keep SKILL.md as a concise overview with navigation links.

DimensionReasoningScore

Conciseness

The skill is extremely verbose at ~300+ lines, with extensive bullet-point lists explaining concepts Claude already knows (what REST is, what Kafka is, what a circuit breaker does). The 'Core Concepts' section duplicates content that appears again in the detailed sections below. Phrases like 'Organize services around business functions' and 'Each service owns its domain' are generic knowledge that wastes tokens.

1 / 3

Actionability

The code examples are reasonably concrete but not fully executable—they reference undefined types (Order, DomainEvent, SagaStep, PaymentRequest, etc.), missing imports, and undefined decorators (@circuit). They serve more as illustrative pseudocode than copy-paste-ready implementations. The best practices and pitfalls sections are purely descriptive bullet points with no actionable guidance.

2 / 3

Workflow Clarity

There is no clear sequenced workflow for actually implementing microservices. The content presents isolated patterns without connecting them into a coherent process. There are no validation checkpoints, no decision trees for choosing between patterns, and no feedback loops for verifying that decomposition or communication patterns are working correctly.

1 / 3

Progressive Disclosure

The content is a monolithic wall of text with no references to external files and no bundle files to support it. All patterns are inlined at full length, with duplicated content between the 'Core Concepts' overview and the detailed sections. There's no layered structure or navigation aids.

1 / 3

Total

5

/

12

Passed

Description

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 covering 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', 'API gateway', or specific file types/diagrams produced.

DimensionReasoningScore

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

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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
secondsky/claude-skills
Reviewed

Table of Contents

Is this your skill?

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.