ce-polish — Claude Code skill: polish UI with live browser feedback
Refines a working feature through browser feedback: you point out what needs work, the skill edits the code, hot reload shows the result.
npx skills add EveryInc/compound-engineering-plugin --skill ce-polish -a claude-codeWhat ce-polish does
The skill starts a dev server, opens the page, and waits for your observations. Two modes: traditional — you type what to fix; live — you talk and draw on the page, a voice interviewer turns your speech into tasks, the agent fixes them in code, you see changes immediately. Live mode requires an OpenAI key in the environment and adds the riffrec dependency as a setup commit on the current branch.
All fixes are saved as local commits. It never pushes, never opens a PR, and never touches the default branch — that's a safety boundary. When you say you're done, the skill invokes ce-commit to save the changes and reports the still-running server URL.
What it helps with
- polish a feature before shipping without manual commit workflow
- collect feedback by voice and drawing directly on the page
- fix UX details and see the result through hot reload instantly
- refine a form or widget before merging
- turn live observations into code edits
Example prompts for the agent
- Start live polish session for the checkout page on current branch
- I need to refine the signup form, open it in the browser and wait for my feedback
- Polish the dashboard in branch feature/new-layout
How to install ce-polish
1Skills CLI (Vercel)
npx skills add EveryInc/compound-engineering-plugin --skill ce-polish -a claude-code2Manually: put the files in place
~/.claude/skills/ce-polish/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/ce-polish/
1Skills CLI (Vercel)
npx skills add EveryInc/compound-engineering-plugin --skill ce-polish -a codex2Manually: put the files in place
.agents/skills/ce-polish/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add EveryInc/compound-engineering-plugin --skill ce-polish -a cursor2Manually: put the files in place
.cursor/skills/ce-polish/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install EveryInc/compound-engineering-plugin ce-polish2Manually: put the files in place
.github/skills/ce-polish/SKILL.md1Skills CLI (Vercel)
npx skills add EveryInc/compound-engineering-plugin --skill ce-polish -a gemini-cli2Platform CLI
gemini skills install https://github.com/EveryInc/compound-engineering-plugin --path skills/ce-polishManually: put the files in place
.devin/skills/ce-polish/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add EveryInc/compound-engineering-plugin --skill ce-polish -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set21
The whole set →Similar
Questions about ce-polish
How to install ce-polish in Claude Code?
Run npx skills add EveryInc/compound-engineering-plugin --skill ce-polish -a claude-code, the skill will land in ~/.claude/skills/ce-polish/SKILL.md.
What does ce-polish do?
It starts a dev server with the working feature, collects your feedback in the browser (typed or spoken with drawing on the page), edits the code to match your observations, and saves changes as local commits. It never pushes and never touches the default branch.
Why does ce-polish need an OpenAI key?
The key is required for live mode: a voice interviewer listens to your speech, sees what you draw and click, and turns that into tasks for the agent. Traditional mode does not require the key.
Source text
SKILL.md · MIT
--- name: ce-polish description: "Polish a working feature through user-directed live browser feedback. Use when a functional feature needs focused UX refinement before shipping." disable-model-invocation: true argument-hint: "[PR number, branch name, or blank for current branch]" --- # Polish Put a working feature in front of the user and turn their live observations into focused UX fixes on the running page. Two ways to collect those observations: **traditional**, where the user types what could be better; and **live**, where they talk and draw on the page while a voice interviewer turns speech into units and you act on them at checkpoints. **Done:** the user ends the polish loop, every requested fix is reflected in the live feature or reported as blocked, and the in-scope changes are saved in local commit(s). A live session also ends with a residual list of the units that were not applied and the path of its session log. A server or checkout blocker also ends the run when it is reported with the evidence needed to resume. **Boundaries:** the user drives what to inspect and change; do not invent an autonomous checklist or expand into general QA. Never work on the repository's default branch. This workflow may edit and locally commit the requested polish, and in live mode the disclosed riffrec setup commit, but it never pushes or opens a PR. ## Run 1. **Ask live or traditional.** Ask once, before any server starts. Include this disclosure with the question: live mode needs an OpenAI key in the environment, runs a voice interviewer in the page that hears the user, is told what they click and draw on, and looks at their screen when they point at something or ask it to, streams the session to a local endpoint this skill runs, and, when riffrec is not yet in the app, adds the riffrec dependency and a provider mount as a setup commit on the current branch that stays after the session. Traditional continues with steps 2–5 unchanged. Live: read `references/live-start.md`; it owns preconditions, install, the endpoint, and the URL handoff, applies the workspace and server rules of `references/run.md` itself, then routes to `references/live-loop.md` for the session and its close. Steps 2–5 do not run for a live session. 2. **Get the live page ready.** Read `references/run.md` before resolving the requested ref or starting anything. It owns existing-worktree safety, dev-server discovery, the bundled-script calls, reachability, and the browser handoff. 3. **Wait for observations.** Tell the user where the server is running and ask what could be better. Do not start a review pass while they browse. 4. **Iterate.** For each requested change, inspect only as needed, edit the in-scope surface, and let hot reload update the page. When the user asks you to inspect the result, use a browser capability available in the active harness; if none exists, ask them to describe what they see. 5. **Close locally.** When the user says they are done, invoke `ce-commit` for the polish changes, then report the commit(s), the still-running server URL, and any residual blocker.
© EveryInc · MIT · EveryInc/compound-engineering-plugin