tdg-personal/content-hash-cache-pattern
Cache expensive file processing results using SHA-256 content hashes — path-independent, auto-invalidating, with service layer separation.
48
61%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
40%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 identifies a clear technical niche (content-hash-based caching for file processing) with distinctive architectural details, but it reads like a feature list rather than a skill selection guide. It completely lacks a 'Use when...' clause, making it difficult for Claude to know when to select this skill, and the language is overly technical rather than matching natural user requests.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when implementing caching for file processing, avoiding redundant computation on unchanged files, or when the user mentions content hashing or memoization.'
Include natural trigger terms users would say, such as 'speed up file processing', 'skip unchanged files', 'avoid reprocessing', 'memoize results', or 'cache invalidation'.
List concrete actions the skill enables, e.g., 'Generates cache keys from file content, stores and retrieves processed results, automatically invalidates stale entries when files change.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (caching file processing results) and mentions specific techniques (SHA-256 content hashes, service layer separation), but doesn't list multiple concrete user-facing actions — it reads more like an architectural description than a list of capabilities. | 2 / 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, missing 'Use when' caps completeness at 2, and the 'what' is also somewhat vague on concrete actions, so this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant terms like 'cache', 'file processing', 'SHA-256', and 'content hashes', but these are fairly technical. Missing natural user phrases like 'speed up', 'avoid reprocessing', 'memoize', or 'skip unchanged files' that users would actually say. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of SHA-256 content hashing, path-independent caching, and auto-invalidation creates a very specific niche that is unlikely to conflict with other skills. This is clearly distinguishable from general caching or file processing skills. | 3 / 3 |
Total | 8 / 12 Passed |
Implementation
64%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 excellent executable code examples and clear anti-patterns. Its main weaknesses are moderate redundancy across sections (When to Activate/When to Use overlap, design decisions restating inline comments) and lack of explicit validation steps in the workflow. The content would benefit from tightening and adding a verification step.
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.
Add a validation/verification step, e.g., a quick smoke test showing how to confirm the cache round-trips correctly (write then read back and assert equality).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content 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 (e.g., chunking, corruption handling). | 2 / 3 |
Actionability | Provides fully executable, copy-paste ready Python code for every component: hashing, cache entry dataclass, read/write operations, and the service layer wrapper. Anti-patterns include concrete bad examples contrasted with the correct approach. | 3 / 3 |
Workflow Clarity | The service layer wrapper implicitly shows the cache-check → extract → store flow, and the numbered sections (1-4) provide a build-up sequence. However, there are no explicit validation checkpoints — no guidance on verifying cache integrity, testing the cache works correctly, or handling edge cases like disk-full scenarios during write. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and sections, but it's a monolithic file (~150 lines of substantive content) with no references to external files. The design decisions table and best practices could be separate references. However, given no bundle files exist, the single-file approach is acceptable but not optimal. | 2 / 3 |
Total | 9 / 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