skills/photo-content-recognition-curation-expert/SKILL.md
Expert in photo content recognition, intelligent curation, and quality filtering. Specializes in face/animal/place recognition, perceptual hashing for de-duplication, screenshot/meme detection, burst photo selection, and quick indexing strategies. Activate on 'face recognition', 'face clustering', 'perceptual hash', 'near-duplicate', 'burst photo', 'screenshot detection', 'photo curation', 'photo indexing', 'NSFW detection', 'pet recognition', 'DINOHash', 'HDBSCAN faces'. NOT for GPS-based location clustering (use event-detection-temporal-intelligence-expert), color palette extraction (use color-theory-palette-harmony-expert), semantic image-text matching (use clip-aware-embeddings), or video analysis/frame extraction.
npx skillsauth add curiositech/windags-skills photo-content-recognition-curation-expertInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Expert in photo content analysis and intelligent curation. Combines classical computer vision with modern deep learning for comprehensive photo analysis.
PHOTO LIBRARY SIZE?
├─ <1K photos → Single-pass processing
│ ├─ dHash for duplicates (fastest)
│ └─ Agglomerative clustering (known thresholds)
├─ 1K-10K photos → Optimized pipeline
│ ├─ pHash → DINOHash hybrid
│ └─ HDBSCAN if variance in cluster sizes >3x
└─ >10K photos → Batch processing
├─ GPU batching (batch_size=32)
└─ Incremental updates only
CLUSTERING ALGORITHM CHOICE?
├─ Face variance known? → Agglomerative (threshold=0.4, 0.6)
├─ Unknown distribution? → HDBSCAN (auto-threshold)
└─ Real-time additions? → Incremental clustering
DUPLICATE DETECTION ROBUSTNESS?
├─ Exact duplicates only? → dHash (Hamming ≤3)
├─ Brightness/contrast edits? → pHash (Hamming ≤5)
├─ Heavy crops/compression? → DINOHash (Hamming ≤10)
└─ Production system? → Hybrid (pHash→DINOHash)
BURST PHOTO SELECTION?
├─ Face quality available? → Weight faces 35%, sharpness 30%
├─ No faces detected? → Weight sharpness 50%, aesthetics 30%
└─ Action photos? → Weight sharpness 60%, exposure 25%
CONTENT FILTERING CONFIDENCE?
├─ Screenshot confidence >0.6? → Filter out
├─ NSFW confidence >0.8? → Filter out
├─ Face confidence <0.9? → Exclude from clustering
└─ Pet confidence <0.7? → Manual review
Root Cause: Clustering threshold too strict, splitting same person into multiple clusters Detection Rule: If clusters/unique_people ratio > 2.0, threshold too conservative Fix:
Root Cause: Perceptual hash threshold too loose, faces in similar poses triggering matches Detection Rule: If duplicate groups contain faces with cosine distance >0.7, hash threshold too aggressive Fix:
Root Cause: Face quality override masking sharpness issues when faces poorly detected Detection Rule: If selected burst frame Laplacian variance <500 while other frames >1000 Fix:
Root Cause: Single-signal detection missing edge cases (dark mode, custom UI) Detection Rule: If photos contain perfect rectangles + high text density but confidence <0.6 Fix:
Root Cause: Loading all images into memory simultaneously instead of streaming Detection Rule: If memory usage >2GB per 1000 photos, batch size too large Fix:
Scenario: Family vacation photos (500 images), many bursts and similar poses, want top 100 for sharing.
Step 1 - Library Analysis:
Step 2 - Duplicate Detection:
# Stage 1: Fast pHash filtering
pHash_duplicates = find_duplicates_phash(photos, threshold=5)
# Found 45 potential duplicate groups
# Stage 2: DINOHash verification
verified_duplicates = []
for group in pHash_duplicates:
dino_hashes = [compute_dinohash(img) for img in group]
if hamming_distance(dino_hashes[0], dino_hashes[1]) <= 8:
verified_duplicates.append(group)
# Verified 38 true duplicate groups
Step 3 - Face Clustering Decision:
Step 4 - Burst Selection Trade-offs:
Final Output: 387 unique photos → 100 curated (top aesthetic + diversity)
Scenario: Wedding ceremony burst of 15 shots, bride's face overexposed in sharpest frames.
Challenge: Best technical shot (frame 8) has bride's face blown out by direct sunlight.
Analysis Process:
# Frame 8: Sharpness winner but face quality fail
frame_8_metrics = {
'sharpness': 2100, # Highest in burst
'face_quality': 0.2, # Overexposed face detection
'aesthetics': 0.75, # Good composition
'exposure': 0.3 # Highlights clipped
}
# Frame 11: Balanced option
frame_11_metrics = {
'sharpness': 1650, # Still acceptable
'face_quality': 0.9, # Clear face, good exposure
'aesthetics': 0.8, # Slightly better angle
'exposure': 0.85 # Well exposed
}
# Weighted scoring:
frame_8_score = 2100*0.3 + 0.2*0.35 + 0.75*0.2 + 0.3*0.05 = 630 + 0.07 + 0.15 + 0.015 = 630.235
frame_11_score = 1650*0.3 + 0.9*0.35 + 0.8*0.2 + 0.85*0.05 = 495 + 0.315 + 0.16 + 0.0425 = 495.518
Expert Insight: Frame 11 selected despite lower sharpness because face quality penalty (-80%) outweighs sharpness advantage. Novice would pick frame 8 based on technical metrics alone.
Photo Indexing Complete:
Duplicate Detection Complete:
Face Clustering Complete:
Burst Selection Complete:
Content Filtering Complete:
This skill should NOT be used for:
GPS-based location clustering → Use event-detection-temporal-intelligence-expert instead
Color palette extraction and harmony → Use color-theory-palette-harmony-expert instead
Semantic image-text matching → Use clip-aware-embeddings instead
Video analysis or frame extraction → Use video processing specialist instead
Advanced photo editing → Use image editing specialist instead
3D scene reconstruction → Use computer vision specialist instead
Delegation Rules:
event-detection-temporal-intelligence-expertcolor-theory-palette-harmony-expertclip-aware-embeddingsdata-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.