Polish fix

Personal agent skills for Paper-first UI prototyping and design engineering.

Install

npx -y skills add olzn/skills --skill polish-fix

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Land one small UI papercut as a tiny, easy-to-approve PR, the low-ceremony path for fixes too small to warrant a full session. Use when the user spots a minor visual or interaction nit (spacing, alignment, colour, hover, copy, a slightly-off radius) and wants it fixed and shipped without ceremony, or says "quick fix", "polish this", "tiny PR for X". Makes the minimal change, captures a before/after, and opens a small PR. Does NOT do feature work, refactors, or anything that needs review discussion; escalate those to a normal session.

SKILL.md

2.3 KB, as published. Nobody here has run it

Polish Fix

A polish fix is one tiny, obvious UI improvement shipped with as little ceremony as possible. The whole value is volume without overhead: dozens of small craft fixes that would never each justify a dedicated session.

Keep each one genuinely small. If it grows past a few lines or needs a design decision, it isn't a polish fix; stop and treat it as real work.

Workflow

Pin the papercut. State the single concrete change in one sentence ("tighten the gap between the avatar and name", "fix the sticky hover on the nav links"). One papercut per fix.
Make the minimal change. Touch the fewest lines that resolve it. Match the surrounding code and tokens: no new abstractions, no drive-by edits, no scope creep into nearby nits (those are separate polish fixes).
Capture before/after. Use the before-and-after skill to screenshot the element or page in both states, so the PR is reviewable at a glance without anyone running it.
Open a small PR. Branch, commit (end the message with the project's Co-Authored-By line if one is configured), and open a PR whose body is just the one-line description plus the before/after images. Title it so a reviewer can approve on sight.

Keep it cheap

One papercut per PR. Don't batch unrelated fixes; small, single-purpose PRs are the thing that makes them approvable on sight. (If a pile accumulates, the user can ask to squash them later.)
No tests, no refactors, no behaviour change beyond the visual/interaction nit.
Respect the project's checks. Run whatever build/lint the repo defines before pushing; a polish fix that breaks CI defeats the purpose.
Escalate honestly. The moment a "quick fix" reveals a real problem, say so and stop; don't quietly expand the PR.