Name: webiny-api-cms-custom-field-type
Rating: 60 (1 reviews)
Author: webiny

webiny-api-cms-custom-field-type

How to implement a custom CMS field type that integrates with the model builder's fluent API. Covers extending DataFieldBuilder, composing validator interfaces, creating a FieldTypeFactory, registering via DI, and module augmentation for TypeScript autocomplete on the fields() registry.

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/user-skills/api/custom-field-type/SKILL.md

Quality

Content

75%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 strong, executable reference: complete code for every component, dense Webiny-specific tables instead of generic explanation, and a clear workflow with a key-rules checklist. The main defect is an internal inconsistency between the example's module augmentation and Key Rule 2, plus an unexplained renderer-registry augmentation.

Suggestions

Reconcile the module augmentation: make the complete example and Key Rule 2 use the identical augmentation form so the copy-paste code is unambiguous.

Remove or explain the IFieldRendererRegistry/myCustomRenderer augmentation, which is unrelated to the slug example.

Add a short verification step (e.g., a tsc/type-check to confirm fields.slug() autocomplete resolves after registration).

Dimension	Reasoning	Score
Conciseness	The body is lean and table-driven, delivering only Webiny-specific API details Claude cannot know (builder methods, validator signatures, settings shapes) with no padding of general concepts. It is not a 5 because the numbered comments in the example, the duplicated module-augmentation guidance (example vs. Key Rule 2), and the two validator tables could be tightened further.	4 / 5
Actionability	Complete, copy-paste-ready TypeScript is provided for the builder, factory, FieldType implementation, feature registration, and model usage. It is not a 5 because the example's module augmentation ("interface IFieldBuilderRegistry") contradicts Key Rule 2 ("namespace FieldBuilderRegistry { interface Interface }") and the unexplained IFieldRendererRegistry/"myCustomRenderer" block leaves a gap a reader cannot resolve.	4 / 5
Workflow Clarity	The create → register → augment → use sequence is coherent, with a three-part structure breakdown, directory layout, and a Key Rules checklist covering the two fragile points (unique type string, registration order). It is not a 5 because no verification checkpoint is offered (e.g., confirming autocomplete resolves via a type check), though the destructive/batch cap does not apply to code authoring.	4 / 5
Progressive Disclosure	A single well-organized file with clearly labeled sections and a Related Skills pointer that signals where adjacent knowledge lives. It is not a 5 because roughly 60 lines of validator/API reference tables sit inline in SKILL.md where a one-level-deep reference file would be the better split.	4 / 5
	Total	16 / 20 Passed

Description

63%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 highly specific description that clearly conveys what the skill does through five concrete actions, but it omits any "Use when..." trigger guidance and never mentions Webiny, the most natural keyword a user would say. Adding an explicit trigger clause and the framework name would lift the completeness and trigger-term dimensions.

Suggestions

Append an explicit trigger clause, e.g., "Use when a Webiny CMS model needs a field type or validation behavior not covered by the built-in types."

Mention Webiny by name in the description so users saying "Webiny custom field" naturally match this skill.

Include one or two natural-synonym trigger phrases such as "add a new field type" or "custom CMS field" alongside the API-level terminology.

Dimension	Reasoning	Score
Specificity	The description enumerates multiple concrete actions — "extending DataFieldBuilder", "composing validator interfaces", "creating a FieldTypeFactory", "registering via DI", and "module augmentation" — giving comprehensive coverage of the implementation task. It is not a 4 because there are no meaningful gaps: every major component of building a custom field type is named.	5 / 5
Completeness	The "what" is explicitly and concretely answered ("How to implement a custom CMS field type... Covers extending DataFieldBuilder..."), but there is no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines. It is not a 2 because the "what" is far from vague, and not a 4 because the "when" is entirely absent rather than merely implicit.	3 / 5
Trigger Term Quality	Relevant domain keywords are present ("custom CMS field type", "model builder's fluent API", "TypeScript autocomplete"), but the description never names the framework (Webiny) and omits natural user phrasings like "add a new field type" or "Admin UI field". It is not a 4 because these are common variations a user would actually say, not just a few missing synonyms.	3 / 5
Distinctiveness Conflict Risk	The niche is well-specified ("custom CMS field type", "DataFieldBuilder", "FieldTypeFactory", "fields() registry"), making wrong-skill triggering unlikely. It is not a 5 because "integrates with the model builder's fluent API" overlaps with the closely related content-models skill, and the framework name is never stated.	4 / 5
	Total	15 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: webiny/webiny-js
Path: skills/user-skills/api/custom-field-type/SKILL.md
Commit: f0d3d3e

Reviewed: 3 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.