# Understanding Shape Consistency Rules and Corner‑Radius Systems in taste-skill > Master shape consistency rules and corner-radius systems in taste-skill. Learn how the Shape Consistency Lock ensures uniform design across your pages. - Repository: [Leon Lin/taste-skill](https://github.com/Leonxlnx/taste-skill) - Tags: deep-dive - Published: 2026-06-05 --- **The taste-skill design system mandates a Shape Consistency Lock that forces every page to adopt exactly one corner‑radius scale—either all‑sharp, all‑soft, or all‑pill—and prohibits mixed shapes unless a documented exception rule is consistently applied.** The `Leonxlnx/taste-skill` repository codifies a strict, anti‑slop visual language through its core skill specification. Understanding shape consistency rules and corner‑radius systems in taste-skill begins with the mandatory lock defined in the project’s source files. This guide explains the rule, the three permitted radius scales, and how to implement them in production code. ## The Shape Consistency Lock The authoritative rule is defined in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) at line 217, which states that you must **pick ONE corner‑radius scale for the page and stick to it**, choosing from **all‑sharp** (radius 0), **all‑soft** (radius 12–16 px), or **all‑pill** (full radius for interactive). Mixed systems are allowed only when there is a documented rule—such as *“buttons are full‑pill, cards are 16 px, inputs are 8 px”*—and that rule is followed everywhere. Round buttons in a square layout, or square cards on a pill‑button page, is considered broken design. The same lock is repeated at line 1745, where it is framed as a pre‑flight check. This means every page built under the taste-skill system must commit to a single radius language unless a written mapping is defined and applied globally. ## The Three Corner‑Radius Scales The taste-skill specification recognizes exactly three radii categories. You must choose one as the page default. ### All‑Sharp (0 px) **All‑sharp** removes rounding entirely. Every container, button, and input uses a `0px` radius, creating a brutalist, editorial aesthetic. - **Token value:** `0px` - **Tailwind utility:** `rounded-none` ### All‑Soft (12–16 px) **All‑soft** applies a moderate radius, typically in the `12–16 px` range. This is the most common default for modern SaaS interfaces and is usually implemented as `14px`. - **Token value:** `14px` - **Tailwind utility:** `rounded-[var(--radius-base)]` ### All‑Pill (Full Radius) **All‑pill** uses full rounding, usually expressed as `9999px` or Tailwind’s `rounded-full`. This scale is reserved for highly tactile, button-heavy interfaces. - **Token value:** `9999px` - **Tailwind utility:** `rounded-full` ## Why Shape Consistency Matters The taste-skill system emphasizes four primary benefits of locking a page to one scale: - **Visual cohesion** — Uniform radii create a clean, intentional aesthetic and avoid the “template” feel that results from mixing sharp cards with pill‑shaped buttons. - **Accessibility & affordance** — Consistent rounding signals interaction intent; pill‑shaped elements are immediately perceived as clickable. - **Maintainability** — Designers and developers audit a page for a single token such as `--radius-base` rather than hunting down disparate values across dozens of components. - **Automation** — The lock can be encoded in a Tailwind configuration or a design‑token file, making linting and CI checks straightforward. ## Implementing the Corner‑Radius System in taste-skill The `taste-skill` specification expects teams to adopt the lock through a token-based workflow. The standard implementation follows four steps: 1. **Choose a radius token** in your [`tailwind.config.js`](https://github.com/Leonxlnx/taste-skill/blob/main/tailwind.config.js) or CSS variables. 2. **Apply it globally** via a utility class such as `rounded-[var(--radius-base)]` or a component-level base style. 3. **Document any exceptions** in the page’s design spec. The rule permits a written mapping such as “buttons = full‑pill, cards = 16 px”. 4. **Audit** the rendered markup to confirm all elements respect the chosen token. ### Configuring the Tailwind Token Define the chosen scale in [`tailwind.config.js`](https://github.com/Leonxlnx/taste-skill/blob/main/tailwind.config.js) at the project root: ```javascript // tailwind.config.js module.exports = { theme: { extend: { borderRadius: { // Choose ONE of the three scales for the whole page // all-sharp: '0px', // all-soft: '14px', // ≈ 12-16 px range // all-pill: '9999px', // fully rounded base: '14px', // <-- selected radius for this page }, }, }, }; ``` This creates a single source of truth for the page’s radius. An **all‑sharp** page would set `base: '0px'`, while an **all‑pill** page would set `base: '9999px'`. ### Applying Tokens to Components Use the token for standard surfaces, and reserve explicit exceptions only for documented component roles: ```tsx // components/Card.tsx export function Card({ children }: { children: React.ReactNode }) { return (
{children}
); } // components/Button.tsx /* shape-exception: button-pill */ export function Button({ label }: { label: string }) { return ( ); } ``` In the example above, `Card` inherits the page’s base radius (`14px`), while `Button` follows a documented exception mapped to the **all‑pill** scale. According to the taste-skill specification, this mixing is valid only because the exception is explicit, written, and consistently applied. ### Linting and CI Enforcement To prevent accidental drift, audit rendered markup or add a custom lint rule that flags deviations: ```bash # Using ESLint with a custom rule to forbid mixed radii npm exec eslint . --rule 'no-mixed-radius: error' ``` Any component that deviates from the defined `--radius-base` without an explicit comment such as `/* shape-exception: button-pill */` should cause the linter to fail, surfacing violations early in CI. ## Summary - The **Shape Consistency Lock** is mandatory in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) (lines 217 and 1745). - Every page must choose exactly one scale: **all‑sharp** (`0px`), **all‑soft** (`12–16px`), or **all‑pill** (`9999px`). - Mixed systems are permitted only under a **documented exception rule** that is applied everywhere. - Implement the lock via a single design token such as `--radius-base` in [`tailwind.config.js`](https://github.com/Leonxlnx/taste-skill/blob/main/tailwind.config.js). - Audit components and enforce the rule through linting to maintain taste-skill’s anti‑slop design standard. ## Frequently Asked Questions ### What is the Shape Consistency Lock in taste-skill? It is a mandatory design rule defined in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) that requires every page to commit to exactly one corner‑radius scale. The rule is stated at line 217 and repeated at line 1745 as a pre‑flight check. ### Can I mix different corner radii on the same page? Only if you establish and follow a documented exception rule everywhere. The specification allows mappings such as “buttons are full‑pill, cards are `16px`, inputs are `8px`,” but arbitrary mixing—like round buttons inside square cards—is explicitly considered broken design. ### What are the exact corner‑radius values defined by taste-skill? The system defines three options. **All‑sharp** uses `0px`. **All‑soft** uses a range of `12–16px`, commonly implemented as `14px`. **All‑pill** uses full rounding, typically `9999px` or Tailwind’s `rounded-full`. ### How do I enforce shape consistency in a taste-skill codebase? Define a single token such as `--radius-base` in [`tailwind.config.js`](https://github.com/Leonxlnx/taste-skill/blob/main/tailwind.config.js), apply it globally through utility classes, and audit markup for stray `rounded-*` values. You can also add linter rules that reject deviations unless the component includes an explicit `/* shape-exception */` comment.