backend-architect
Expert backend architect specializing in scalable API design, microservices architecture, and distributed systems.
44
17%
Does it follow best practices?
Impact
89%
1.17xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/backend-architect/SKILL.mdQuality
Discovery
22%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 description reads as a persona/role statement rather than a functional skill description. It lacks concrete actions (what it does), has no 'Use when...' trigger clause, and uses first-person-adjacent framing ('Expert backend architect specializing in...'). The domain keywords provide some signal but are insufficient for reliable skill selection among many options.
Suggestions
Replace the persona framing with concrete action verbs: e.g., 'Designs REST/GraphQL APIs, architects microservices, plans distributed system topologies, reviews backend code for scalability.'
Add an explicit 'Use when...' clause: e.g., 'Use when the user asks about API design, microservices decomposition, service-to-service communication, distributed system patterns, or backend scalability.'
Include more natural trigger terms users would say, such as 'REST API', 'GraphQL', 'service mesh', 'load balancing', 'database sharding', 'event-driven architecture', '.proto files'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague, abstract language like 'specializing in' and 'scalable API design' without listing any concrete actions. It describes a persona rather than specific capabilities (no verbs like 'designs', 'builds', 'reviews'). | 1 / 3 |
Completeness | The 'what' is vague (no concrete actions listed) and there is no 'when' clause at all. It reads as a role description rather than a skill description with explicit trigger guidance. | 1 / 3 |
Trigger Term Quality | Contains some relevant domain keywords like 'API design', 'microservices architecture', and 'distributed systems' that users might mention, but lacks common variations and practical trigger terms like 'REST', 'endpoints', 'service mesh', 'load balancing', etc. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'backend', 'API design', 'microservices', and 'distributed systems' provides some specificity, but 'backend architect' is broad enough to overlap with many coding, infrastructure, or system design skills. | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
12%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 persona description and knowledge inventory rather than an actionable skill. It exhaustively lists backend architecture concepts Claude already knows without providing any concrete, executable guidance, code examples, or specific decision frameworks. The content would benefit enormously from being reduced to a concise workflow with concrete examples and splitting reference material into separate files.
Suggestions
Replace the massive 'Capabilities' enumeration lists with 2-3 concrete, worked examples showing actual architecture outputs (e.g., a sample OpenAPI spec, a Mermaid service diagram, a concrete API contract for a specific use case).
Add executable code examples or templates - for instance, a sample OpenAPI YAML snippet, a Mermaid diagram template for service architecture, or a concrete circuit breaker configuration.
Move the detailed capability lists to a separate REFERENCE.md file and keep SKILL.md focused on the workflow, decision criteria, and key examples.
Add validation checkpoints to the workflow - e.g., 'Before proceeding to step 3, confirm with the user: service boundaries, expected scale, consistency requirements' to make the multi-step process more robust.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with extensive lists of technologies, patterns, and concepts that Claude already knows. The 'Capabilities' section alone is a massive enumeration of well-known backend concepts (OAuth 2.0, JWT, REST, GraphQL, etc.) that adds no new knowledge. The skill reads like a comprehensive textbook table of contents rather than actionable instructions. | 1 / 3 |
Actionability | Contains zero executable code, no concrete examples, no specific commands, and no actual implementation guidance. Everything is described at an abstract level ('Design APIs contract-first', 'Build resilience patterns') without showing how. The 'Example Interactions' section lists prompts but provides no example outputs or responses. | 1 / 3 |
Workflow Clarity | The 'Response Approach' section provides a 10-step numbered sequence that gives a reasonable high-level workflow, and the 'Instructions' section has a 4-step process. However, there are no validation checkpoints, no feedback loops, and no concrete criteria for when to proceed between steps. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. All content is inline in one massive document, with enormous capability lists that could be split into separate reference files. No navigation aids or links to supplementary materials despite the content clearly warranting it. | 1 / 3 |
Total | 5 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- sickn33/antigravity-awesome-skills
- Commit
43280f9
- 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.