engram-ui-elements

Creation rules for Engram UI elements, pages, cards, metrics, and detail flows. Trigger: Adding or changing dashboard UI components or connected browsing flows.

Quality

70%

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/ui-elements/SKILL.md

Quality

Content

65%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.

The body is a lean, well-structured set of Engram UI design rules that assumes Claude's competence and needs no external references. Its weakness is that the guidance is mostly design heuristics rather than concrete executable steps or a sequenced workflow with checkpoints.

Suggestions

Tighten or remove the "When to Use" section since it duplicates the frontmatter Trigger clause, or repurpose it to link element types to specific user requests.

Convert abstract constraints into concrete directives, e.g., replace "metrics must reflect real system state" with "back each metric with a live query or computed field; omit metrics that have no underlying data source."

For flows involving batch or destructive UI changes (e.g., deleting entities from lists), add an explicit validation/confirmation checkpoint so the workflow can score higher on clarity.

Dimension	Reasoning	Score
Conciseness	The body is lean and well-organized into three tight sections with no concept explanations Claude would not already know. It is not 5 because the "When to Use" section largely restates the frontmatter Trigger clause, a minor redundancy that could be trimmed.	4 / 5
Actionability	Some rules are concrete and actionable (e.g., "Prefer connected flows: project -> session -> observation -> full detail" and the cards-vs-tables mapping), but several are abstract constraints ("must reflect real system state, not decorative counters", "should lead somewhere useful"). It is not 4 because much of the guidance states design principles rather than specific, executable directives.	3 / 5
Workflow Clarity	The content is organized as numbered and bulleted rule lists rather than a sequenced workflow, and there are no validation checkpoints or feedback loops. It is not lower because the rules are clearly grouped and legible; it is not 4+ because no multi-step sequence or checkpoints are present (and the skill is not single-purpose enough to fully claim the simple-skill exception).	3 / 5
Progressive Disclosure	The body is under 50 lines, no external references are needed, and it is cleanly split into three well-signaled sections (When to Use, UX Rules, Composition Rules). Per the simple-skills guidance, this satisfies the top anchor for progressive disclosure without bundle files.	5 / 5
	Total	15 / 20 Passed

Description

75%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.

The description clearly states both what the skill governs and when to trigger it, with concrete Engram-specific element categories and an explicit Trigger clause. It is strong but stops short of the top anchor due to a generic verb and slightly high-level trigger phrasing.

Suggestions

Replace the generic verb "Creation rules" with concrete actions, e.g., "Create and modify Engram UI pages, cards, metrics, tables, and detail flows."

Expand the Trigger clause to name the component-level phrases users would say, e.g., "Trigger: adding or changing dashboard cards, metrics, tables, list views, or connected detail flows."

Add common synonyms or file/extension cues if applicable to broaden natural trigger-term coverage.

Dimension	Reasoning	Score
Specificity	"Creation rules for Engram UI elements, pages, cards, metrics, and detail flows" names the domain plus several concrete element categories (pages, cards, metrics, detail flows), listing several specific targets with only minor coverage gaps. It does not reach 5 because the verb ("Creation rules") is generic rather than a comprehensive set of distinct actions.	4 / 5
Completeness	Both "what" (creation rules for Engram UI elements) and "when" (an explicit "Trigger:" clause) are present. It falls short of 5 because the trigger, while explicit, is fairly high-level and does not enumerate the concrete user phrases that map to each element type.	4 / 5
Trigger Term Quality	"Trigger: Adding or changing dashboard UI components or connected browsing flows" supplies reasonably natural phrases a dashboard developer would say. It is not 5 because it lacks common synonyms or explicit component-level variations (e.g., "cards", "metrics", "tables") as trigger terms.	4 / 5
Distinctiveness Conflict Risk	The Engram-specific framing ("Engram UI elements", "connected browsing flows") carves a clear niche with low conflict risk against unrelated skills. It is not 5 because "dashboard UI components" could still overlap with a generic dashboard/UI styling skill.	4 / 5
	Total	16 / 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: Gentleman-Programming/engram
Path: skills/ui-elements/SKILL.md
Commit: 47f281c

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