# Shape Consistency Lock for Corner-Radius in Taste Skill: Implementation Guide

> Learn to implement Shape Consistency Lock for corner-radius in Taste Skill. Enforce a unified radius scale and prevent visual inconsistencies in AI designs.

- Repository: [Leon Lin/taste-skill](https://github.com/Leonxlnx/taste-skill)
- Tags: how-to-guide
- Published: 2026-05-30

---

**The Shape Consistency Lock is a mandatory design rule in Taste Skill that enforces a single, page-wide corner-radius scale to prevent mixed-radius visual inconsistencies in AI-generated layouts.**

The **Taste Skill** specification defines strict design standards for UI generation, and the **Shape Consistency Lock** ensures every component adheres to a unified border-radius system. This rule lives within the Materiality subsection of the skill definition and acts as a hard gate in the generation pipeline. By mandating a choice between `all-sharp`, `all-soft`, or `all-pill` radius scales, the system eliminates the "mixed-radius sloppiness" common in automated layout generation.

## What is the Shape Consistency Lock?

The **Shape Consistency Lock** is a mandatory directive that requires selecting exactly one corner-radius scale for an entire page or application. According to the specification in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) at line 217, the rule states:

> **SHAPE CONSISTENCY LOCK (mandatory):** Pick ONE corner‑radius scale for the page and stick to it. Options: `all‑sharp` (radius 0), `all‑soft` (radius 12‑16 px), `all‑pill` (full radius for interactive). Mixed systems are allowed only when a documented rule exists and is followed everywhere.

This rule functions as a **pre-flight check** item that must pass before the generated page is emitted. The parser identifies any rule containing the word "mandatory" and flags it for enforcement during the generation and verification phases.

## Where the Rule is Defined

The primary specification resides in **Section 4.4 (Materiality)** of the main skill file:

- **File:** [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) (line 217)
- **Context:** Materiality subsection governing shadows, cards, and shape properties
- **Classification:** Hard rule marked as "mandatory" rather than advisory

The rule also appears in **Section 14** of [`CHANGELOG.md`](https://github.com/Leonxlnx/taste-skill/blob/main/CHANGELOG.md) (line 32) as part of the **Final Pre-Flight Check** checklist, confirming its role as a gatekeeper in the output pipeline.

## Architectural Implementation

The enforcement of the Shape Consistency Lock spans four architectural layers, from Markdown parsing to post-generation validation.

### Skill Definition Layer

The [`SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/SKILL.md) file serves as the plain-text instruction set. When consumed by the `npx skills add` CLI, the Markdown front-matter and numbered sections are extracted into a structured payload. The **mandatory** designation triggers specific parsing logic that elevates the rule to a blocking check.

### CLI Parser

The parser converts the Markdown into a structured JSON payload for the LLM agent. It tags every rule containing the word **mandatory** as a **pre-flight check** item (see lines 226-231 in [`SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/SKILL.md)). This tagging ensures the Shape Consistency rule becomes a checklist item that must be satisfied before final output.

### LLM Agent Generation

During code generation, the agent receives explicit instructions to **choose a single radius scale** and apply it consistently across all UI primitives including buttons, cards, and inputs. If the prompt includes a documented exception—such as "pill buttons with soft cards"—the agent respects this as an allowed deviation from the single-scale requirement.

### Post-Generation Verifier

A heuristic script scans the generated HTML for `border-radius` values to verify compliance. The verifier checks that only one distinct radius value (or the explicitly defined exception set) appears in the output. If multiple distinct pixel values are detected without documentation, the system emits a **Pre-Flight Fail** error and forces regeneration.

## Practical Implementation Examples

Implement the lock using CSS custom properties to drive a consistent radius system throughout your components.

### Single Scale Implementation

Define the radius once and apply it universally:

```css
/* 1️⃣ Define the radius scale once */
:root {
  --radius: 0;          /* all-sharp */
  /* --radius: 0.75rem; */  /* all-soft (12-16px) */
  /* --radius: 9999px; */   /* all-pill */
}

/* 2️⃣ Apply the variable everywhere */
.button {
  border-radius: var(--radius);
}
.card {
  border-radius: var(--radius);
}
.input {
  border-radius: var(--radius);
}

```

### Documented Exception Pattern

When mixing radius styles intentionally, document the exception with explicit variables:

```css
:root {
  --radius-button: 9999px;   /* pill */
  --radius-card: 0.75rem;    /* soft (12px) */
}

/* Enforce per-component radius */
.button { border-radius: var(--radius-button); }
.card   { border-radius: var(--radius-card); }

```

### Verification Error Example

If the generated HTML contains unapproved radius variations, the verifier flags the issue:

```

❌ Shape Consistency Lock failed: found radii 0px, 4px, 8px.

```

To resolve this, add an explicit exception rule to your prompt or consolidate to a single radius value.

## Integration with Pre-Flight Checks

The Shape Consistency Lock integrates with the broader **Pre-Flight Check** machinery described in [`SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/SKILL.md) (line 256: "Pre-Flight Check is mechanical"). This system aggregates all mandatory rules into a final validation checklist before emission.

The lock specifically influences:

- **Materiality patterns:** The radius choice directly impacts shadow and card implementations (e.g., soft cards require 12-16px radius for visual coherence)
- **Accessibility affordances:** Pill-style controls imply high interaction probability; mixing them with sharp cards without documentation creates ergonomic confusion
- **Theming simplicity:** A single `--radius` variable drives the entire design system, making global updates trivial

## Summary

- The **Shape Consistency Lock** is a mandatory rule defined at line 217 in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) that requires a single, page-wide corner-radius scale.
- Valid options include **all-sharp** (0px), **all-soft** (12-16px), or **all-pill** (9999px/full), with mixed systems permitted only under documented exceptions.
- The rule flows through the **CLI parser**, **LLM agent**, and **post-generation verifier** to ensure enforcement at every stage of the pipeline.
- Use **CSS custom properties** to implement the chosen scale consistently across buttons, cards, and inputs.
- Non-compliance triggers a **Pre-Flight Fail** error, forcing regeneration or explicit exception documentation.

## Frequently Asked Questions

### What happens if I don't document a mixed-radius system?

If the post-generation verifier detects multiple distinct `border-radius` values without a documented exception rule, it emits a **Pre-Flight Fail** error message listing the conflicting values (e.g., "found radii 0px, 4px, 8px") and blocks the output. You must either consolidate to a single scale or add an explicit exception rule to your prompt describing the intentional mixing pattern.

### Can I use different radii for different component types?

Yes, but only when the mixing follows a **documented rule** that is applied consistently everywhere. For example, you may specify "pill buttons (9999px) with soft cards (16px)" in your prompt. Without this documentation, the verifier treats mixed radii as a violation of the mandatory lock.

### Where does the Shape Consistency Lock appear in the project files?

The primary definition is in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) at line 217 within the Materiality subsection. It is also referenced in [`CHANGELOG.md`](https://github.com/Leonxlnx/taste-skill/blob/main/CHANGELOG.md) at line 32 as part of Section 14 (Final Pre-Flight Check), which lists it among the mandatory validation gates that must pass before page emission.

### How does the lock affect the LLM generation process?

During generation, the LLM agent is instructed to select one radius scale and apply it to all UI primitives. The agent treats the "mandatory" designation as a hard constraint, and the post-generation verifier (which scans for `border-radius` values in the output HTML) ensures compliance before the final code is delivered.