Module Redesign Pipeline — Security skill for Claude Code

module-redesign-pipeline

A reusable Claude Code **skill** that turns "this module looks generic / dated / not top 1%" into a shipped, live-verified redesign of an **existing** screen or section — grounded in the module's real code, benchmarked against real reference products where no internal precedent exists, gated by a scored audit and real performance traces, and never accepted on a claim alone.

Redesigns an EXISTING surface end-to-end, through build and ship. Not a new-feature-scoping skill — see [feature-design-pipeline](https://github.com/eazyapp-tech/feature-design-pipeline) for that.

Every phase, gate, and standing rule in this skill is mined from **66+ real redesign sessions** (Reviews, Food/FoodV2, Tasks, Change Room on RentOk's manager webapp) — not a theoretical process. It's the tool sequence, the operator discipline, and the design principles that actually made each of those land, made reusable.

What it does

Runs an ordered, looping pipeline: **frame → ground the codebase → reference (conditional) → check the house design language → scored audit → propose & lock (rendered artifact) → plan → build → motion pass → live verify + instrument → final gate (acceptance round) → ship.** Phases 3–8 repeat as rounds driven by the user's real feedback — real modules took 2–8 rounds. It orchestrates other skills (`impeccable`, `interface-design`, `emil-design-eng`, `playwright`, `web-design-guidelines`, `code-review`) rather than replacing them, and adds the connective tissue those don't cover on their own: the per-module memory ledger, the pre-code design lock, the instrumented verification gate, and a named human merge owner.

Five ideas do the heavy lifting:

1. Ground before you touch pixels — map the real module first; only reach outside (Mobbin, for real reference screens from best-in-class apps) when there's genuinely no internal precedent.
2. The user is the real final gate, not the skills — verbatim rejections get logged and carried forw