arcgis-tables-forms
Configure FeatureTable for tabular data display and FormTemplate with input elements for feature editing forms.
49
37%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./contexts/5.0/skills/arcgis-tables-forms/SKILL.mdQuality
Discovery
32%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 identifies specific component names and their purposes but lacks a 'Use when...' clause, making it incomplete for skill selection. The technical component names provide some distinctiveness but the description would benefit from framework context and natural trigger terms that users would actually say.
Suggestions
Add a 'Use when...' clause specifying trigger scenarios, e.g., 'Use when the user needs to set up a FeatureTable for displaying tabular data or create a FormTemplate for editing features.'
Include the framework or library name these components belong to (e.g., ArcGIS, a specific UI library) to improve distinctiveness and help Claude match the right context.
Add natural language trigger terms users might say, such as 'data table', 'feature grid', 'edit form', 'form layout', or relevant file extensions.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names specific components (FeatureTable, FormTemplate) and actions (configure, display, editing), but doesn't elaborate on the full range of concrete actions or capabilities beyond configuration. | 2 / 3 |
Completeness | Describes what the skill does (configure FeatureTable and FormTemplate) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, missing 'Use when' caps completeness at 2, and the 'what' is also only moderately clear, warranting a 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant terms like 'FeatureTable', 'FormTemplate', 'tabular data', 'input elements', and 'forms', but these are fairly technical/component-specific and may miss natural user language like 'table component', 'data grid', 'form builder', or 'edit form'. | 2 / 3 |
Distinctiveness Conflict Risk | The specific component names (FeatureTable, FormTemplate) provide some distinctiveness, but without context about which framework or library these belong to, it could overlap with other table/form configuration skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive but bloated API reference that prioritizes completeness over efficiency. While the code examples are excellent and fully executable, the sheer volume of property tables, input type enumerations, and inline complete HTML examples makes it a poor fit for a SKILL.md that should be a concise overview. The content would benefit enormously from splitting reference material into separate files and keeping only the most common patterns inline.
Suggestions
Extract property tables (FeatureTable properties, FieldColumnTemplate properties, events) and input type examples into a separate REFERENCE.md file, keeping only the 2-3 most common patterns inline.
Move the complete HTML examples to an EXAMPLES.md file and reference them with one-line descriptions from the main skill.
Add explicit workflow sequences for common multi-step tasks like 'configure and enable table editing' or 'set up form with validation', including error handling and verification steps.
Consolidate the input types section — instead of showing every input type individually, show one complete form example with mixed input types and list the remaining types in a compact table with just type name and key properties.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This skill is extremely verbose at ~500+ lines, with exhaustive property tables, every input type enumerated, and multiple complete HTML examples. Much of this is reference documentation that Claude could infer or that should be in separate files. The property tables alone consume significant tokens for information that's essentially API documentation. | 1 / 3 |
Actionability | The skill provides fully executable code examples throughout — complete HTML pages, working JavaScript snippets with real imports, and concrete configuration objects. The Common Pitfalls section with correct/incorrect examples is particularly actionable. | 3 / 3 |
Workflow Clarity | The skill presents individual features clearly but lacks explicit workflow sequences for multi-step operations like setting up editing (load layer → check capabilities → configure form → enable editing → handle submit → validate). The FeatureForm submit example shows steps but without validation checkpoints or error handling. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of content with no delegation to sub-files. The exhaustive property tables, all input types, expression examples, and two complete HTML examples should be split into referenced files. The Related Skills section at the end shows awareness of cross-referencing but the skill itself badly needs decomposition. | 1 / 3 |
Total | 7 / 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (890 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Commit
d84407b
- 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.