CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

oma-backend

Implement server APIs, authentication, and application data access. Schema modeling and query tuning use oma-db.

58

Quality

73%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/oma-backend/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

73%Weight 40%Scale 1-5

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

A well-structured, largely actionable agent skill with an explicit five-scene workflow, verification checkpoints, failure recovery, and clearly signaled one-level references. Its weaknesses are padding from generic DRY/SOLID/KISS explanations and heavy inlining of core rules and architecture patterns that could live in reference files.

Suggestions

Trim the DRY/SOLID/KISS definitions and generic clean-architecture explanations to a single line of project-specific conventions, keeping the token budget for guidance Claude doesn't already know.

Move the 13 Core Rules and the layer-by-layer architecture material into a dedicated reference file (e.g. resources/architecture.md) and keep only the pattern diagram and the top rules inline.

Use a consistent reference path convention — the body points to resources/*.md and ../_shared/core/*.md while none of these files ship in the bundle — and verify the referenced paths resolve in the deployed skill.

DimensionReasoningScore

Conciseness

The body is mostly tight, declarative bullet-style, but the Guardrails section explains textbook concepts Claude already knows — "DRY (Don't Repeat Yourself)", "Single Responsibility: Classes and functions should have one responsibility", "KISS: Keep it simple and clear" — and the Architecture/Repository/Service/Router layer walkthroughs restate standard clean-architecture knowledge.

3 / 5

Actionability

Mostly executable guidance: concrete rules like "JWT + Argon2id for auth (bcrypt acceptable for legacy compatibility); rate limit auth endpoints", "Parameterized queries only (never string interpolation)", an explicit stack-detection order naming manifests (pyproject.toml, package.json, Cargo.toml, go.mod, pom.xml), and a defined stack.yaml verify contract. Minor gaps: no inline code examples, and execution detail is deferred to external resource files.

4 / 5

Workflow Clarity

The PREPARE → ACQUIRE → ACT → VERIFY → FINALIZE scenes give a clear sequence with an explicit verification step ("Run relevant lint, type, test, migration, and checklist commands"), a feedback loop ("If verification fails, fix root cause before handoff"), a run-before-handoff checklist reference, and explicit entry/exit criteria plus a failure-and-recovery section.

5 / 5

Progressive Disclosure

The References section is well-signaled with per-file purposes ("Execution steps (follow for the selected task): resources/execution-protocol.md", "Checklist (run before handoff)") and is one level deep. However, the 13 Core Rules and layer-by-layer architecture guidance are inlined rather than split out, and the referenced resources/ and ../_shared/ files are not present in this bundle, so the structure is good but not optimal.

4 / 5

Total

16

/

20

Passed

Description

58%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A concise, third-person description that names concrete capabilities and includes a helpful sibling-skill boundary, but it entirely lacks a 'when to use' trigger clause and misses common natural keywords like REST, endpoints, backend, and migrations.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user asks for API endpoints, REST/GraphQL work, authentication flows, server-side business logic, or database migrations."

Include natural synonyms users would say — "backend", "REST", "GraphQL", "endpoints", "auth" — alongside the current capability nouns.

Optionally mention background jobs/queues in the description since the body covers them, so the description's coverage matches the skill's scope.

DimensionReasoningScore

Specificity

The description lists three concrete action areas — "Implement server APIs, authentication, and application data access" — which is several specific actions with minor gaps; only "application data access" is somewhat generic, keeping it below a fully comprehensive 5.

4 / 5

Completeness

It has a clear 'what' (implement server APIs, authentication, application data access) but contains no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines.

3 / 5

Trigger Term Quality

It includes some relevant natural keywords ("server APIs", "authentication", "data access") but misses common variations and synonyms users would actually say such as "backend", "REST", "endpoints", "migrations", or "auth", matching the 'some relevant keywords but missing common variations' anchor.

3 / 5

Distinctiveness Conflict Risk

The boundary sentence "Schema modeling and query tuning use oma-db" explicitly disambiguates from the closely related database skill, and the server-API/auth niche is mostly distinct; only minor overlap risk remains with general full-stack work.

4 / 5

Total

14

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

first-fluke/oh-my-agent

Path

skills/oma-backend/SKILL.md

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.