Python development with ruff, mypy, pytest - TDD and type safety
40
38%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/python/SKILL.mdQuality
Discovery
32%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description reads more like a tag list than a proper skill description. While it names specific tools (ruff, mypy, pytest) which aids in identification, it lacks concrete action verbs describing what the skill does and entirely omits a 'Use when...' clause to guide skill selection. It would benefit significantly from describing specific capabilities and explicit trigger conditions.
Suggestions
Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks about linting, type checking, running tests, or setting up Python code quality tooling.'
Replace the tag-like format with concrete action descriptions, e.g., 'Configures and runs ruff for linting/formatting, mypy for static type checking, and pytest for test-driven development in Python projects.'
Include common natural language variations users might say, such as 'unit tests', 'linting', 'type errors', 'code formatting', 'test coverage', or 'Python code quality'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Python development) and lists specific tools (ruff, mypy, pytest) along with methodologies (TDD, type safety), but doesn't describe concrete actions like 'run tests', 'lint code', 'check types', or 'format files'. | 2 / 3 |
Completeness | Provides a partial 'what' (Python development with specific tools) but completely lacks a 'when' clause or any explicit trigger guidance. Per rubric guidelines, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also weak enough to warrant a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant tool names (ruff, mypy, pytest) and concepts (TDD, type safety) that users might mention, but misses common variations like 'linting', 'testing', 'type checking', 'unit tests', 'formatting', or 'Python code quality'. | 2 / 3 |
Distinctiveness Conflict Risk | The specific tool names (ruff, mypy, pytest) and TDD methodology provide some distinctiveness, but 'Python development' is broad enough to overlap with general Python coding skills or other Python-related skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
44%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides excellent concrete, executable examples for Python tooling configuration (ruff, mypy, pytest) and good coding patterns. However, it lacks a coherent TDD workflow despite being described as a TDD skill, reads as a reference dump rather than a structured guide, and would benefit significantly from splitting content into referenced files and adding a clear development workflow sequence.
Suggestions
Add an explicit TDD workflow section with clear steps: 1. Write failing test → 2. Run pytest (expect failure) → 3. Implement minimal code → 4. Run pytest (expect pass) → 5. Run ruff/mypy → 6. Refactor
Split the GitHub Actions, pre-commit config, and patterns sections into separate referenced files (e.g., CI.md, PATTERNS.md) and add a quick-start overview with navigation links
Remove the anti-patterns list and basic concepts (dependency injection, project structure) that Claude already knows, or condense them to project-specific conventions only
Add validation checkpoints connecting the tools: e.g., 'After writing code, run this sequence: ruff check . && mypy src/ && pytest — fix issues in this order'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with good code examples, but includes some content Claude already knows well (anti-patterns list, basic dependency injection concept, basic project structure conventions). The GitHub Actions and pre-commit config sections are quite long and could be more concise or referenced externally. | 2 / 3 |
Actionability | The skill provides fully executable, copy-paste ready code examples throughout: pyproject.toml config, pytest examples with Arrange/Act/Assert, GitHub Actions workflow, pre-commit config with install commands, and concrete Python patterns with good/bad comparisons. | 3 / 3 |
Workflow Clarity | Despite the description mentioning TDD, there is no clear TDD workflow sequence (e.g., write test → run test → see failure → implement → run test → see pass). The sections are presented as independent reference blocks without a coherent multi-step development workflow or validation checkpoints connecting them. | 1 / 3 |
Progressive Disclosure | The content is a monolithic wall of text with no references to external files and no clear navigation structure. All content (tooling config, CI, pre-commit, patterns, anti-patterns) is inline in a single file with no overview or signposting, making it hard to navigate for a ~150-line skill. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
65efb33
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.