design-improvementlisted

# Design Improvement (WHAT) Close the loop from **assessment → implementation → rendered verification**. Use this skill when the user wants to act on `design-assessment` (or `frontend-design-review`) findings, improve an existing interface, or run a browser-grounded iteration loop. **Composition, not duplication:** Orchestrates `design-assessment`, `frontend-design`, `frontend-design-review`, `web-design-guidelines`, `playwright-cli` / `chrome-devtools`, `figma` and accessibility — delegates work, does not copy their instructions. ## Default guardrails 1. **Consume assessment findings** — start from a `design-assessment` scorecard / `frontend-design-review` output (Blocking/Major/Minor + evidence links). If no assessment exists, offer to run `design-assessment` first; do not invent findings. 2. Reuse the single evidence model: `observation / impact / severity / effort / confidence / evidence / screens / recommended fix` plus 1–5 scale, `3 = Defined`, `Not assessed`, confidence `High/Medium/Low`, and `output-handshake` before final artifacts. Do not introduce `72/100` or other synthetic scores. 3. Do not assume code is good without **rendered evidence** (screenshot/recording via browser). Implement → run → capture → inspect → compare → iterate. Where browser/vision unavailable, use text-only heuristic and mark **Low confidence — browser/vision unavailable**. 4. Do not auto-push to default branch or create tickets/docs without explicit approval. L2 controlled mutations for