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-engineertools
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.