- Home
- Skills
- Pbakaus
- Impeccable
- Normalize
normalize_skill
- JavaScript
10.4k
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 pbakaus/impeccable --skill normalize- SKILL.md4.0 KB
Overview
This skill normalizes UI features to match a project's design system so interfaces are consistent, accessible, and maintainable. It guides discovery, analysis, planning, and execution to replace one-off implementations with design-system-aligned components and tokens. The result is predictable UX, fewer regressions, and a cleaner shared component surface.
How this skill works
First, it runs a Context Gathering Protocol to find and study the design system, tokens, and patterns. Then it analyzes the target feature to identify cosmetic and functional deviations, creates a prioritized normalization plan, and executes changes across typography, color, spacing, components, motion, responsiveness, and accessibility. Finally, it consolidates reusable code, removes orphaned artifacts, and verifies quality through linting, type checks, and tests.
When to use it
- When a feature uses hard-coded styles or custom components that diverge from the design system
- During UI refactors to improve consistency and reduce maintenance overhead
- Before adding new features so they follow established tokens and patterns
- When accessibility or responsive behavior is inconsistent with product standards
- When onboarding a new design system or consolidating multiple style sources
Best practices
- Always run the Context Gathering Protocol; never guess design intent or tokens
- Prefer design system components and tokens over new one-off implementations
- Prioritize UX and accessibility before visual polish when resolving conflicts
- Document any shared components moved into the system and delete obsolete code
- Verify changes with linting, type checks, responsive checks, and accessibility audits
Example use cases
- Replace a custom modal with the design system dialog component and map tokens for spacing, typography, and focus behavior
- Convert hard-coded color values to theme color tokens and ensure contrast meets accessibility thresholds
- Refactor a bespoke form input into the system input component to unify validation, labels, and error states
- Align a feature's responsive breakpoints and grid layout to the system’s layout utilities
- Audit animations and micro-interactions to match system timings and easing for consistent motion
FAQ
Follow the Context Gathering Protocol and run teach-impeccable to collect missing context. If gaps remain, ask clarifying questions and prefer patterns used elsewhere in the product rather than inventing new ones.
Can I introduce a new component when solving a problem?
Only introduce a new component if there is a clear, repeated need that the design system cannot address. When you do, move it into the shared system path and document its tokens, variants, and accessibility behavior.