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.
55
46%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agent/skills/backend-architect/SKILL.mdQuality
Discovery
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 establishes a clear domain focus on backend architecture and lists relevant technologies, but relies heavily on buzzwords and category names rather than concrete actions Claude would perform. The 'Use when' clause is present but too narrow, and the description uses problematic framing ('Expert backend architect specializing in') rather than action-oriented third-person voice describing what the skill does.
Suggestions
Replace role-based framing ('Expert backend architect specializing in') with action verbs describing concrete capabilities (e.g., 'Designs REST/GraphQL/gRPC API contracts, defines microservice boundaries, implements circuit breakers and retry patterns').
Expand the 'Use when' clause to cover more trigger scenarios: 'Use when designing APIs, splitting monoliths into services, implementing service-to-service communication, adding observability, or troubleshooting distributed system issues'.
Add natural language trigger terms users would actually say: 'backend', 'server-side code', 'API endpoints', 'service architecture', 'scaling services', 'message queues'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (backend architecture) and lists several areas like 'REST/GraphQL/gRPC APIs, event-driven architectures, service mesh patterns' but these are more categories than concrete actions. 'Handles service boundary definition' is somewhat specific but most items are domain areas rather than actionable capabilities. | 2 / 3 |
Completeness | The 'what' is partially addressed through listing domains and technologies. The 'when' clause exists ('Use PROACTIVELY when creating new backend services or APIs') but is narrow and doesn't cover other valid use cases like refactoring existing services, debugging distributed systems, or designing communication patterns. | 2 / 3 |
Trigger Term Quality | Includes relevant technical terms users might say like 'API', 'microservices', 'REST', 'GraphQL', 'gRPC', but many terms are jargon ('service mesh patterns', 'resilience patterns') that typical users may not naturally use. Missing common variations like 'backend development', 'server-side', 'web services'. | 2 / 3 |
Distinctiveness Conflict Risk | While 'backend architect' and 'microservices' provide some distinction, terms like 'API design' and 'scalable' are broad enough to potentially conflict with general coding skills or other architecture-focused skills. The scope is somewhat defined but could overlap with API-specific or infrastructure skills. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill has excellent progressive disclosure with well-organized sub-skill references, but severely lacks actionability. The instructions are abstract guidance without concrete examples, templates, or specific questions to ask during architecture design. The content would benefit greatly from executable checklists, example API contracts, and specific decision frameworks.
Suggestions
Add concrete examples: include a sample API contract template, example service boundary diagram, or specific questions to ask when gathering requirements
Make instructions actionable: replace vague steps like 'Define service boundaries' with specific techniques, checklists, or decision trees (e.g., 'Ask: Does this capability need independent scaling? Does it have a distinct data ownership boundary?')
Add validation checkpoints to the workflow: specify what artifacts should exist after each step and how to verify the design is sound before proceeding
Remove redundant sections: consolidate 'Purpose' and 'Core Philosophy' into the main instructions or eliminate them entirely as they don't add actionable guidance
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill has some unnecessary sections like 'Purpose' that largely repeats the description, and 'Core Philosophy' that states general principles Claude already knows. However, it's not excessively verbose and the structure is reasonably tight. | 2 / 3 |
Actionability | The instructions are extremely vague ('Capture domain context', 'Define service boundaries', 'Choose architecture patterns') with no concrete examples, code snippets, specific questions to ask, or templates. It describes what to do abstractly rather than showing how. | 1 / 3 |
Workflow Clarity | There is a 4-step sequence in the Instructions section, but steps are high-level without validation checkpoints, decision criteria, or feedback loops. No guidance on what constitutes 'done' for each step or how to verify correctness. | 2 / 3 |
Progressive Disclosure | The skill appropriately uses a hub-and-spoke model with 17 clearly labeled sub-skills linked at one level deep. Navigation is clear with descriptive names, and the main file serves as an overview pointing to detailed materials. | 3 / 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.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
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
- Commit
332e58b
- 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.