Menu

Individual skill

consistency-internal

Apply internal consistency — making your product coherent with itself across all surfaces, components, and flows. Use when designing or auditing component libraries, defining design tokens, settling cross-team naming conventions, planning a design-system rollout, integrating acquired or legacy code, or evaluating whether two features should share or diverge in their interaction model. Internal consistency is enforced through design systems, shared vocabularies, and process discipline; it erodes through hand-off losses, sprint-driven shortcuts, and team boundaries that don't coordinate.

plugins/HDeibler/universal-design-principles/plugins/cognition-and-learnability-principles/skills/consistency-internal/SKILL.md

Read pinned source

Source commit d780783eba4ecc7c8b9429f95c9362df95f07c61

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Network or broad shell
Last checked
Nov 4, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
1,533
Repository last updated
Nov 6, 2026
License
Apache-2.0

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Consistency — internal

Internal consistency is the property of a product being coherent with itself. Every screen, every flow, every component looks like it came from the same product, and equivalent operations behave the same way. Users transfer their learning across surfaces because the product rewards them for doing so.

Internal consistency is hard to maintain by good intentions alone. Teams ship in parallel, designers move on, design tokens drift, components get forked. The systems that maintain consistency over years are the ones that build it into the production process — design systems with real components, design tokens enforced by code, lint rules that fail builds for off-system colors.

## The mechanisms of internal consistency

Internal consistency rests on a few mechanisms working together.

**A design system with real components.** A library of buttons, inputs, modals, cards, tabs, etc., that is the canonical implementation. Designers compose with it; engineers use it; everyone gets the same behavior because there's only one implementation to use. The design system is not a documentation site full of screenshots — it's actual production components, code, and design tokens that flow through to the product.

**Design tokens enforced by code.** Colors, spacings, typographic sizes, border-radii, shadows, animations — all defined as named tokens (`color.primary.500`, `spacing.4`, `radius.md`) and used through those names rather than as raw values. When a designer changes the canonical primary blue, every component that uses `color.primary.500` updates automatically. When an engineer hard-codes a custom blue, a lint rule flags it.