/ce-polish
Start the dev server, inspect the feature in browser, and iterate on polish.
$ npx -y skills add everyinc/compound-engineering-plugin --skill ce-polish --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/ce-polish
Context preview
The summary Claude sees to decide when to auto-load this skill.
Start the dev server, inspect the feature in browser, and iterate on polish.
SKILL.md
ce-polish.SKILL.mdname: ce-polish
description: "Start the dev server, inspect the feature in browser, and iterate on polish."
disable-model-invocation: true
argument-hint: "[PR number, branch name, or blank for current branch]"
Polish
Start the dev server, open the feature in a browser, and iterate. You use the feature, say what feels off, and fixes happen.
Phase 0: Get on the right branch
1. If a PR number or branch name was provided, check it out (probe for existing worktrees first). 2. If blank, use the current branch. 3. Verify the current branch is not main/master.
Phase 1: Start the dev server
The scripts below ship in this skill's `scripts/` directory. The Bash tool's working directory is the user's project, not the skill directory, so a bare `scripts/<name>` path will not resolve — invoke each by the skill's own absolute path. Every runnable block below sets `SKILL_DIR` inline (shell state does not persist between Bash tool calls, so each command must carry it); replace the `<absolute path …>` placeholder with the directory you loaded this `ce-polish` SKILL.md from before running.
1.1 Check for `.claude/launch.json`
SKILL_DIR="<absolute path of the directory containing this SKILL.md>";
bash "$SKILL_DIR/scripts/read-launch-json.sh"
If it finds a configuration, use it — the user already told us how to start the project.
1.2 Auto-detect (when no launch.json)
Identify the framework:
SKILL_DIR="<absolute path of the directory containing this SKILL.md>";
bash "$SKILL_DIR/scripts/detect-project-type.sh"
Route by type to the matching recipe reference for start command and port defaults:
| Type | Recipe | |------|--------| | `rails` | `references/dev-server-rails.md` | | `next` | `references/dev-server-next.md` | | `vite` | `references/dev-server-vite.md` | | `nuxt` | `references/dev-server-nuxt.md` | | `astro` | `references/dev-server-astro.md` | | `remix` | `references/dev-server-remix.md` | | `sveltekit` | `references/dev-server-sveltekit.md` | | `procfile` | `references/dev-server-procfile.md` | | `unknown` | Ask the user how to start the project |
For framework types that need a package manager, run the resolver and substitute the result into the start command:
SKILL_DIR="<absolute path of the directory containing this SKILL.md>";
bash "$SKILL_DIR/scripts/resolve-package-manager.sh"
Resolve the port:
SKILL_DIR="<absolute path of the directory containing this SKILL.md>";
bash "$SKILL_DIR/scripts/resolve-port.sh" --type <type>
1.3 Start the server
Start the dev server in the background, log output to a temp file. Probe `http://localhost:<port>` for up to 30 seconds. If it doesn't come up, show the last 20 lines of the log and ask the user what to do.
1.4 Open in browser
Load `references/ide-detection.md` for the env-var probe table. Open the browser using the IDE's mechanism (Claude Code → `open`, Cursor → Cursor browser, VS Code → Simple Browser).
Tell the user:
Dev server running on http://localhost:<port>
Browse the feature and tell me what could be better.
Phase 2: Iterate
This is the core loop. The user browses the feature and tells you what to improve. You fix it. Repeat until they're happy.
- When the user describes something to fix → make the change, the dev server hot-reloads
- When the user asks to check something → use a browser-automation capability to screenshot or inspect the page; prefer `agent-browser` if it's installed, otherwise use whatever the host exposes
- When the user says they're done → commit the fixes and stop
No checklist. No envelope. Just conversation.
References
Reference files (loaded on demand):
- `references/launch-json-schema.md` — launch.json schema + per-framework stubs
- `references/ide-detection.md` — host IDE detection and browser-handoff
- `references/dev-server-detection.md` — port resolution documentation
- `references/dev-server-rails.md` — Rails dev-server defaults
- `references/dev-server-next.md` — Next.js dev-server defaults
- `references/dev-server-vite.md` — Vite dev-server defaults
- `references/dev-server-nuxt.md` — Nuxt dev-server defaults
- `references/dev-server-astro.md` — Astro dev-server defaults
- `references/dev-server-remix.md` — Remix dev-server defaults
- `references/dev-server-sveltekit.md` — SvelteKit dev-server defaults
- `references/dev-server-procfile.md` — Procfile-based dev-server defaults
Scripts (invoked via `bash "$SKILL_DIR/scripts/<name>"` — see Phase 1 for `SKILL_DIR`):
- `scripts/read-launch-json.sh` — launch.json reader
- `scripts/detect-project-type.sh` — project-type classifier
- `scripts/resolve-package-manager.sh` — lockfile-based package-manager resolver
- `scripts/resolve-port.sh` — port resolution cascade
Read more
name: ce-polish description: "Start the dev server, inspect the feature in browser, and iterate on polish." disable-model-invocation: true argument-hint: "[PR number, branch name, or blank for current branch]"
Polish
Start the dev server, open the feature in a browser, and iterate. You use the feature, say what feels off, and fixes happen.
Phase 0: Get on the right branch
1. If a PR number or branch name was provided, check it out (probe for existing worktrees first). 2. If blank, use the current branch. 3. Verify the current branch is not main/master.
Phase 1: Start the dev server
The scripts below ship in this skill's `scripts/` directory. The Bash tool's working directory is the user's project, not the skill directory, so a bare `scripts/<name>` path will not resolve — invoke each by the skill's own absolute path. Every runnable block below sets `SKILL_DIR` inline (shell state does not persist between Bash tool calls, so each command must carry it); replace the `<absolute path …>` placeholder with the directory you loaded this `ce-polish` SKILL.md from before running.
1.1 Check for `.claude/launch.json`
SKILL_DIR="<absolute path of the directory containing this SKILL.md>"; bash "$SKILL_DIR/scripts/read-launch-json.sh"
If it finds a configuration, use it — the user already told us how to start the project.
1.2 Auto-detect (when no launch.json)
Identify the framework:
SKILL_DIR="<absolute path of the directory containing this SKILL.md>"; bash "$SKILL_DIR/scripts/detect-project-type.sh"
Route by type to the matching recipe reference for start command and port defaults:
| Type | Recipe | |------|--------| | `rails` | `references/dev-server-rails.md` | | `next` | `references/dev-server-next.md` | | `vite` | `references/dev-server-vite.md` | | `nuxt` | `references/dev-server-nuxt.md` | | `astro` | `references/dev-server-astro.md` | | `remix` | `references/dev-server-remix.md` | | `sveltekit` | `references/dev-server-sveltekit.md` | | `procfile` | `references/dev-server-procfile.md` | | `unknown` | Ask the user how to start the project |
For framework types that need a package manager, run the resolver and substitute the result into the start command:
SKILL_DIR="<absolute path of the directory containing this SKILL.md>"; bash "$SKILL_DIR/scripts/resolve-package-manager.sh"
Resolve the port:
SKILL_DIR="<absolute path of the directory containing this SKILL.md>"; bash "$SKILL_DIR/scripts/resolve-port.sh" --type <type>
1.3 Start the server
Start the dev server in the background, log output to a temp file. Probe `http://localhost:<port>` for up to 30 seconds. If it doesn't come up, show the last 20 lines of the log and ask the user what to do.
1.4 Open in browser
Load `references/ide-detection.md` for the env-var probe table. Open the browser using the IDE's mechanism (Claude Code → `open`, Cursor → Cursor browser, VS Code → Simple Browser).
Tell the user:
Dev server running on http://localhost:<port> Browse the feature and tell me what could be better.
Phase 2: Iterate
This is the core loop. The user browses the feature and tells you what to improve. You fix it. Repeat until they're happy.
- When the user describes something to fix → make the change, the dev server hot-reloads
- When the user asks to check something → use a browser-automation capability to screenshot or inspect the page; prefer `agent-browser` if it's installed, otherwise use whatever the host exposes
- When the user says they're done → commit the fixes and stop
No checklist. No envelope. Just conversation.
References
Reference files (loaded on demand):
- `references/launch-json-schema.md` — launch.json schema + per-framework stubs
- `references/ide-detection.md` — host IDE detection and browser-handoff
- `references/dev-server-detection.md` — port resolution documentation
- `references/dev-server-rails.md` — Rails dev-server defaults
- `references/dev-server-next.md` — Next.js dev-server defaults
- `references/dev-server-vite.md` — Vite dev-server defaults
- `references/dev-server-nuxt.md` — Nuxt dev-server defaults
- `references/dev-server-astro.md` — Astro dev-server defaults
- `references/dev-server-remix.md` — Remix dev-server defaults
- `references/dev-server-sveltekit.md` — SvelteKit dev-server defaults
- `references/dev-server-procfile.md` — Procfile-based dev-server defaults
Scripts (invoked via `bash "$SKILL_DIR/scripts/<name>"` — see Phase 1 for `SKILL_DIR`):
- `scripts/read-launch-json.sh` — launch.json reader
- `scripts/detect-project-type.sh` — project-type classifier
- `scripts/resolve-package-manager.sh` — lockfile-based package-manager resolver
- `scripts/resolve-port.sh` — port resolution cascade
AI skills that make each unit of engineering work easier than the last.
Repo: everyinc/compound-engineering-plugin
Other skills on compound-engineering.
- /ce-babysit-pr
Babysits or watches an open GitHub PR until merge-ready, continuously reacting to review comments, CI failures, and routine base movement throughout the PR's life. Use when asked to 'babysit the PR', 'watch the PR', monitor, or keep an eye on a PR over time — not a one-shot
Open skill - /ce-brainstorm
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm, think through scope, decide what to build, or needs collaborative product framing before planning. Also use when the user must scope work in territory they
Open skill - /ce-code-review
Structured code review for bugs, regressions, tests, and standards. Use before PRs or when asked for review; report-only by default, with explicit local apply available for user-directed fix workflows.
Open skill - /ce-commit-push-pr
Commit, push, and open a PR. Use when asked to ship/open a PR, or for PR-description-only flows like writing, rewriting, or describing a PR body.
Open skill - /ce-commit
Create a git commit with a clear, value-communicating message. Use when the user asks to commit/save staged or unstaged changes with a repo-appropriate message.
Open skill - /ce-compound-refresh
Refresh the repo's captured learnings against the current codebase. Use when auditing stale, overlapping, superseded, or drifted learnings; avoid general refactor, debugging, or code review unless the learnings store is explicit.
Open skill

