agentleFS
PaulRBergPaulRBerg/agent-skills/skills/code-polish/SKILL.md

code-polish

Skill104 starsChanged 19 days agoMITView on GitHub

Resolve scope once. Make only high-confidence simplifications. Fix defects supported by evidence according to their risk. Verify the final state. 1. Require a Git repository. 2. Use explicit paths, patterns, ranges, natural-language targets, or a supplied resolved-scope block when present. Otherwise, use only files modified in this session. If session history is unavailable, use all uncommitted tracked and untracked files. 3. Exclude lockfiles, generated outputs, vendored code, minified bundles, and large data snapshots from manual review unless explicitly requested. Validate…

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 6 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use explicit paths, patterns, ranges, natural-language targets, or a supplied resolved-scope block when present.

    line 24
  2. Distinctive:

    remove real duplication when the abstraction reduces total complexity.

    line 39
  3. Distinctive:

    remove only dead code caused by this session's edits.

    line 41
  4. Distinctive:

    Do not split by line count, perform architecture cleanup, convert sync/async APIs, add speculative configurability, or replace readable …

    line 43
  5. Distinctive:

    Every finding must cite a verified location, triggering input/state, failure mode, blast radius, and evidence in the changed code.

    line 56
  6. Distinctive:

    Run the narrowest formatter/lint, targeted tests, typecheck, and invariant checks that prove the final touched behavior.

    line 82
  7. Very specific:

    When review ran and found no defects, state ✅ No verified review findings.

    line 104
  8. Distinctive:

    Stop when behavior parity or required high-risk validation cannot be established, or a fix requires an unrequested public-contract change …

    line 108

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Code Polish

Resolve scope once. Make only high-confidence simplifications. Fix defects supported by evidence according to their risk. Verify the final state.

Modes

  • --simplify: simplify only.
  • --review: review and fix only.
  • Neither or both: simplify, then review the simplified result.
  • --with-profile <name> / --skip-profile <name>: add or suppress review profiles. Skip wins.

Fixed Scope

  1. Require a Git repository.
  2. Use explicit paths, patterns, ranges, natural-language targets, or a supplied resolved-scope block when present. Otherwise, use only files modified in this session. If session history is unavailable, use all uncommitted tracked and untracked files.
  3. Exclude lockfiles, generated outputs, vendored code, minified bundles, and large data snapshots from manual review unless explicitly requested. Validate relevant excluded outputs through their generator, schema, or invariants.
  4. Resolve and retain one authoritative scope set and optional exclusions for execution. Do not broaden or recompute scope later. Stop if it is empty.

Simplify

Preserve public contracts, inputs, outputs, side effects, error behavior, performance-sensitive characteristics, telemetry, and operational guards. Apply only changes with a concrete comprehension or defect-risk benefit:

  • flatten avoidable control-flow nesting.
  • clarify misleading names or dense transforms.
  • remove real duplication when the abstraction reduces total complexity.
  • tighten local types and contracts without broad churn.
  • remove only dead code caused by this session's edits.

Do not split by line count, perform architecture cleanup, convert sync/async APIs, add speculative configurability, or replace readable duplication with a one-use abstraction. A no-op is a valid result.

Review and Fix

Judge the diff against the user's request. Prioritize CRITICAL → HIGH → MEDIUM → LOW:

  • CRITICAL: exploitable security, data loss, or critical outage path.
  • HIGH: behavior, error-path, boundary, or performance defect affecting core behavior.
  • MEDIUM: resource leak, complexity hotspot, test gap, over-scoped change, speculative complexity, or weak success criterion likely to cause defects.
  • LOW: localized clarity or style issue with a real maintenance cost.

Every finding must cite a verified location, triggering input/state, failure mode, blast radius, and evidence in the changed code. Merge duplicates and apply the smallest defensible fix. Resolve ambiguous intent from the request and repository first. State routine assumptions. Ask only when the answer changes behavior or scope. While that item waits, continue independent in-scope fixes.

Select every applicable profile and read it once. Read all selected profiles together in one parallel turn:

SurfaceProfile
auth, secrets, crypto, external input/network, unsafe parsingsecurity
env, config, timeouts, retries, pools, limitsconfiguration
Go behavior, concurrency, context, errorsgo
Rust, Cargo/workspaces, async/concurrency, unsafe/FFIrust
Swift, iOS/macOS, SwiftUI/UIKit/AppKit, SwiftPM/Xcode targetsswift
Kotlin, Android, coroutines/Flow, Compose, Gradle/manifestkotlin
TypeScript types, modules, packages, async behaviortypescript
Python services, scripts, async, packaging, data IOpython
shell, CI, deploy, installers, quotingshell
CSV/JSON/YAML/binary, schemas, migrations, generated datadata-formats
human-facing numbers, money, percentages, rates, unitsnumber-formatting
naming and intent claritynaming unless skipped

Profiles live at references/profiles/<name>.md. Missing selected profiles are a stop condition.

Verification and Report

Run the narrowest formatter/lint, targeted tests, typecheck, and invariant checks that prove the final touched behavior. Broaden only for shared contracts. Name skipped checks and why.

Summarize scope with the file count and smallest useful repository-relative roots, globs, ranges, or user-supplied targets. Do not enumerate every file merely to prove scope. Name individual paths only for a small explicit scope or to clarify exceptions and findings.

Findings include severity, location, impact, evidence, fix, and confidence. A residual risk states the assumption, consequence if wrong, and how to check it.

Under Issues and caveats, group verified fixes with evidence as Resolved, and remaining problems, limitations, or unverified assumptions as Open, with their impact and next step. Omit empty groups. Report each item once. Put neutral context and agreed decisions under changes or scope.

Reserve blocker for something preventing required work and risk for a specific potential adverse outcome. A workaround leaves an item open when the underlying issue still affects the result. Completion requires fixed scope, traceable edits/findings, and validation evidence.

Lead a successful report with ### ✨ Code polish — ✅ complete, then summarize scope, meaningful changes, and verification. For small results, use short prose. Add tables or sections only when they clarify multiple changes or findings. Honor the user's requested format.

When review ran and found no defects, state ✅ No verified review findings. If a stop condition below prevents completion, lead with ### ✨ Code polish — ⛔ blocked and report the evidence and required decision. Keep severity tokens, profile IDs, commands, locations, reproduction inputs, and security evidence exact and undecorated.

Stop when behavior parity or required high-risk validation cannot be established, or a fix requires an unrequested public-contract change or larger redesign.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.