taste-python

Detects forbidden Python patterns in proposed edits using grep-based boundary checks.

1|1|Updated Jun 21, 2026
One-click install
npx skills add https://github.com/Navdeepgambhir9023/nav --skill taste-python-navdeepgambhir9023
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: taste-python
Source: https://github.com/Navdeepgambhir9023/nav/tree/main/skills/taste/python
Command: npx skills add https://github.com/Navdeepgambhir9023/nav --skill taste-python-navdeepgambhir9023

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Python codebases accumulate classic footguns — bare excepts, mutable default arguments, shell=True subprocess calls, star imports — that slip past review and cause production bugs. This Skill acts as a runtime guardrail that catches these forbidden patterns as edits are proposed, before they land on disk. ## Core Features & Use Cases - Pattern-Based Boundary Checks: Soft-warns on nine rule categories including bare except clauses, print statements outside tests, star imports, mutable defaults, asyncio.run inside running loops, shell=True subprocess calls, Any type escapes, requirements.txt drift, and free-form JSON permission grants. - Path-Triggered Loading: Activates automatically when edits target .py files, pyproject.toml, requirements.txt, or test files under /tests/, with a relaxed rule set for test code. - Advisory, Non-Blocking: Returns OK or a soft warning with the matched rule; it never blocks the write, keeping the developer in control. - Use Case: While an agent edits a service module and introduces except Exception: pass, the hook flags the line and suggests catching a specific exception or logging before re-raising. ## Quick Start Ask the agent to review a proposed Python file edit and report any taste rule violations such as bare excepts, mutable defaults, or shell=True usage.

Frequently Asked Questions about taste-python

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I catch common Python code smells automatically during edits?

Load this guardrail when editing Python files and it grep-checks each proposed diff against nine forbidden patterns. Matches produce a soft warning naming the violated rule and a suggested fix, without blocking the write.

What Python anti-patterns does this boundary check detect?

It detects bare except clauses, print calls outside tests, star imports, mutable default arguments, asyncio.run inside running loops, subprocess with shell=True, Any used to silence type-checkers, requirements.txt replacing pyproject.toml, and free-form JSON permission grants.

Does the Python guardrail block file writes when it finds a violation?

No, the hook is advisory only. It returns either OK or a soft warning describing the matched rule, and the write proceeds regardless, leaving the final decision to the developer.

Are the rules different for Python test files?

Yes, under **/tests/** the rules are relaxed: print is allowed for debug output, Any is allowed in fixtures and stubs, and bare except is tolerated in pytest.raises helpers. All other rules apply unchanged.

Does this replace linters like Ruff or formatters like Black?

No, formatting and linting are explicitly out of scope and handled by the language server or formatter. This guardrail covers language-level taste rules only, not style, type-checker choice, or framework-specific concerns.