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-embeddingstools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.