Agent Skills: SnakePolish — Python Modernization Assessor

Executes the implementation phase of the python-engineering stinkysnake modernization workflow. Use when stinkysnake phases 1-8 are complete — modernization plan reviewed, interfaces designed, and failing tests written. Implements functions in dependency order (types, data structures, utilities, core logic, integration, entry points) applying modern Python patterns (Protocol, dataclass, Pydantic, modern type annotations, httpx, orjson). Runs iterative pytest loops until all tests pass, then verifies with static analysis via prek or ruff. Success criteria — all tests pass, no type errors, no lint errors, coverage meets project threshold.

UncategorizedID: Jamie-BitFlight/claude_skills/snakepolish

Install this agent skill to your local

pnpm dlx add-skill https://github.com/Jamie-BitFlight/claude_skills/tree/HEAD/plugins/python-engineering/skills/snakepolish

Skill Files

Browse the full folder contents for snakepolish.

Download Skill

Loading file tree…

plugins/python-engineering/skills/snakepolish/SKILL.md

Skill Metadata

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.

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.

SnakePolish — Python Modernization Assessor Skill | Agent Skills