CtrlK
BlogDocsLog inGet started
Tessl Logo

webiny-api-permissions

Schema-based permission system for API features. Use this skill when implementing authorization in use cases, defining permission schemas with createPermissionSchema, creating injectable permissions via createPermissionsAbstraction/createPermissionsFeature, checking read/write/delete/publish permissions, handling own-record scoping, or testing permission scenarios. Covers the full pattern from schema definition to use case integration to test matrices.

67

Quality

84%

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

SKILL.md
Quality
Evals
Security

Quality

Content

71%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, highly actionable body with complete core code examples and a clear two-layer architecture walkthrough. Its weaknesses are repetition of the canDelete gotcha, abbreviated later use-case snippets, a missing testing section the description advertises, and no use of reference files to split the long body.

Suggestions

Add a testing section (or reference file) with the permission test matrix the description promises — e.g., the identity/permission combinations (full access, wildcard, entity-level full/own, own+no-item for each method) to verify against.

Move the method reference table and the use-case implementation patterns into references/ files (e.g., references/methods.md, references/use-cases.md), keeping SKILL.md as a lean overview with clearly signaled links.

State the canDelete-without-item behavior once (the Delete Use Case section or Gotchas) instead of three times, and note explicitly why the '// ... events + repository' elisions are safe to omit.

DimensionReasoningScore

Conciseness

Mostly efficient — dense tables, working code, and no explanation of concepts Claude already knows — but the canDelete/own:true rule is repeated three times (method table, Delete Use Case section, Gotcha #1) and the four use-case snippets repeat the same NotAuthorizedError shape, which could be trimmed.

4 / 5

Actionability

The schema, abstraction, feature, registration, and Get use case examples are complete and copy-paste ready, and the method reference table gives concrete semantics. However, the Update, Delete, and Publish snippets elide bodies with '// ... events + repository', leaving minor gaps that keep them from being fully executable.

4 / 5

Workflow Clarity

The layered sequence (schema definition → DI artifacts → feature registration → file structure → methods → use-case patterns → gotchas) is clear, and the 'Get use case is the central ownership gate' checkpoint makes enforcement inheritance explicit. But the description promises test matrices and the body contains no testing or verification guidance, leaving a validation gap.

4 / 5

Progressive Disclosure

No bundle files exist and the 363-line body is monolithic: the method reference table and the four use-case implementation patterns would naturally live in references/ files. Section structure itself is good, but content that should be separate is inlined and there are no external references to signal.

3 / 5

Total

15

/

20

Passed

Description

88%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 strong description: specific, function-named capabilities, an explicit 'Use this skill when...' trigger clause, and a clear statement of scope. Its only gaps are a few missing natural synonyms and no explicit API-vs-admin discriminator against its sibling skill.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions named by their actual API functions ("defining permission schemas with createPermissionSchema", "creating injectable permissions via createPermissionsAbstraction/createPermissionsFeature", "checking read/write/delete/publish permissions", "handling own-record scoping", "testing permission scenarios"), giving comprehensive coverage of the skill's surface.

5 / 5

Completeness

It explicitly answers both what ("Schema-based permission system for API features... Covers the full pattern from schema definition to use case integration to test matrices") and when ("Use this skill when implementing authorization in use cases, defining permission schemas..."), with concrete trigger phrases rather than a weakly implied when-clause.

5 / 5

Trigger Term Quality

Good natural keyword coverage ("authorization", "permissions", "read/write/delete/publish", "own-record scoping"), but common synonyms such as "access control", "RBAC", or "auth" are missing, so a few natural phrasings a user might say would not match.

4 / 5

Distinctiveness Conflict Risk

The Webiny API permission niche and function-name triggers make it clearly distinct, but it overlaps with the closely related admin-side skill (webiny-admin-permissions) that covers the same permission schema concept from the UI side — the description does not include a discriminator like "API/server-side".

4 / 5

Total

18

/

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
webiny/webiny-js
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.