القائمة
Rewrites unprofessional code comments into clear ones and performs non-semantic cleanup. Use to professionalize code without altering logic or behavior.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test th
Triage acc's open promises and close them with honest real-world verdicts via acc_act(runtime="outcome").
Drain acc's deliberation queue — open/waiting brain_frames checkpointed by headless runs — via acc_act(runtime="continue").
Route a goal through acc's scored-memory loop via acc_act(runtime="solve"); deliberate any returned brain_frame and submit via continue.
Add an iOS App Clip target to an Expo app. Use when the user mentions App Clip, AASA, apple-app-site-association, appclips, smart app banner, or wants to ship a lightweight iOS Clip invoked from a URL
A hybrid memory system that provides persistent, searchable knowledge management for AI agents.
| name | code-polish |
| description | Rewrites unprofessional code comments into clear ones and performs non-semantic cleanup. Use to professionalize code without altering logic or behavior. |
| category | Document Processing |
| source | antigravity |
| tags | ["python","api","ai","document","security","cro"] |
| url | https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/code-polish |
A constraint-based protocol for normalizing code comments and performing safe, non-semantic cleanup. This skill exists because human-written code tends to carry casual, outdated, or missing comments, while the goal is professional-grade documentation without touching behavior.
This file is self-contained. Do not require any other skill file to execute this protocol.
Comments and non-semantic cleanup are the job. Logic is never the job. If a change would alter what the code does — not just what it says or how it's arranged — it is out of scope, no matter how obviously "correct" the fix seems.
Apply this skill when:
Do not apply this skill when:
Before editing anything, read the entire file (or the entire relevant module if the codebase is large — not just the function in question). Do not comment or clean incrementally while still reading. A comment written without full context is a guess, and guesses are how "professional" comments end up wrong.
Identify:
/// for Rust, XML doc comments, etc.)Classify every existing comment into one of these categories before touching it:
| Category | Example | Action |
|---|---|---|
| Junk / venting | // wtf is this, // idk why but it works | Remove tone, extract any real information underneath, rewrite professionally — or delete if it truly holds zero information |
| Placeholder | // fix later, // TODO hack | Convert to a proper TODO: note with the actual concern stated plainly, or remove if stale/resolved |
| Dead code comments | Blocks of commented-out code | Remove, unless the surrounding context makes clear it's intentionally preserved (e.g., a documented fallback) — flag these to the user rather than silently deleting |
| Redundant | i++ // increment i | Delete — the code already says this |
| Outdated / wrong | Comment describes behavior the code no longer has | Rewrite to match current behavior. Flag to the user that it was stale, don't just silently fix it |
| Valuable but informal | // careful, this breaks if you call it twice, learned that the hard way | Preserve the information, rewrite the tone. Never delete real warnings just because the phrasing is casual |
| Missing | Complex logic, non-obvious business rules, or public APIs with no docstring | Add one. Don't over-comment simple, self-explanatory lines |
Scope is strictly limited to changes that cannot alter behavior:
Anything beyond this — reordering logic, extracting functions, changing control flow, altering algorithms — is out of scope for this skill.
Apply these standards to every comment touched or added:
///, etc.) — match the convention already used elsewhere in the file if one exists.