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
Quality
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 functions primarily as a table of contents pointing to sub-skills, which is appropriate for progressive disclosure. However, the main content lacks actionable guidance—the instructions are abstract descriptions rather than concrete steps with examples or templates. The skill would benefit significantly from adding at least one concrete example workflow or decision framework in the main file.
Suggestions
Add a concrete example showing how to apply the 4-step process to a real scenario (e.g., designing a user service API), including specific outputs at each step
Replace vague instructions like 'Define service boundaries' with actionable guidance such as decision criteria, questions to ask, or a checklist
Include at least one executable artifact template (e.g., API contract skeleton, service boundary diagram format, or architecture decision record template)
Add validation checkpoints to the workflow, such as 'Before proceeding to step 3, verify that API contracts include error schemas and versioning strategy'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill has some unnecessary sections like 'Purpose' which largely repeats the description, and 'Core Philosophy' which 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, templates, or specific guidance. It describes what to do abstractly rather than showing how to do it. | 1 / 3 |
Workflow Clarity | There is a 4-step sequence in the Instructions section, but steps are high-level abstractions without validation checkpoints, concrete outputs, or feedback loops. No guidance on what 'done' looks like for each step. | 2 / 3 |
Progressive Disclosure | The skill effectively uses progressive disclosure by providing a clear overview and linking to 17 sub-skills for detailed content. References are one level deep and clearly organized by topic area. | 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 | |
3395991
Table of Contents
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.