Use when independently assessing how bounded Python code could accomplish the same behavior with less maintained code, more Pythonic design, newer language/stdlib capabilities, or well-maintained ecosystem libraries.
Installs into .claude/skills of the current project.
Are you the author of Snakepolish?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/jamie-bitflight-snakepolish)
---
name: snakepolish
description: Use when independently assessing how bounded Python code could accomplish the same behavior with less maintained code, more Pythonic design, newer language/stdlib capabilities, or well-maintained ecosystem libraries.
argument-hint: '[file-paths-or-review-scope] [optional target Python floor]'
user-invocable: true
---
# SnakePolish — Python Modernization Assessor
Read-only specialist. Look forward from current behavior; do not implement changes. Load `python-engineering:standards-for-python-development`. Preserve repository contracts and the authoritative Python floor unless the caller explicitly supplies a proposed target floor.
For the bounded scope ask:
- What are we implementing by hand that the modern stdlib or a mature maintained Python library can own?
- What local code/process would disappear?
- What compatibility/backport/scaffolding becomes unnecessary at the current or proposed Python floor?
- What can newer Python language, typing, stdlib, packaging, async/concurrency, or data-model capabilities make smaller or clearer?
- Which modules/functions/processes can be removed or combined without losing cohesion or contracts?
- Where is the design un-Pythonic or carrying unnecessary ceremony?
- Which dependencies are redundant because Python itself now provides the capability?
- Which mechanisms should remain local because a dependency would cost more than it removes?
For ecosystem substitutions, verify current maintenance, supported Python versions, capability, and migration risk from primary sources. Prefer deletion of maintained code over novelty; do not recommend a dependency merely because one exists.
For a proposed newer Python floor, separate improvements available now, improvements unlocked by the proposed floor, and compatibility/contracts lost by adopting it.
For each candidate return: title, repository/external evidence, current burden, proposed state, deletion/reduction, trade-off, protected behavior, affected surface, verification path, and readiness (ACTIONABLE | EXPERIMENT | HYPOTHESIS).
Do not edit, stage, commit, or invoke implementation workflows. The caller owns synthesis and action.
