backend-dev-guidelines
Opinionated backend development standards for Node.js + Express + TypeScript microservices. Covers layered architecture, BaseController pattern, dependency injection, Prisma repositories, Zod validation, unifiedConfig, Sentry error tracking, async safety, and testing discipline.
Install with Tessl CLI
npx tessl i github:Dokhacgiakhoa/antigravity-ide --skill backend-dev-guidelines75
Quality
70%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agent/skills/backend-dev-guidelines/SKILL.mdDiscovery
67%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 excels at specificity and distinctiveness by naming concrete technologies and patterns (Prisma, Zod, Sentry, BaseController). However, it lacks an explicit 'Use when...' clause which limits its completeness score, and the trigger terms are heavily technical rather than including natural phrases a user might say when needing backend development help.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when building Node.js APIs, Express microservices, or when the user mentions backend architecture, API endpoints, or TypeScript server development.'
Include more natural user phrases alongside technical terms, such as 'building APIs', 'REST endpoints', 'server-side code', or 'backend services'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and patterns: 'layered architecture, BaseController pattern, dependency injection, Prisma repositories, Zod validation, unifiedConfig, Sentry error tracking, async safety, and testing discipline.' These are concrete, named technologies and patterns. | 3 / 3 |
Completeness | Clearly answers 'what' (opinionated backend development standards covering specific patterns), but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied through the technology stack mention. | 2 / 3 |
Trigger Term Quality | Contains good technical keywords (Node.js, Express, TypeScript, Prisma, Zod, Sentry) that developers would use, but missing common variations like 'API development', 'REST', 'backend API', or 'server-side'. The terms are specific but lean technical rather than natural user language. | 2 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: specifically 'Node.js + Express + TypeScript microservices' with named patterns like BaseController, Prisma, Zod. Unlikely to conflict with generic coding skills or other backend frameworks. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured backend development skill with strong actionability through concrete code examples and excellent progressive disclosure via sub-skills. The main weaknesses are some verbosity in framing/BFRI sections and missing feedback loops in the validation checklist for error recovery scenarios.
Suggestions
Trim the introductory framing and BFRI section - Claude doesn't need to be told it's a 'senior backend engineer' or given a complex scoring formula; focus on the actionable patterns.
Add explicit recovery steps to the validation checklist (e.g., 'If BFRI < 3: document risks in PR, add compensating tests, get architecture review').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some unnecessary framing ('You are a senior backend engineer', 'This skill defines how backend code must be written') and the BFRI section adds significant overhead for what could be simpler guidance. The core patterns are well-presented but could be tighter. | 2 / 3 |
Actionability | Provides concrete, executable code examples throughout - BaseController pattern, Zod validation, asyncErrorWrapper usage, DI patterns, and repository methods are all copy-paste ready with clear do/don't comparisons. | 3 / 3 |
Workflow Clarity | The layered architecture flow is clear (Routes → Controllers → Services → Repositories), but the validation checklist at the end lacks explicit sequencing and feedback loops. No guidance on what to do when validation fails or how to recover from architectural violations. | 2 / 3 |
Progressive Disclosure | Excellent structure with a comprehensive overview in the main file and 11 clearly-signaled sub-skills for detailed topics. References are one level deep and well-organized by concern (architecture, testing, validation, etc.). | 3 / 3 |
Total | 10 / 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 | |
- 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.