backend-dev-guidelines

You are a senior backend engineer operating production-grade services under strict architectural and reliability constraints. Use when routes, controllers, services, repositories, express middleware, or prisma database access.

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

77%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is highly actionable with concrete code and a clear BFRI-plus-checklist workflow, but it is a long monolithic file with redundant and boilerplate sections and no progressive disclosure into reference files.

Suggestions

Remove the duplicate "When to Use" block and the generic closing boilerplate (the canned "When to Use"/"Limitations" paragraphs at lines 346-352) to tighten conciseness.

Split detailed material (extended code patterns, full BFRI worked examples) into reference files under references/ and link to them from SKILL.md to enable progressive disclosure for this long skill.

Replace the trivial test example (`expect(user).toBeDefined()`) with a meaningful assertion that actually exercises the service behavior.

Dimension	Reasoning	Score
Conciseness	The body is largely dense rules and code rather than explanations of concepts Claude already knows, but it carries redundancy (a duplicated "When to Use" section at lines 60-69 and 346-347) and generic boilerplate at the tail ("This skill is applicable to execute the workflow...", the canned Limitations block) that could be trimmed, matching the 'mostly efficient but could be tightened' anchor.	2 / 3
Actionability	It supplies concrete, copy-paste-ready TypeScript patterns throughout (BaseController extension, Sentry capture, unifiedConfig import, Zod parse, DI constructor injection, asyncErrorWrapper) plus specific naming conventions, a directory tree, and a BFRI formula, matching the 'fully executable code/commands; specific examples' anchor.	3 / 3
Workflow Clarity	The BFRI section gives a sequenced gate (assess dimensions -> compute -> interpret table -> act) and section 12 provides an explicit Operator Validation Checklist as a pre-merge checkpoint, satisfying the 'clear sequence with explicit validation steps; checklists' anchor.	3 / 3
Progressive Disclosure	No bundle files exist and the ~340-line skill is a single monolithic document with all detail inline; it is well-organized into clear sections but content that could be split (full code patterns, BFRI detail) is not separated into referenced files, matching the 'some structure but content that should be separate is inline' anchor.	2 / 3
	Total	10 / 12 Passed

Description

65%

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 has strong trigger coverage and a clear, distinct backend niche with an explicit Use-when clause, but its specificity is dragged down by second-person persona framing and buzzword-heavy role language instead of concrete actions.

Suggestions

Rewrite in third person with concrete action verbs (e.g., "Enforces layered backend architecture for Node.js/Express/Prisma services") instead of the second-person persona opener "You are a senior backend engineer...".

Replace the buzzword framing ("production-grade services under strict architectural and reliability constraints") with the specific actions the skill governs (routing, validation, error handling, repository access).

Add common trigger variations a user would naturally say, such as "API endpoints", "database queries/models", and "request validation".

Dimension	Reasoning	Score
Specificity	The description names the backend domain ("routes, controllers, services, repositories, express middleware, or prisma database access") but lists no concrete actions, and the persona framing ("You are a senior backend engineer operating production-grade services under strict architectural and reliability constraints") is buzzword-heavy; the second-person voice triggers the rubric's -1 specificity penalty, dropping a base of 2 to 1.	1 / 3
Completeness	It explicitly answers both what (backend engineering under architectural/reliability constraints) and when, with an explicit "Use when routes, controllers, services, repositories, express middleware, or prisma database access" trigger clause, satisfying the top anchor's requirement for explicit triggers.	3 / 3
Trigger Term Quality	Terms like "routes", "controllers", "services", "express middleware", and "prisma database access" are natural for a backend developer, but common variations such as "API", "endpoints", "database queries", or "models" are missing, matching the 'some relevant keywords but missing common variations' anchor.	2 / 3
Distinctiveness Conflict Risk	The stack-specific triggers (prisma, express middleware, repositories, controllers) carve a clear backend niche that is unlikely to fire for unrelated skills, matching the 'clear niche with distinct triggers' anchor.	3 / 3
	Total	9 / 12 Passed

Validation

93%

Warnings & errors only

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

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: sickn33/antigravity-awesome-skills
Commit: 615669b

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

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.