python-guidelines
Skill3 starsChanged 8 days agoMITView on GitHub
Apply Python policy as a conditional overlay when writing or reviewing Python code, scripts, and services: uv, ruff, ty or mypy, pytest, packaging, CLI/service patterns, and controller or remote runtime contracts. Choosing Python for a new persisted component is language selection in skills-routing.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- youssef-tharwat/lang-guidelinestheir own version, first seen Nov 8, 2026
- stevencarpenter/agentstheir own version, first seen Jul 21, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- youssef-tharwat/lang-guidelines★ 7same name
- stevencarpenter/agents★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository34 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- analyze-projectSkill
- api-contract-strategySkill
- architecture-patternsSkill
- close-changeSkill
- design-changeSkill
- development-standardsSkill
- docker-multiarch-buildSkill
- error-patternsSkill
- go-guidelinesSkill
- herdr-implementSkill
- implement-changeSkill
- logging-standardsSkill
- lua-guidelinesSkill
- organize-docsSkill
- output-stylesSkill
- plan-changeSkill
- powershell-guidelinesSkill
- review-changeSkill
- review-designSkill
- review-implementationSkill
- review-planSkill
- routeros-scripting-guidelinesSkill
- runtime-diagnosisSkill
- security-guardrailsSkill
- shell-guidelinesSkill
- skill-authoringSkill
- skill-minerSkill
- skills-routingSkill
- smart-commitSkill
- sops-age-guardrailsSkill
- sync-truthSkill
- testing-strategySkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 7 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 18
Keep reusable caches and bytecode outside the source tree, distinct from the project environment, and give each owning project its own …
- Distinctive: line 20
Read Tooling And Environments for cache variables, pytest setup, one-off dependencies, and the post-verification check for untracked or …
- Distinctive: line 22
Read Controller And Remote Execution when Python crosses a host or controller boundary, such as an Ansible module or a remote action.
- Very specific: line 28
Add type hints for all function parameters and return values.
- Very specific: line 30
Default a mutable argument to None and build the value inside the function.
- Very specific: line 41
Use the owning project's pinned Ruff through uv run ruff, configured in pyproject.toml.
- Very specific: line 42
Run ruff check --fix --no-unsafe-fixes, then ruff format, as separate commands.
- Distinctive: line 47
Use pytest by default, testing core behavior directly and keeping CLI plumbing thin.
- Distinctive: line 48
Use docstrings for public modules, classes and functions, in Google style for public APIs.
- Distinctive: line 77
Read Script And CLI Patterns for interfaces, invocation and script structure.
- Distinctive: line 78
Read Service Patterns for Python service conventions.
- Distinctive: line 79
Read Review Checks for read-only language review evidence.
≈ “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.
Files
Python Guidelines
Apply Python coding and tooling policy to Python files, scripts, CLIs, services and reviews. An unsettled language or ad hoc tool choice reads references/language-selection.md or references/tool-selection.md in skills-routing. A standard-library script that would acquire third-party runtime packages applies language selection before its environment expands.
Toolchain And Environment
Apply the environment-scope rules in development-standards; these are the Python mappings.
- A Python project with managed dependencies uses
uvfor dependencies and tool execution,pyproject.tomlfor configuration, project-pinned Ruff for formatting and linting, and pytest for tests. Type-check with the checker the project configures (mypyorpyright), and withtywhen the project declares none. - A standard-library-only script or short embedded fragment runs directly on the available interpreter; keep inputs separate from source and honor the host's runtime contract.
- Resolve the nearest owning project, including in multi-project repositories, and run its commands with
uv run --project <project-root> ...or from the owning project root. - Point every project operation at the owning project's external
UV_PROJECT_ENVIRONMENT, following the project or host's storage contract. The environment is project-scoped and reused across runs. Create it only when it is missing, and reuse a compatible existing one. - Keep reusable caches and bytecode outside the source tree, distinct from the project environment, and give each owning project its own pytest
cache_dir.
Read Tooling And Environments for cache variables, pytest setup, one-off dependencies, and the post-verification check for untracked or ignored files.
Read Controller And Remote Execution when Python crosses a host or controller boundary, such as an Ansible module or a remote action.
Coding Requirements
Types And Constants
- Add type hints for all function parameters and return values. Use
X | Nonewhen the runtime supports it, andtyping.Anyonly for a hard constraint, with the reason documented. - Replace magic numbers with named
UPPER_SNAKE_CASEconstants that include units where relevant, such asTIMEOUT_SECONDS. - Default a mutable argument to
Noneand build the value inside the function.
Errors And Security
- Validate inputs early and raise actionable errors with context. Catch a specific exception type.
- Catch generic exceptions only at boundaries, with specific handling, structured logging and re-raise or wrapping. Error classification and recovery choices follow
error-patterns. - Define domain-specific exception classes inheriting from appropriate base classes, with useful context and without sensitive values in messages.
- Load secrets, credentials and configuration values from the environment or project configuration, and redact tokens, passwords and keys in logs.
Formatting And Linting
- Use the owning project's pinned Ruff through
uv run ruff, configured inpyproject.toml. - Run
ruff check --fix --no-unsafe-fixes, thenruff format, as separate commands; continue after exit 1 (residual diagnostics) and stop on any other non-zero exit. Resolve every final lint, format and type failure rather than suppressing it. - Limit changes to authorized files, and let the formatter own line length.
Tests And Documentation
- Use pytest by default, testing core behavior directly and keeping CLI plumbing thin. Cover happy and failure paths for critical logic.
- Use docstrings for public modules, classes and functions, in Google style for public APIs.
Operational Commands (Examples)
Prefer the owning project's versioned command entrypoint. This Bash example runs from the owning project root with an existing uv lockfile; replace the placeholders with the project's declared environment and cache locations and the file list with the authorized files. The exports select an environment for use.
set -euo pipefail
# One project or subproject per environment; caches may be shared, per-project test state may not.
export UV_PROJECT_ENVIRONMENT="<project-env-root>/<project>"
export UV_CACHE_DIR="<cache-root>/uv"
export RUFF_CACHE_DIR="<cache-root>/ruff"
export PYTHONDONTWRITEBYTECODE=1
export PYTHONPYCACHEPREFIX="<cache-root>/python"
files=(path/to/changed.py)
uv run --locked ruff check --fix --no-unsafe-fixes -- "${files[@]}" || {
ruff_exit_code=$?
[ "$ruff_exit_code" -eq 1 ] || exit "$ruff_exit_code"
}
uv run --locked ruff format -- "${files[@]}"
uv run --locked ruff check -- "${files[@]}"
uv run --locked ruff format --check -- "${files[@]}"
uv run --locked ty check .
uv run --locked pytest -q -o "cache_dir=<project-test-state-root>/<project>"Task-Specific References
- Read Script And CLI Patterns for interfaces, invocation and script structure.
- Read Service Patterns for Python service conventions.
- Read Review Checks for read-only language review evidence.
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
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.

