tdg-personal/content-hash-cache-pattern
Cache expensive file processing results using SHA-256 content hashes — path-independent, auto-invalidating, with service layer separation.
71
71%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
50%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 excels at specificity and distinctiveness, clearly articulating a narrow technical capability with precise architectural details. However, it completely lacks a 'Use when...' clause, making it difficult for Claude to know when to select this skill from a large pool. The trigger terms are overly technical and may not match how users naturally describe their needs.
Suggestions
Add a 'Use when...' clause with trigger scenarios, e.g., 'Use when the user wants to avoid reprocessing unchanged files, needs content-based caching, or asks about performance optimization for file processing pipelines.'
Include more natural user-facing trigger terms like 'speed up file processing', 'avoid reprocessing', 'memoization', 'performance', or 'duplicate work detection'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and architectural details: 'Cache expensive file processing results', 'SHA-256 content hashes', 'path-independent', 'auto-invalidating', 'service layer separation'. These are concrete, specific capabilities. | 3 / 3 |
Completeness | Describes what the skill does (caching with content hashes) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, a missing 'Use when...' clause caps completeness at 2, and since the 'when' is entirely absent, this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant technical keywords like 'cache', 'SHA-256', 'content hashes', but these are fairly technical. Missing more natural user terms like 'speed up', 'avoid reprocessing', 'memoize', or 'performance optimization'. A user needing caching might not phrase their request using these exact terms. | 2 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: SHA-256 content-hash-based caching with specific architectural patterns (path-independent, auto-invalidating, service layer separation). Unlikely to conflict with other skills due to the very specific technical scope. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable skill with executable code examples and clear architectural guidance. Its main weakness is moderate verbosity — redundant sections (When to Activate/When to Use), a design decisions table that largely restates inline comments, and best practices that echo what the code already demonstrates. The workflow is well-sequenced and the pattern is clearly communicated.
Suggestions
Merge 'When to Activate' and 'When to Use'/'When NOT to Use' into a single concise section to eliminate redundancy.
Remove the 'Key Design Decisions' table since each rationale is already explained inline via comments and the 'Why content hash?' callout — or keep only the table and remove inline explanations.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with good code examples, but includes some redundancy: 'When to Activate' and 'When to Use' sections overlap significantly, the 'Key Design Decisions' table repeats rationale already evident from inline comments, and some best practices restate what the code already demonstrates. | 2 / 3 |
Actionability | Provides fully executable Python code for every component: hashing, cache storage, cache reading, and the service layer wrapper. The code is copy-paste ready with proper imports, type hints, and error handling. Anti-patterns show concrete bad examples alongside the good patterns. | 3 / 3 |
Workflow Clarity | The service layer wrapper clearly sequences the workflow: cache check → extraction → cache write. The numbered sections (1-4) build logically from hash computation to cache entry to storage to the orchestrating service layer. Corruption handling serves as a validation/recovery mechanism. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and logical sections, but it's a fairly long monolithic document (~130 lines of substantive content). The design decisions table and best practices could potentially be separate references. However, there are no external file references, and some sections like 'When to Use' vs 'When NOT to Use' could be consolidated. | 2 / 3 |
Total | 10 / 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