CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

microservices-patterns

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

58

Quality

73%

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 ./skills/microservices-patterns/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

50%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.

A well-structured, concise overview that delegates appropriately, but the body is an empty shell: the instructions are abstract one-liners, the workflow lacks any checkpoints, and the single referenced file is missing from the bundle entirely. The skill as shipped provides almost no substantive guidance beyond what its description already says.

Suggestions

Make the Instructions section actionable: for each step, name concrete techniques or criteria (e.g., which bounded-context heuristics to apply, which communication patterns to choose between and when), rather than abstract directives like 'Plan resilience, observability, and deployment strategy'.

Add validation checkpoints to the workflow — e.g., verify each proposed service owns its data with no shared tables, check that every cross-service interaction has a failure-mode plan — so the sequence has explicit quality gates instead of ending at 'Provide migration steps'.

Fix the dangling reference: either include resources/implementation-playbook.md in the bundle with the detailed patterns, or remove the pointer and inline the essential guidance, since the referenced file currently does not exist.

DimensionReasoningScore

Conciseness

The body is lean with no explanations of concepts Claude already knows, but the intro sentence and the 'Use this skill when' list restate the frontmatter description almost verbatim, which could be trimmed. Better than anchor 3 (unnecessary explanation), short of anchor 5's every-token-earns-its-place.

4 / 5

Actionability

The four instructions are high-level hints — 'Identify domain boundaries and ownership for each service', 'Plan resilience, observability, and deployment strategy' — with no concrete methods, criteria, or examples; the only detailed material is delegated to a resource file. This matches the minimal-concrete-guidance anchor rather than anchor 3, because nothing here is specific enough to execute.

2 / 5

Workflow Clarity

A coherent 4-step sequence is present (boundaries → contracts/data → resilience/deployment → migration/ops), but each step is a single abstract line with no validation checkpoints or decision guidance. Not a destructive/batch skill so no hard cap applies; it sits between anchor 2's many-gaps and anchor 4's most-checkpoints cases.

3 / 5

Progressive Disclosure

Sections are well organized and the reference is clearly signaled ('resources/implementation-playbook.md for detailed patterns and examples'), but that file does not exist in the bundle — no resources/, references/, scripts/, or assets/ directories are present — so the skill's promised deeper content is unreachable. Better than anchor 2's minimal structure, but the dangling reference keeps it below anchor 4.

3 / 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 and good domain specificity. Its only weaknesses are single-verb framing of the capabilities and a trigger set that misses common synonyms like SOA.

DimensionReasoningScore

Specificity

The description names the domain and three concrete capability areas — 'service boundaries, event-driven communication, and resilience patterns' — but hangs them all on a single verb ('Design'), so it falls between the 1-2-action anchor (3) and the multiple-distinct-actions anchor (5).

4 / 5

Completeness

It explicitly answers 'what' ('Design microservices architectures with service boundaries, event-driven communication, and resilience patterns') and 'when' with three concrete trigger scenarios, mirroring the anchor-5 example structure. The explicit 'Use when' clause rules out the anchor-4 case of a weakly implied 'when'.

5 / 5

Trigger Term Quality

'building distributed systems, decomposing monoliths, or implementing microservices' are natural user phrases, but common variations like 'SOA', 'service-oriented architecture', and 'event-driven architecture' are absent. Not anchor 5 because synonym coverage is incomplete; not 3 because the phrases present are exactly what users would say.

4 / 5

Distinctiveness Conflict Risk

A clear microservices/design niche with distinct triggers, but the 'when building distributed systems' trigger is broad enough to overlap with general distributed-systems or backend-architecture skills. More distinct than anchor 3 (which would overlap with many similar skills), short of anchor 5's minimal conflict risk.

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

rmyndharis/antigravity-skills

Path

skills/microservices-patterns/SKILL.md

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.