tdg-personal/django-verification
"Verification loop for Django projects: migrations, linting, tests with coverage, security scans, and deployment readiness checks before release or PR."
68
68%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Risky
Do not use without reviewing
Quality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description does a good job listing specific concrete actions within a well-defined Django verification workflow, making it distinctive. However, it lacks an explicit 'Use when...' clause, which weakens its completeness for skill selection purposes. The trigger terms are relevant but could include more natural user phrasings.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when preparing a Django project for release, opening a PR, or when the user asks to verify, check, or validate their Django codebase.'
Include additional natural trigger terms users might say, such as 'pre-merge checks', 'CI checks', 'ready to deploy', 'validate Django app', or 'pre-commit verification'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: migrations, linting, tests with coverage, security scans, and deployment readiness checks. These are clearly defined verification steps. | 3 / 3 |
Completeness | The 'what' is well-covered (verification loop with specific checks), and there's an implied 'when' ('before release or PR'), but there is no explicit 'Use when...' clause with trigger guidance. Per rubric guidelines, a missing explicit trigger clause caps completeness at 2. | 2 / 3 |
Trigger Term Quality | Includes relevant terms like 'Django', 'migrations', 'linting', 'tests', 'coverage', 'security scans', 'PR', and 'release', but misses common user phrasings like 'check my code', 'pre-commit', 'CI pipeline', or 'ready to deploy'. Some terms are natural but coverage of variations is incomplete. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'Django projects' with a specific verification loop (migrations, linting, tests, security, deployment readiness) creates a clear niche that is unlikely to conflict with generic testing or linting skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
55%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill is highly actionable with concrete commands and a well-structured multi-phase workflow with clear validation checkpoints. However, it is severely bloated—much of the content (basic git commands, Python version checks, full CI YAML, logging tests) is either obvious to Claude or should be split into referenced files. The monolithic structure makes it a poor use of context window tokens.
Suggestions
Reduce to ~80-100 lines by condensing each phase to its essential commands and moving detailed examples (CI config, output template, per-phase common issues) to separate referenced files.
Remove content Claude already knows: basic git diff usage, how to check Python version, how pip works, what environment variables are.
Split into SKILL.md (overview + quick reference table) with references like [CI_CONFIG.md], [OUTPUT_TEMPLATE.md], [SECURITY_CHECKS.md] for detailed content.
Remove the explanatory 'Common issues' lists and 'Report' sections that describe what to look for—Claude can infer these from the commands themselves.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~350+ lines with 12 phases, many of which cover things Claude already knows (how to run git diff, how to check Python version, how to use pip). The CI example, logging checks, and static asset sections add significant bloat. Much of this could be condensed to a quick-reference table with phase descriptions. | 1 / 3 |
Actionability | Every phase includes concrete, executable bash commands and Python snippets that are copy-paste ready. Coverage targets are specific with a clear table, and the output template shows exactly what the report should look like. | 3 / 3 |
Workflow Clarity | The 12 phases are clearly sequenced with explicit validation checkpoints (e.g., 'If environment is misconfigured, stop and fix'), feedback loops in the output template showing pass/fail status, and a pre-deployment checklist. The recommendation section includes next steps for remediation. | 3 / 3 |
Progressive Disclosure | This is a monolithic wall of text with all 12 phases, a full CI config, output template, quick reference table, and pre-deployment checklist all inline. There are no references to external files; content like the GitHub Actions example, the output template, and detailed per-phase commands should be split into separate referenced documents. | 1 / 3 |
Total | 8 / 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 | |
Reviewed
Table of Contents