content-hash-cache-pattern
Cache expensive file processing results using SHA-256 content hashes — path-independent, auto-invalidating, with service layer separation.
68
52%
Does it follow best practices?
Impact
100%
1.44xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/content-hash-cache-pattern/SKILL.mdQuality
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) with distinctive architectural details, but reads like an implementation summary rather than a skill selection guide. It lacks explicit trigger guidance ('Use when...') and natural user-facing keywords, making it difficult for Claude to know when to select this skill from a large pool.
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'.
Reframe the architectural details ('service layer separation', 'path-independent') as concrete actions, e.g., 'Implements content-addressed caching that detects file changes regardless of path, separates cache logic into a reusable service layer, and auto-invalidates stale entries.'
| 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 more architectural than actionable, warranting 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 service layer separation is quite specific and unlikely to conflict with other skills. This occupies a clear niche around content-addressed caching for file processing. | 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 executable code examples and clear design rationale. Its main weaknesses are redundancy between sections (When to Activate vs When to Use, inline comments vs Best Practices vs Design Decisions table) and lack of explicit workflow sequencing with validation checkpoints. The content would benefit from consolidation and trimming of repeated information.
Suggestions
Merge 'When to Activate' and 'When to Use' / 'When NOT to Use' into a single section to eliminate redundancy.
Remove the 'Key Design Decisions' table and 'Best Practices' section — the rationale is already clear from inline code comments and the 'Why content hash?' callout.
Add an explicit numbered integration workflow showing how to wire this into a CLI tool, including a verification step (e.g., 'Run once, confirm cache file created, run again, confirm cache hit in logs').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill has 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 the 'Best Practices' section restates points made in the code. However, it's not egregiously verbose and avoids explaining basic concepts like what SHA-256 is. | 2 / 3 |
Actionability | All code examples are concrete, executable Python with proper imports, type hints, and realistic patterns. The full pipeline from hashing to cache read/write to service layer wrapper is copy-paste ready, and anti-patterns show specific bad code to avoid. | 3 / 3 |
Workflow Clarity | The service layer wrapper implicitly shows the workflow (hash → check cache → extract → store), but there's no explicit numbered sequence for the overall integration workflow. There are no validation checkpoints — e.g., no step to verify the cache is working correctly or to validate serialized data integrity after writing. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and sections, but it's a monolithic file (~120 lines of substantive content) with no references to external files. The design decisions table and best practices could be separate references, and the anti-patterns section adds length that could be linked out. | 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 | |
- Repository
- affaan-m/everything-claude-code
- Commit
5df943e
- Reviewed
Table of Contents
Is this your skill?
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.