# Negotiating Visual Changes

> Use when about to redesign or restyle a UI surface the user has already seen, or when one pass bundles two or more separable visual changes.

- Skill: `presidenteog/negotiating-visual-changes` (Agent Skill)
- Install (CLI): `npx skillmds@latest add presidenteog/negotiating-visual-changes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/presidenteog/negotiating-visual-changes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: PresidenteOG (https://skillmd.com/u/presidenteog)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/presidenteog/negotiating-visual-changes

---


# Negotiating visual changes

**Prohibition:** never start a full rebuild or restyle of a UI surface the user
has already seen on request phrasing alone, without confirming scope and
appetite first — and never bundle two or more separable visual changes into one
indistinguishable edit. Working code proves the code works, not that the design
is wanted; a surface can be built-and-verified-working and still get discarded
on sight, more than once.

## Rationalization → counter

| What it sounds like | Why it's wrong |
|---|---|
| "The request sounds urgent / already agreed ('like we talked about')" | Urgent, presumptive phrasing describes their state of mind, not confirmed scope. A 15-second scope check costs less than a discarded rebuild. |
| "They just praised the last small fix — this is the natural next step" | A small, reversible fix landing well doesn't transfer to authorization for a much bigger, harder-to-reverse change on the same surface. These are independent signals. |
| "The two changes live in the same function, separating them is extra work" | Code adjacency isn't conceptual separability. Keeping two changes as distinguishable pieces costs a label, not a rewrite. |
| "This surface has been discussed before, no need to re-ask" | Prior discussion doesn't survive the next instruction being read as blanket approval. Confirm current appetite, especially on a surface with a revert history. |
| "Asking feels like friction / slows things down" | The question is one sentence. An unwanted full rebuild is an hour lost, and it still has to be caught and reverted afterward. |

## Red flags — confirm before building, or split before shipping

- A UI surface with a documented rebuild/revert history is getting a new large
  request.
- One request names two or more distinct visual elements or concerns in the
  same breath ("also improve X while you're at it").
- Positive feedback on a small, scoped change is immediately followed by a
  request to scale it up to the whole surface.
- Phrasing that presumes agreement already exists ("like we talked about", "you
  know what I mean", "just redo it").

## Procedure

- **Before a full rebuild/restyle:** name the surface's revert history if any,
  and get an explicit "yes, this one" before building — not a formal spec, one
  confirming sentence.
- **When a request bundles 2+ separable changes:** ship them in the same pass if
  asked, but keep them as separately identifiable edits — separate diff hunks,
  or a clear "change A" / "change B" split — so a later "undo just X" gets
  answered precisely instead of a manual untangle. Doesn't apply to one
  cohesive change with multiple properties of the same element (e.g. a badge's
  color + position together) — only to separable concerns on different elements.