Agent Skills: design-consistency-auditor
Hunts design-token drift across a frontend — hardcoded hex values where semantic tokens belong, arbitrary spacing outside the scale, one-off classes duplicating a design-system component, and patterns that diverge screen to screen. Measures against the project's own tokens and class conventions, discovered from the codebase first rather than assumed. Triggers on audit design consistency, review component styling, check color palette usage, find hardcoded colors, or identify design debt. For a scored multi-dimension quality report, use `audit`; for WCAG conformance, use `accessibility`.
ID: shipshitdev/library/design-consistency-auditor
353
Install this agent skill to your local
Skill Files
The files that make up design-consistency-auditor.
More agent skills
- design-system-starterCreate and evolve design systems with design tokens, component architecture, accessibility guidelines, and documentation templates. Ensures consistent, scalable, and accessible UI across products.
- error-diagnostics-error-traceYou are an error tracking and observability expert specializing in implementing comprehensive error monitoring solutions. Set up error tracking systems, configure alerts, implement structured logging,
- coverage-analysisMeasures and interprets what a fuzzing campaign actually reaches, using llvm-cov, lcov, or a fuzzer's own coverage output. Covers baselining a new campaign, reading coverage reports, and turning uncovered regions into harness, seed, or dictionary work. Use when a fuzzer plateaus, when judging whether a harness is effective, after changing a harness, or when asking why some code is never reached.
- create-commandCreate new commands for the code-forge application. Commands are stored as .md files in the <cwd>/.forge/commands directory with YAML frontmatter (name, description) and markdown body containing command steps. Use when users need to add new commands, modify existing commands, or understand the command file structure. Supports special command tags like <lint> and <test> for automated workflows.
- commit-changesCreate a git commit for the current changes. Use when asked to commit changes, make a commit, generate a commit message, or commit the current worktree with optional user-provided context.
- open-sourcingThis skill should be used when the user asks to "open source this project", "prepare this repository for public release", "make this repo public", "check open-source readiness", "choose a license for this project", or "set up release automation" ahead of a public launch. Provides a release-readiness workflow covering secrets hygiene, licensing, documentation, CI, and language-specific packaging.