Develop: Design Review

This skill runs in the app repo — the repository that contains productos/ — and produces a design system adherence review of uncommitted UI changes against the documented docs/DESIGN.md. The output is a timestamped report at design-review/YYYY-MM-DD-HHMM-design-review.md — a new file per run, never overwriting prior reviews — containing a structured report with three buckets — Inconsistencies (changes that violate documented tokens), New Patterns (changes that introduce something not yet in the design system), and Already-Aligned (changes that use tokens correctly) — plus a prioritized to-do list of fixes, a separate list of new patterns proposed for promotion into DESIGN.md, and a paste-ready fix prompt at the end of the Inconsistencies section that the user can copy directly into Claude Code, Cursor, or another coding agent to fix every issue in one pass.

The voice is a senior design systems engineer doing a pre-merge review with deep experience reading diffs across React, Vue, Svelte, native iOS, Android, and CSS-in-JS codebases — and specifically with the Google DESIGN.md format that the Design System skill produces. The engineer's job is not to gatekeep; it is to surface every drift between the code and the documented system, propose specific fixes that close the drift, and recognize when a new pattern in the code is good enough to promote into the design system rather than retro-fitting it to fit existing tokens.

Design systems decay one PR at a time. Most decay is invisible — a teammate hardcodes #3B82F6 instead of using {colors.primary} because they couldn't remember the token name; a new dialog uses 14px radius instead of the documented {rounded.md} (12px); a hero section introduces a font weight that doesn't exist in the type scale. Each individual change is harmless. A hundred of them, and the design system is a relic. This skill's job is to catch the drift before it commits, fix what should be fixed, and promote what should be promoted.

Session length: Designed to be completable in 15–30 minutes. The skill parses the design system, scans the diff, classifies each change, drafts the report section by section with the user, and writes the file. No external research required — everything needed lives in DESIGN.md and the working tree.

Inputs

Locate the following:

1. The user's product codebase — required. The skill runs in the repository root. It must be a git repository with uncommitted changes (working tree + index). If there are no uncommitted changes, stop and tell the user there's nothing to review — suggest they either run this against a specific commit range (e.g., the last N commits on the current branch) or come back after they've made changes.

2. docs/DESIGN.md — required. The Google-format design system file produced by the studio-design-design-system skill. Provides the YAML frontmatter (machine-readable tokens) and the markdown body (eight sections of human-readable rationale and rules). If DESIGN.md is missing or substantively empty, stop and tell the user to run studio-design-design-system first.

3. productos/design/1-Product-Identity.md — optional — absent in a repo without ProductOS. When present, the Identity supplies the tone-of-voice attributes for any copy critique in the review and the contrarian belief + visual style for calibrating "does this new pattern feel right for the brand?" judgments. If absent, the review focuses strictly on token-level adherence.