normalize
Audits and realigns UI to match design system standards, spacing, tokens, and patterns. Use when the user mentions consistency, design drift, mismatched styles, tokens, or wants to bring a feature back in line with the system.
63
55%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.codex/skills/normalize/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid skill description with excellent trigger terms and completeness. It clearly communicates both what the skill does and when to use it, with natural language triggers that users would actually say. The main weakness is that the capability description could be more specific about the concrete actions performed (e.g., replacing hardcoded values, fixing spacing violations, updating component patterns).
Suggestions
Expand the 'what' portion with more concrete actions, e.g., 'Replaces hardcoded values with design tokens, fixes spacing and sizing violations, updates deprecated component patterns to current standards.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (UI/design system) and some actions ('audits and realigns UI'), but the specific actions are somewhat vague—'realigns' and 'match design system standards' are broad. It doesn't list multiple concrete discrete actions like 'replace hardcoded values with tokens, fix spacing violations, update component usage'. | 2 / 3 |
Completeness | Clearly answers both 'what' (audits and realigns UI to match design system standards, spacing, tokens, and patterns) and 'when' (explicit 'Use when...' clause with specific trigger scenarios like consistency, design drift, mismatched styles, tokens). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'consistency', 'design drift', 'mismatched styles', 'tokens', 'bring a feature back in line with the system'. These are terms a user would naturally use when they need this kind of audit. | 3 / 3 |
Distinctiveness Conflict Risk | The combination of 'design system standards', 'design drift', 'tokens', and 'realign' creates a clear niche that is unlikely to conflict with general UI development or styling skills. The focus on auditing against a design system is quite distinct. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
20%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads more like a general design audit philosophy document than an actionable skill for Claude. It lacks any concrete code examples, specific commands, or executable patterns—everything remains at the level of abstract guidance. The content is also verbose, explaining concepts Claude already understands (design tokens, accessibility, DRY principles) and including motivational language that wastes tokens.
Suggestions
Add concrete, executable examples: show a before/after code snippet of replacing a hard-coded value with a design token, or a grep command to find violations (e.g., `grep -rn 'color: #' src/components/`)
Remove explanations of concepts Claude already knows (what design tokens are, what DRY means, what accessibility entails) and replace with project-specific patterns or token names
Add explicit validation checkpoints: e.g., 'After replacing tokens, run `npm run lint` and verify no hard-coded color values remain with `grep -rn "color: #" src/`'
Clarify what $frontend-design and $teach-impeccable are and where they live, or inline the critical information needed from them
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Significant verbosity throughout. Explains concepts Claude already knows (what design tokens are, what typography consistency means, what DRYness is). The motivational closing paragraph ('You are a brilliant frontend designer...') wastes tokens. Many bullet points describe obvious design audit steps that don't add novel information. | 1 / 3 |
Actionability | No concrete code, commands, or executable examples. The entire skill is abstract guidance ('Replace hard-coded values with typographic tokens', 'Apply design system color tokens') without showing how. No grep commands, no code snippets for finding violations, no example of what a fix looks like. References to '$frontend-design' and '$teach-impeccable' are opaque without explanation. | 1 / 3 |
Workflow Clarity | There is a clear three-phase sequence (Plan → Execute → Clean Up) which provides reasonable structure. However, there are no explicit validation checkpoints between phases—no step to verify changes match the design system before proceeding, no feedback loop for catching regressions during execution. The 'Verify quality' step at the end is vague. | 2 / 3 |
Progressive Disclosure | References external skills ($frontend-design, $teach-impeccable) which suggests some content splitting, but these references are unclear—it's not obvious what they contain or where they live. The main content itself is a monolithic document that could benefit from splitting the detailed Execute checklist into a separate reference file. | 2 / 3 |
Total | 6 / 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 |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- pbakaus/impeccable
- Commit
db1add7
- 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.