Fix an existing dashboard without breaking it

State what must change and what must not, take a baseline, get an approved changeset, apply it one item at a time, and end on a verdict that names anything that moved.

A request to fix something that already exists is the opposite of a design request, and the lifecycle skills answer it badly: the dashboard gets one thing fixed and three things redesigned. cupertino-repair is the one route that treats the existing system as the design system, and makes "do not break it" a list of checks rather than a hope.

Start here

One prompt to start

The KPI tiles on our dashboard overflow sideways on a phone -- fix that and remove the dead chart file, but do not change how it looks on desktop or in dark mode, and do not touch anything the change does not need.

Needscupertino, andon

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

1. cupertino:cupertino-repair

   Owns the whole job. It asks for the objective and what must be preserved before it edits, baselines every check, and a hook then limits each edit to the one approved item. Starting from a design skill instead redesigns what you only wanted fixed.

   Run this beat on its own

   the KPI tiles overflow sideways on my phone -- fix the dashboard, but don't change how it looks on desktop or in dark mode

2. andon:andon-verifyalso in 15 other recipes

   • Audit supply-chain pinning and dependencies
   • Finish and integrate a development branch
   • Investigate a job that reports success but changed nothing
   • Investigate a fix that did not stick
   • Investigate tests that pass while the code is broken
   • Root-cause a bugfix from a tracked issue
   • Build a new feature in an existing codebase
   • Collapse duplication hand-synced across N sites
   • Execute a written plan across parallel workstreams
   • Migrate a return shape or type representation
   • Propagate a vendored artifact to N copies
   • Audit your own agent and skill definitions for loop-reliability defects
   • Rework a plugin to the official Anthropic standard
   • Do oracle engineering and numerical V&V
   • Whole-branch review without re-trusting the branch's own self-assessment

   Optional second opinion on one claim the verdict makes, for example that a deleted file is unreferenced. It reads the repair's evidence and writes nothing to the ledger.

   Run this beat on its own

   prove that nothing in dashboard/ still loads legacy-chart.js

Worked example

Grounded in — why this beat order is trustworthy

`plugins/cupertino/scripts/fixtures/repair-demo.json` is the committed run behind `plugins/cupertino/assets/repair-viewer-screenshot.jpg`: both acceptance checks pass, yet the verdict is `regressed` because the chart bars went black in light mode and `chart.js` changed outside any approved item.

Do / Don't

• ✓Say what must stay the same as well as what must change; each `mustPreserve` entry becomes a check that is re-run after the edit.
• ✓Read the changeset before approving it. Approval is bound to its hash, and editing it afterwards voids the approval.
• ✓Delete through the repair route only. It refuses while anything still references the file and keeps a copy that can be restored.

• ×Don't start from `cupertino-council` or `cupertino-review` -- they design something new and will redesign the page.
• ×Don't run another plugin's fix in the same session mid-run; cupertino's guard scopes every edit to the active item and will deny it.
• ×Don't treat a verdict with a check that could not run as done; it is reported as not run, never as a pass.