
python-foundational
Foundational Python best practices, idioms, and code quality fundamentals
- Installs
- 71
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/microsoft/hve-core --skill python-foundational- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads python-foundational automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Python Foundational Coding Standards Skill
Overview
Foundational Python excellence that every diff must satisfy. This skill is loaded first for any .py change. All higher-order skills build on it.
This content is a skill rather than an instructions file for three reasons: skills are distributed through the CLI plugin and VS Code extension without requiring consumers to copy files into their repo; new language skills can be added without modifying the review agent itself; and skills are loaded on demand, keeping the context window small when the diff contains no Python.
Core Checklist
1. Readability & Style
- Use Python naming:
PascalCaseclasses,snake_casefunctions/variables,UPPER_SNAKE_CASEconstants,_private members. - Group imports: stdlib → third-party → local (blank line between groups, no trailing whitespace).
2. Pythonic Idioms
- Prefer comprehensions for simple transforms; use explicit loops for complex logic/side-effects.
- Always use
withfor files, locks, DB connections. - Prefer
dataclass/NamedTuple/Enumfor data holders. - Use
pathliboveros.path; timezone-awaredatetimewhen relevant. - Use
*keyword-only arguments for multi-optional functions. - Never use mutable defaults or
global/nonlocalunless strictly required.
3. Function & Class Design
- Keep functions small and single-responsibility.
- Add docstrings to all public APIs (follow repo style).
- Document unavoidable side-effects.
- Follow codebase’s class-member ordering (if defined).
4. Type Safety Foundations
- Add type hints to all public APIs, module vars, and class attributes.
- Use PEP 695 (3.12+) or
TypeVarfor generics. - Avoid
Anyexcept in thin wrappers.
5. Error Handling
- Raise specific exceptions; never bare
except:(broadexcept Exception:only at app boundaries with logging). - No silent failures or generic error messages.
- Provide context, expected state, and guidance in every exception.
6. Anti-Patterns to Avoid
- Never use
eval,exec, orpickleon untrusted data. - Never hard-code secrets.
7. Maintainability
- Prefer self-documenting code; comments only for "why".
- Use structured logging instead of
print. - Flag overly long/complex functions that resist testing.
8. Architectural Fit
- Align with existing patterns; do not re-implement shared functionality or bypass established layers.
- Place code in the correct module/package.
9. Design Principles
- Eliminate duplication: extract repeated logic into a shared helper so fixes propagate automatically.
- Prefer the simplest implementation that satisfies current requirements. Introduce abstractions only when a second concrete use case appears.
- Limit change breadth: every modified line should trace to the stated purpose of the change.
- Before flagging seemingly unused code, verify it is not a protocol implementation, framework hook, public API, or entry point invoked externally.
- Match solution complexity to problem complexity. A duplicated function warrants a shared helper, not an event-driven architecture.
References
| File | Covers | Purpose |
|---|---|---|
| design-principles.md | Section 9 | Rationale and examples for the design principles |
| code-style-patterns.md | Sections 1–5 | Concrete code examples for style, idioms, type safety, class design, and error handling |
Severity Rubric
| Severity | Definition |
|---|---|
| High | Causes incorrect behavior, data loss, or security exposure at runtime |
| Medium | Degrades maintainability, readability, or violates a project convention with no immediate runtime impact |
| Low | Cosmetic, stylistic, or minor improvement opportunity |
Troubleshooting
| Symptom | Check |
|---|---|
| Skill not loaded | Confirm the diff contains .py files. The agent selects skills by matching file types in the changed files against skill descriptions. |
| No findings generated | Verify the Skills Loaded footer in the review output lists python-foundational. If listed but no findings appear, the diff may already satisfy the checklist. |
| Severity seems miscalibrated | Compare against the Severity Rubric above. High requires runtime impact; medium is maintainability-only. |
Contributing
Follow these conventions when extending this skill:
- Checklist items belong in SKILL.md. Each bullet is a single, actionable check an agent or reviewer can apply to a diff. Keep bullets concise: one sentence, no code.
- Reference files live in
references/and provide examples or rationale for the covered checklist items. Each reference file covers a contiguous range of sections. Update the References table when adding a new file. - Before adding a new checklist item, confirm it does not duplicate an existing bullet in any section. Place it in the section that matches its primary concern. If it spans concerns, prefer the more specific section.
- Name new reference files after the topic they cover (e.g.,
async-patterns.md). Include a frontmatterdescriptionthat states which sections the file supports. Add a row to the References table in SKILL.md. - Checklist items and examples must be portable across codebases. Use generic module names and describe anti-patterns by their behavior, not by specific directory or file names.
FAQ
What does the python-foundational skill do?
Foundational Python best practices, idioms, and code quality fundamentals
How do I install python-foundational?
Run npx skills add https://github.com/microsoft/hve-core --skill python-foundational in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/python-foundational/ (personal) or .claude/skills/python-foundational/ (project).
Which AI agents can use python-foundational?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is python-foundational safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains python-foundational?
It is published by microsoft in microsoft/hve-core, and it is an official skill from the maker of the technology it covers. It has 71 recorded installs.
More from microsoft/hve-core
owasp-top-10
microsoft/hve-core
OWASP Top 10 for Web Applications (2025) knowledge base for identifying, assessing, and remediating web application security risks.
powerpoint
microsoft/hve-core
Open the skill to read its SKILL.md instructions.
secure-by-design
microsoft/hve-core
Open the skill to read its SKILL.md instructions.
owasp-docker
microsoft/hve-core
Open the skill to read its SKILL.md instructions.
owasp-cicd
microsoft/hve-core
Open the skill to read its SKILL.md instructions.
owasp-infrastructure
microsoft/hve-core
Open the skill to read its SKILL.md instructions.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.