CtrlK
BlogDocsLog inGet started
Tessl Logo

backend-architect

Expert backend architect specializing in scalable API design, microservices architecture, and distributed systems. Masters REST/GraphQL/gRPC APIs, event-driven architectures, service mesh patterns, and modern backend frameworks. Handles service boundary definition, inter-service communication, resilience patterns, and observability. Use PROACTIVELY when creating new backend services or APIs.

32

Quality

28%

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 ./.agent/skills/backend-architect/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

7%

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 table of contents with no substantive content. It lacks any concrete, actionable guidance—no code examples, no specific patterns, no templates, no decision frameworks. The main file is padded with redundant descriptions of purpose and philosophy while the actual instructions are abstract to the point of being useless without the sub-skill files, none of which were provided.

Suggestions

Add concrete, actionable content to the main SKILL.md: include at least one executable example (e.g., a REST API endpoint template, an OpenAPI spec snippet, or a service boundary decision checklist) so the file is useful on its own.

Replace the vague 4-step instructions with a specific workflow that includes validation checkpoints, e.g., 'Define API contract → Validate with OpenAPI linter → Implement endpoints → Run integration tests → Review observability dashboards'.

Remove the redundant 'Purpose' and 'Core Philosophy' sections—they restate the description and contain generic advice Claude already knows. Use that space for concrete decision trees or pattern selection guides.

Add brief 1-2 sentence summaries next to each sub-skill link so users can navigate effectively without opening every file (e.g., '### 1. API Design & Patterns - REST vs GraphQL vs gRPC selection criteria, versioning strategies').

DimensionReasoningScore

Conciseness

The content is verbose and redundant. The 'Purpose' section restates the description, 'Core Philosophy' states generic platitudes Claude already knows, and the 'Use this skill when' / 'Do not use this skill when' sections add little value. The 17 sub-skill links are listed without any substantive content in the main file, yet the file still manages to be padded with unnecessary framing.

1 / 3

Actionability

The instructions are entirely abstract ('Capture domain context', 'Define service boundaries', 'Choose architecture patterns') with no concrete code, commands, examples, templates, or specific guidance. There is nothing executable or copy-paste ready anywhere in the content.

1 / 3

Workflow Clarity

The four-step instruction list is vague and lacks any validation checkpoints, feedback loops, or concrete sequencing. Steps like 'Choose architecture patterns and integration mechanisms' provide no actionable detail on how to perform or verify the step.

1 / 3

Progressive Disclosure

The skill does reference 17 sub-skill files with clear one-level-deep links, which is a reasonable progressive disclosure structure. However, no bundle files were provided to verify these references exist, the main file provides almost no substantive overview content to stand on its own, and 17 links without any summary of what each contains makes navigation difficult.

2 / 3

Total

5

/

12

Passed

Description

50%

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

The description reads like a developer resume or persona description rather than a focused skill definition. It uses first-person-adjacent framing ('Expert backend architect', 'Masters') and covers an extremely broad domain without specifying concrete actions. While it includes a 'Use when' clause, the trigger guidance is too narrow relative to the broad capabilities claimed.

Suggestions

Replace persona language ('Expert backend architect', 'Masters') with concrete action verbs describing what the skill does (e.g., 'Designs REST/GraphQL/gRPC API schemas, defines microservice boundaries, implements resilience patterns like circuit breakers and retries').

Expand the 'Use when' clause to cover the full range of scenarios: 'Use when designing APIs, defining service boundaries, setting up inter-service communication, implementing event-driven architectures, or configuring observability for backend systems.'

Add natural user trigger terms that people would actually say, such as 'build a backend', 'create an API endpoint', 'set up microservices', 'design a distributed system', or specific framework names.

DimensionReasoningScore

Specificity

Names the domain (backend architecture) and lists several areas like API design, microservices, distributed systems, resilience patterns, and observability. However, these are more like categories than concrete actions — it says 'handles' and 'masters' but doesn't specify what concrete operations it performs (e.g., 'generates API endpoint definitions', 'creates service mesh configurations').

2 / 3

Completeness

The 'what' is partially addressed through listing domains and capabilities, and there is a 'Use PROACTIVELY when...' clause, but the trigger guidance is very narrow ('creating new backend services or APIs') and doesn't cover many scenarios where this skill would be relevant (e.g., debugging distributed systems, designing event-driven flows, reviewing API designs).

2 / 3

Trigger Term Quality

Includes relevant technical keywords like REST, GraphQL, gRPC, microservices, event-driven, service mesh, and backend. However, these are more jargon-heavy than natural user language. Missing common user phrases like 'build an API', 'create a backend', 'set up a server', 'database design', or file extensions/framework names users might mention.

2 / 3

Distinctiveness Conflict Risk

The scope is extremely broad — covering API design, microservices, distributed systems, event-driven architecture, service mesh, observability, and multiple API paradigms. This breadth means it could easily conflict with more specialized skills for any of these individual areas. The description reads more like a resume than a focused skill definition.

2 / 3

Total

8

/

12

Passed

Validation

81%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation9 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

9

/

11

Passed

Repository
Dokhacgiakhoa/antigravity-ide
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.