- Home
- Skills
- Steveclarke
- Dotfiles
- I Normalize
i-normalize_skill
- Shell
31
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
3 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill steveclarke/dotfiles --skill i-normalize- SKILL.md4.0 KB
Overview
This skill normalizes UI features to match your design system, ensuring consistent visuals, spacing, components, and accessibility across projects. It drives a disciplined discovery → plan → execute workflow so changes follow established tokens, components, and interaction patterns. Use it to eliminate one-off styles, enforce tokens, and align UX with system standards.
How this skill works
Before making changes it runs a Context Gathering Protocol (via the i-frontend-design skill) to discover design documentation, tokens, and component patterns. It inspects code and assets to identify deviations (hard-coded colors, custom spacing, bespoke components, missing ARIA, etc.), creates a concrete normalization plan, and then replaces patterns with design-system equivalents while preserving accessibility and responsive behavior. After refactors it consolidates components, removes orphans, and runs linting/tests to prevent regressions.
When to use it
- When a feature visually or behaviorally diverges from your design system
- During UI refactors to replace one-off implementations with shared components
- Before shipping major UI updates to ensure consistency and accessibility
- When consolidating multiple repos or developer machines onto the same design standards
- When onboarding new components into the shared design system
Best practices
- Always run the Context Gathering Protocol first; if no context exists, run teach-impeccable to establish it
- Prioritize UX and accessibility over visual tweaks—match established user flows and contrast/token rules
- Replace hard-coded values with design tokens (color, typography, spacing) rather than creating new variables
- Prefer design-system components over custom implementations; only extend the system when necessary and contribute back
- Consolidate reusable pieces into the shared UI path and remove dead code to keep the codebase DRY
Example use cases
- Normalize a legacy admin panel that uses multiple font sizes, colors, and spacing conventions into the current style tokens and grid
- Refactor a custom modal and form controls to use system components, improving keyboard/focus behavior and ARIA support
- Audit and update responsive breakpoints and spacing for a cross-platform feature to match the design system’s layout rules
- Convert an ad-hoc button library into standard variants using the design system’s tokens and motion timing
FAQ
Follow the protocol: run teach-impeccable to create initial context before normalizing. Don’t guess—capture principles and tokens first.
Can I create new components during normalization?
Only when a genuine gap exists. New components should be designed to join the shared system and then contributed back; avoid one-off components.