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.

56

Quality

63%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

Quality

Content

42%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body excels at progressive disclosure — a lean overview pointing to a real, code-rich details file — but the overview itself adds little: it restates well-known pattern taxonomy without actionable guidance, decision criteria, or code. Shifting the body from pattern catalog to concrete decision heuristics and moving known-knowledge bullets into the reference would raise both conciseness and actionability.

Suggestions

Replace the known-knowledge bullet catalogs with decision guidance Claude cannot infer, e.g., when to choose synchronous vs asynchronous communication, or heuristics for drawing service boundaries.

Add at least one concrete inline artifact (a command, a code snippet, or a decision checklist) so the body is actionable on its own rather than purely descriptive.

Signal the reference per-topic (e.g., 'Decomposition worked examples: see references/details.md') and trim bullets like 'REST APIs / gRPC / GraphQL' that restate common knowledge.

DimensionReasoningScore

Conciseness

The body is mostly a catalog of textbook patterns Claude already knows — "REST APIs", "gRPC", "Circuit Breaker: Fail fast on repeated errors, Prevent cascade failures" — restating standard knowledge without added value, matching anchor 2's 'several unnecessary explanations'. It is not anchor 3 because nearly every bullet is known knowledge rather than just some, and not anchor 1 because there is no padded prose, just terse bullets.

2 / 5

Actionability

The body offers only high-level pattern names with no code, commands, decision criteria, or steps — "Organize services around business functions", "Exponential backoff" — fitting anchor 2's 'high-level hints but missing the specific steps'. It is above anchor 1 because it does delegate to a real worked-examples file, but below anchor 3 since the inline guidance itself contains nothing executable or specific.

2 / 5

Workflow Clarity

There is no multi-step process at all — the content is a topic taxonomy, matching anchor 3's 'sequence present but checkpoints missing' at best, since organizing the material has no decision sequence (e.g., how to pick a decomposition strategy or when synchronous vs asynchronous communication applies). Not anchor 4/5 because even for a reference skill there is no guidance on how to move from problem to pattern, and not anchor 2 because the sections are at least coherently organized topically.

3 / 5

Progressive Disclosure

The SKILL.md is a concise overview with a single, well-signaled, one-level-deep reference — "Detailed pattern documentation lives in `references/details.md`. Read that file when the navigation tier above is insufficient" — and that file exists in the bundle with the promised worked examples, matching anchor 5. It is not anchor 4 because the structure is exactly the clean split the top anchor describes: overview inline, details one level deep.

5 / 5

Total

12

/

20

Passed

Description

83%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description that clearly states what the skill does and when to use it, with natural trigger phrases like 'decomposing monoliths'. Minor improvements possible: tighten the broad 'distributed systems' trigger and include a few more concrete capability areas (data management, service discovery) for full coverage.

Suggestions

Add the data-management and service-discovery capabilities (e.g., 'manage distributed transactions with sagas and database-per-service') to close the coverage gap in the 'what' clause.

Consider adding common synonyms or technology triggers (e.g., 'breaking up a monolith', Kafka, event-driven architecture) to improve natural keyword coverage.

The 'building distributed systems' trigger is broad; scoping it (e.g., 'designing distributed system architectures') would reduce overlap risk with general backend-design skills.

DimensionReasoningScore

Specificity

"Design microservices architectures with service boundaries, event-driven communication, and resilience patterns" lists several concrete action areas, matching anchor 4's 'several specific actions; minor gaps in coverage'. It falls short of anchor 5 because other capabilities the body covers (data management, sagas, service discovery) are absent, and it stays slightly above anchor 3 since more than 1-2 concrete actions are named.

4 / 5

Completeness

The description explicitly answers both questions: 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 concrete trigger phrases matching the anchor 5 example's structure. It is not anchor 4 because the 'when' clause is explicit and specific rather than weakly stated.

5 / 5

Trigger Term Quality

Natural terms like "microservices", "distributed systems", "decomposing monoliths", and "event-driven" match what users would actually say, fitting anchor 4's 'good keyword coverage; a few natural terms missing'. Not anchor 5 because common variations such as 'breaking up the monolith', 'service-oriented architecture', or technology keywords (Kafka, REST) are missing.

4 / 5

Distinctiveness Conflict Risk

The microservices/decomposition niche is mostly distinct with clear triggers like "decomposing monoliths", fitting anchor 4's 'mostly distinct; minor overlap risk'. Not anchor 5 because the broad trigger "building distributed systems" could pull in general system-design or messaging questions that overlap with closely related skills.

4 / 5

Total

17

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
wshobson/agents
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.