python-conventionslisted

Use when writing, reviewing or refactoring Python and you want one settled answer rather than an evaluation — choosing between a dataclass, a Pydantic model, a NamedTuple, a TypedDict, attrs or msgspec; handling dates, times and timezones, including DST folds and gaps and where to convert to UTC; loading settings and secrets; when to use a guard clause, an early return or EAFP; designing an exception hierarchy; keeping type ignores honest; laying a package out under `src/`; building a CLI; async and concurrency; and how an HTTP client should handle sessions, timeouts and retries. Also when a module has accumulated global state, grown hard to follow, or needs restructuring — how far to break it up, when a module-level singleton with lazy properties is the right shape, and how to keep objects immutable and functions stateless. For tests see the Python testing skill; for MCP server internals see the MCP Python skill.
TheodoreAD/agent-skills · ★ 0 · AI & Automation · score 72

Install: claude install-skill TheodoreAD/agent-skills

# Python design and style defaults Personal, agent-maintained Python projects. Applies when writing new code or reviewing existing code against one of the topics below without an explicit "evaluate alternatives" request — pick the default, don't re-litigate from scratch each session. Deviating is fine when a case genuinely matches one of the named escalation paths — the point is to stop a fresh session/model from silently picking something different for no reason, not to forbid judgment calls. **Two topics were split out on 2026-08-31** and are separate installs: test-suite conventions are in `python-testing-conventions`, and the stdio-logging, tool-boundary and tool-docstring rules for MCP servers are in `mcp-python-conventions`. The split was measured before it was made — the pieces were checked against real requests to confirm each wins its own and none steals from the others. **This is design guidance, not tool config.** Nothing here tells you which type checker or linter to install, or how to configure one — that belongs to whatever your repo uses to enforce its own standards (basedpyright, ruff, shellcheck/shfmt, dprint and pytest config, in this author's case). This skill is what to reference _while writing code_; tooling config is what a repo enforces _once, at setup_. **Each topic below states whether it's overriding your own default instinct or just confirming one.** A capable model already gets a lot of this right without being told — early returns, EAFP for ru