Code Polish
Run a single pipeline that simplifies recent code then reviews and auto-fixes issues on a git-scoped changeset.
Overview
code-polish is an agent skill most often used in Ship (also Build backend and frontend) that runs code-simplify then code-review --fix on a git-resolved scope in one report.
Install
npx skills add https://github.com/paulrberg/agent-skills --skill code-polishWhat is this skill?
- Two-step pipeline: code-simplify then code-review --fix with fixes applied automatically
- Git-backed scope: session-modified files first, else uncommitted tracked and untracked lists
- Stops if not inside a git repository (git rev-parse --git-dir)
- Accepts explicit paths, commit ranges, or Resolved scope fenced blocks
- One combined user-facing report without redundant simplify verification
- 2-step pipeline: code-simplify then code-review --fix
Adoption & trust: 1.6k installs on skills.sh; 62 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your latest diff is readable enough to ship but you want simplification and a fixing review without running two separate agent rituals.
Who is it for?
Indie devs finishing a feature branch or session who already use paulrberg code-simplify and code-review skills in the same repo.
Skip if: Work outside a git repo, greenfield generation with no changed files, or review-only audits without applying fixes.
When should I use this skill?
User asks to polish code, simplify and review, clean up and review code, full code polish, simplify then review, refactor and review, simplify and fix, or clean up and fix on recently changed code.
What do I get? / Deliverables
Scoped files are simplified for maintainability, reviewed with fixes auto-applied, and summarized in one polish report.
- Simplified source on scoped files
- Review fixes applied via code-review --fix
- Single combined polish report
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Polish combines simplification and review right before merge or release, which maps to Ship → review as the primary home. It orchestrates code-simplify and code-review --fix on targeted files—not greenfield feature build or infra deploy.
Where it fits
Run polish on session edits right before you push and open a PR.
After tests pass, simplify and fix review findings on the same file list.
Clean up API handler changes you made in the current agent session.
Tighten a hotfix branch with simplify plus auto-fixed review on explicit paths.
How it compares
Orchestrated simplify-then-fix review—lighter than ad-hoc chat refactors, narrower than a full security audit skill.
Common Questions / FAQ
Who is code-polish for?
Solo builders using paulrberg agent-skills who want an orchestrated polish pass on git-scoped changes before merge or deploy.
When should I use code-polish?
In Ship before opening or merging a PR, or late in Build after a coding session when you say polish code, simplify and review, or clean up and fix.
Is code-polish safe to install?
It auto-applies review fixes and runs git commands; review the Security Audits panel on this Prism page and inspect the diff before committing.
Workflow Chain
Requires first: code simplify, code review
SKILL.md
READMESKILL.md - Code Polish
# Code Polish Combined simplification and review pipeline. This skill orchestrates two sub-skills in sequence: 1. **`code-simplify`** — simplify for readability and maintainability 2. **`code-review --fix`** — review for correctness, security, and quality, auto-applying all fixes Optimize for one scope resolution, one user-facing report, and no redundant simplify verification. ## Scope Resolution 1. Verify repository context: `git rev-parse --git-dir`. If this fails, stop and tell the user to run from a git repository. 2. If user provides file paths/patterns, a commit/range, or a `Resolved scope` fenced block with one repo-relative path per line, scope is exactly those targets. 3. Otherwise, scope is **only** session-modified files. Do not include other uncommitted changes. 4. If there are no session-modified files, fall back to all uncommitted tracked + untracked files: - tracked: `git diff --name-only --diff-filter=ACMR` - untracked: `git ls-files --others --exclude-standard` - combine both lists and de-duplicate. 5. Exclude generated/low-signal files unless requested: lockfiles, minified bundles, build outputs, vendored code. 6. If scope still resolves to zero files, report and stop. 7. Normalize the final scope into a `Resolved scope` fenced block with one repo-relative path per line. Reuse that exact block for both sub-skills instead of asking them to rediscover scope. ## Workflow ### 1) Resolve scope once - Apply the "Scope Resolution" rules above. - Treat the resulting `Resolved scope` block as authoritative for all downstream work. - Forward user intent, constraints, and risk preferences, but skip raw scope selectors already captured in the resolved block. ### 2) Run `code-simplify` Invoke the `code-simplify` skill with: - the authoritative `Resolved scope` block - `--no-verify` - `--no-report` - any non-scope user intent that still matters Tell `code-simplify` not to broaden or rediscover scope. ### 3) Run `code-review --fix` Invoke the `code-review` skill with: - the same authoritative `Resolved scope` block - `--fix` - any non-scope user intent that still matters If the user explicitly asks for a speed-first pass over maintainability coverage, you may also append `--skip-profile naming`. Do not skip the naming profile by default. ### 4) Final verification - Treat `code-review`'s post-fix verification as the final verification summary when it already covers the final touched scope. - If verification was skipped, partial, or no longer matches the final diff, run one narrow final verification pass across the final touched scope. - Always report skipped checks explicitly. ### 5) Report Combine the final state into one summary: 1. **Scope**: Files and functions touched. 2. **Simplifications**: Key changes from `code-simplify`, derived from the actual diff when needed because `--no-report` was used. 3. **Review findings and fixes**: Findings and applied fixes from `code-review`. 4. **Verification**: Commands run and outcomes. 5. **Residual risks**: Assumptions or items needing manual review.