skills/face-recognition-system-builder/SKILL.md
Build face recognition systems with InsightFace, ArcFace, enrollment pipelines, HDBSCAN clustering, and privacy-compliant architecture. Activate on: face recognition, face enrollment, face clustering, identity verification, facial search. NOT for: general object detection (computer-vision-pipeline), emotion analysis (ai-engineer).
npx skillsauth add curiositech/windags-skills face-recognition-system-builderInstall 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.
Build production face recognition systems with InsightFace/ArcFace for enrollment, verification, identification, and clustering with privacy-compliant architecture.
Requirements Analysis:
├── Latency < 50ms per face?
│ ├── YES: Use buffalo_sc (lightweight, 0.7 accuracy)
│ └── NO: Continue to accuracy analysis
├── Accuracy > 95% required?
│ ├── YES: Use AdaFace (premium accuracy, 200ms latency)
│ └── NO: Use buffalo_l (balanced, 100ms latency)
└── Mobile/Edge deployment?
├── YES: buffalo_sc or custom quantized model
└── NO: buffalo_l or AdaFace
| Use Case | FAR Target | FRR Target | Threshold Range | Validation | |----------|------------|------------|-----------------|------------| | Security/Access Control | <0.1% | 1-5% | 0.55-0.65 | Test on impostor pairs | | Photo Organization | 2-5% | <1% | 0.35-0.45 | Test on family albums | | Investigation/Forensics | <0.01% | 10-20% | 0.65-0.75 | Test on mugshot datasets | | Social Media Tagging | 5-10% | <2% | 0.30-0.40 | Test on casual photos |
Per photo assessment:
├── Face detected with confidence > 0.7?
│ ├── NO: Reject photo, request new one
│ └── YES: Continue
├── Face size > 80px AND < 50% of image?
│ ├── NO: Reject (too small or too close)
│ └── YES: Continue
├── Pose deviation < 30 degrees (yaw/pitch)?
│ ├── NO: Flag as "supplementary only"
│ └── YES: Mark as "primary reference"
└── Final decision:
├── 3+ primary references: Complete enrollment
├── 1-2 primary + 2+ supplementary: Proceed with warning
└── <3 total valid: Require additional photos
Detection: Similarity scores dropping consistently below historical baseline (>10% decrease) Symptoms: Good enrollments start failing verification, complaints of "system doesn't recognize me" Diagnosis: Environmental conditions changed (new lighting, camera angle, seasonal changes) Fix:
Detection: New enrollment has unusually high similarity (>0.8) to existing different identity Symptoms: False positive identifications, "system thinks I'm someone else" Diagnosis: Multiple people enrolled under same identity, or identity mixup during enrollment Fix:
Detection: FAR/FRR metrics shifting >2% from baseline over 30-day periods Symptoms: Gradual increase in false accepts OR false rejects system-wide Diagnosis: Population demographics changing, or model degradation on new data patterns Fix:
Detection: Average enrollment quality score dropping while new enrollments increase Symptoms: Poor recognition accuracy for recently enrolled users Diagnosis: Operators bypassing quality checks to meet enrollment quotas Fix:
Detection: Embedding storage growing faster than enrollment count, or missing consent records Symptoms: Legal compliance audit failures, data retention violations Diagnosis: Raw images stored without consent, or embeddings not properly deleted Fix:
Scenario: COVID-era access control, masks required, camera mounted at door (0.3m typical distance)
Decision Process:
Novice would miss: Using same threshold for masked/unmasked faces, not testing on representative masked dataset Expert catches: Separate calibration needed, eye region weighting more important, enrollment should include masked photos
Final Configuration:
def adaptive_verify(embedding1, embedding2, mask_detected=False):
threshold = 0.45 if mask_detected else 0.55
similarity = np.dot(embedding1, embedding2)
return similarity > threshold
Scenario: Employee self-enrollment via mobile app, submits 3 photos: 1 excellent frontal, 1 slight profile, 1 blurry/dark
Decision Process:
Trade-off Decision: Reject enrollment (high quality standard) vs Accept with warning (user convenience) Chosen: Reject with guidance - better user experience long-term than poor recognition accuracy
Recovery Process:
This skill should NOT be used for:
computer-vision-pipelineai-engineervideo-frame-extraction-analysis firstdata-pipeline-engineer for orchestrationDelegate when you encounter:
system-performance-optimizerdatabase-architectmachine-learning-engineerdata-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.