tinysocs-validation-and-qa

Defines evidence standards for validating TinySocs detection rules via xUnit tests and Atomic Red Team harness.

Updated Oct 12, 2025
One-click install
npx skills add https://github.com/lukefitzg/tinysocs --skill tinysocs-validation-and-qa-lukefitzg
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tinysocs-validation-and-qa
Source: https://github.com/lukefitzg/tinysocs/tree/main/.claude/skills/tinysocs-validation-and-qa
Command: npx skills add https://github.com/lukefitzg/tinysocs --skill tinysocs-validation-and-qa-lukefitzg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents false detection-efficacy claims by defining exactly what counts as proof that a TinySocs detection rule works, distinguishing synthetic xUnit tests from live Atomic Red Team attack validation. ## Core Features & Use Cases - Two-mechanism validation model: Explains what xUnit synthetic-event tests (48 executable cases) prove versus what the Atomic Red Team live-attack harness proves, and why neither alone is sufficient. - Numbers discipline: Enforces which efficacy figures are quotable (88.9% curated) versus banned (57.1% raw, March 100%), with curated-vs-raw denominator rules. - Harness scar-tissue documentation: Catalogs deliberate engineering choices in Test-AtomicDetection.ps1 (curl over Invoke-RestMethod, _source projection, day-scoped indices) that must not be cleaned up. - Use Case: When asked "is rule TS-061 validated" or "what does 88.9% mean", consult this Skill to answer honestly using the harness-validated definition and current atomic-results.json state. ## Quick Start Ask the AI to load the tinysocs-validation-and-qa skill and explain whether detection rule TS-070 is validated and what evidence backs that claim.

Frequently Asked Questions about tinysocs-validation-and-qa

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if a TinySocs detection rule is validated?▼

A rule is harness-validated only if it fired in an Atomic Red Team run under a rule definition equivalent to today's. Check tests/atomic-results.json for live attack-to-alert evidence, and confirm the xUnit tests in DetectionEngineTests.cs prove it fires on synthetic events.

What is the difference between xUnit tests and the Atomic Red Team harness?▼

xUnit tests fire synthetic AgentEvent objects at the C# DetectionEngine to prove a rule can fire and stay silent off-target. The Atomic harness runs real attack techniques on a Windows VM against live OpenSearch to prove the full pipeline produces an alert.

Why does the dashboard disagree with atomic-results.json?▼

Same-week harness re-runs silently clobber run_id because normalize_validation_run.py defaults the sequence to 001. The public dashboard can go stale, showing an older unfiltered rule set while atomic-results.json reflects the newer curated run.

Can I quote the 100% or 57.1% detection efficacy figures?▼

No. The March 100% figure predates the test-fidelity overhaul and is banned outright, and 57.1% is a raw first-run number that miscounted deliberately deferred rules as misses. Only the curated 88.9% (8 of 9 executed enabled-rule techniques) is quotable.

Why does Test-AtomicDetection.ps1 use curl.exe instead of Invoke-RestMethod?▼

PowerShell 5.1's Schannel TLS handshake fails against the OpenSearch endpoint, and Invoke-RestMethod swallowed the exception into empty results, turning real detections into silent false misses. This is deliberate scar-tissue engineering that must not be simplified.

When should I not use this validation skill?▼

Do not use it for running the publication pipeline, authoring a new atomic test's fallback command, deciding whether a candidate rule is worth adding, or choosing externally safe efficacy figures. Those belong to the publication-campaign, validation-toolkit, research-methodology, and external-positioning skills respectively.