AgentStack
SKILL verified MIT Self-run

Exp Lens Severity Testing

skill-trecek-useful-claude-skills-exp-lens-severity-testing · by Trecek

Analyze severity of experimental tests — adversarial cases, negative controls, falsification tests, easy-pass detection, and confirmatory theater. Falsificationist lens answering "Would this design have caught the error?

No reviews yet
0 installs
2 views
0.0% view→install

Install

$ agentstack add skill-trecek-useful-claude-skills-exp-lens-severity-testing

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Exp Lens Severity Testing? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Severity Testing Experimental Design Lens

Philosophical Mode: Falsificationist Primary Question: "Would this design have caught the error?" Focus: Adversarial Cases, Negative Controls, Falsification Tests, Easy-Pass Detection, Confirmatory Theater

When to Use

  • Evaluating whether positive results are meaningful or trivially achievable
  • Checking for adversarial robustness of experimental conclusions
  • User invokes /exp-lens-severity-testing or /make-experiment-diag severity

Critical Constraints

NEVER:

  • Modify any source code files
  • Do not litter the codebase with useless comments, TODO markers, or explanatory annotations — the skill output and diagram speak for themselves
  • Accept a "pass" result without asking what a false result would have looked like under this design

ALWAYS:

  • For every positive claim, identify what error the test was capable of detecting
  • Inventory negative controls and sanity checks explicitly — their absence is a finding
  • Rate severity before reporting conclusions, not after
  • Flag confirmatory theater: experiments designed to confirm rather than risk refutation
  • BEFORE creating any diagram, LOAD the /mermaid skill using the Skill tool - this is MANDATORY

Analysis Workflow

Step 1: Launch Parallel Exploration Subagents

Spawn Explore subagents to investigate:

Positive Results Claimed

  • Find all positive claims and statistically significant results
  • Identify the conclusions drawn from each positive finding
  • Look for: significant, improves, outperforms, better, wins, advantage, novel

Negative Controls & Sanity Checks

  • Find tests designed to fail or baseline sanity checks
  • Identify whether any test was included specifically to validate the measurement apparatus
  • Look for: negative_control, sanity, baseline, random, null, ablation, placebo

Adversarial Conditions

  • Find testing under hostile, edge-case, or boundary conditions
  • Identify whether the experiment was exposed to conditions that would stress its assumptions
  • Look for: adversarial, worst_case, edge, corner, stress, boundary, failure

Alternative Explanations Tested

  • Find whether the experiment actively tries to rule out alternative explanations
  • Identify confound checks, artifact controls, and leakage tests
  • Look for: alternative, confound, artifact, spurious, leakage, bias, explain

Prediction Specificity

  • Find how specific the predictions are that the data is claimed to support
  • Identify whether predictions were directional, magnitude-specific, or vague
  • Look for: predict, expect, hypothesis, specific, precise, direction, magnitude

Step 2: Assess Severity for Each Claim

For each positive claim, answer:

  1. What specific errors was this test capable of detecting?
  2. How easily could the claim pass if it were actually wrong?
  3. Were negative controls included to validate the measurement apparatus?
  4. Were adversarial conditions tested?
  5. Is the "pass" informative or trivially achievable by any plausible intervention?

Step 3: Rate Severity and Identify Gaps

CRITICAL — Analyze Test Severity: For every "pass" the experiment reports:

  • What would a false result have looked like under this design?
  • Was the test sensitive enough to distinguish genuine from artifactual success?
  • Was there any test that could have falsified the claim but was not included?

Severity ratings:

  • HIGH: The test would almost certainly have detected the error if the claim were false
  • MEDIUM: Reasonable chance the test would have detected the error
  • LOW: The test could easily have passed even if the claim were false — result is not informative

Flag as confirmatory theater when: the design was structured to confirm an expected result, the positive finding was predictable regardless of true effect, and no test was included that risked refuting the hypothesis.

Step 4: Create Optional Severity-Flow Diagram

This lens is primarily argumentative. An optional severity-flow diagram may be added to show how claims flow through severity assessment to verdicts.

Direction: TB (claims flow through severity assessment to verdicts)

Node Styling:

  • cli class: Claims and positive results
  • detector class: High-severity tests (would have caught the error)
  • handler class: Medium-severity tests (reasonable chance)
  • gap class: Low-severity or untested claims
  • output class: Severity verdicts

Step 5: Write Output

Write the analysis to: temp/exp-lens-severity-testing/exp_diag_severity_testing_{YYYY-MM-DD_HHMMSS}.md


Output Template

# Severity Testing Analysis: {System / Experiment Name}

**Lens:** Severity Testing (Falsificationist)
**Question:** Would this design have caught the error?
**Date:** {YYYY-MM-DD}
**Scope:** {What was analyzed}

## Severity Assessment

| Claim | Test Applied | Severity Rating | What Would Failure Look Like? |
|-------|-------------|----------------|------------------------------|
| {claim} | {test used} | {HIGH / MEDIUM / LOW} | {what a false positive would have looked like} |

## Negative Control Inventory

| Control | Purpose | Present? | Notes |
|---------|---------|----------|-------|
| {control name} | {what it validates} | {yes / no / partial} | {finding if absent} |

## Adversarial Gap Analysis

| Condition | Tested? | Risk if Untested |
|-----------|---------|-----------------|
| {adversarial condition} | {yes / no} | {what failure mode is left undetected} |

## Easy-Pass Detector

Claims that could be true for trivial reasons — passing the test does not distinguish genuine from artifactual success:

| Claim | Why It Is an Easy Pass | Strengthening Test Needed |
|-------|----------------------|--------------------------|
| {claim} | {mechanism of trivial pass} | {what harder test would distinguish} |

## Confirmatory Theater Flags

{List any experiment components that appear designed to confirm rather than risk refutation, or "None detected."}

- **Flag**: {description of theater pattern}
  - **Evidence**: {what makes this look confirmatory rather than genuinely falsifiable}
  - **Remedy**: {what adversarial test would make this falsifiable}

## Optional Severity-Flow Diagram

```mermaid
%%{init: {'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50, 'curve': 'basis'}}}%%
flowchart TB
    %% CLASS DEFINITIONS %%
    classDef cli fill:#1a237e,stroke:#7986cb,stroke-width:2px,color:#fff;
    classDef stateNode fill:#004d40,stroke:#4db6ac,stroke-width:2px,color:#fff;
    classDef handler fill:#e65100,stroke:#ffb74d,stroke-width:2px,color:#fff;
    classDef phase fill:#6a1b9a,stroke:#ba68c8,stroke-width:2px,color:#fff;
    classDef newComponent fill:#2e7d32,stroke:#81c784,stroke-width:2px,color:#fff;
    classDef output fill:#00695c,stroke:#4db6ac,stroke-width:2px,color:#fff;
    classDef detector fill:#b71c1c,stroke:#ef5350,stroke-width:2px,color:#fff;
    classDef gap fill:#ff6f00,stroke:#ffa726,stroke-width:2px,color:#000;
    classDef integration fill:#c62828,stroke:#ef9a9a,stroke-width:2px,color:#fff;

    subgraph Claims ["POSITIVE CLAIMS"]
        C1["Claim 1━━━━━━━━━━{stated conclusion}"]
        C2["Claim 2━━━━━━━━━━{stated conclusion}"]
    end

    subgraph HighSev ["HIGH-SEVERITY TESTS"]
        HS1["Adversarial Test━━━━━━━━━━would detect false claim"]
        HS2["Negative Control━━━━━━━━━━validates apparatus"]
    end

    subgraph MedSev ["MEDIUM-SEVERITY TESTS"]
        MS1["Sanity Check━━━━━━━━━━reasonable detection chance"]
    end

    subgraph LowSev ["LOW-SEVERITY / UNTESTED"]
        LS1["Easy-Pass Test━━━━━━━━━━trivially achievable"]
        LS2["Untested Condition━━━━━━━━━━gap in coverage"]
    end

    subgraph Verdicts ["SEVERITY VERDICTS"]
        V_HIGH["HIGH Severity━━━━━━━━━━informative pass"]
        V_MED["MEDIUM Severity━━━━━━━━━━partial confidence"]
        V_LOW["LOW Severity━━━━━━━━━━uninformative pass"]
    end

    C1 --> HS1
    C1 --> MS1
    C2 --> HS2
    C2 --> LS1
    C2 -.->|"not tested"| LS2

    HS1 --> V_HIGH
    HS2 --> V_HIGH
    MS1 --> V_MED
    LS1 --> V_LOW
    LS2 --> V_LOW

    class C1,C2 cli;
    class HS1,HS2 detector;
    class MS1 handler;
    class LS1,LS2 gap;
    class V_HIGH,V_MED,V_LOW output;

Color Legend: | Color | Category | Description | |-------|----------|-------------| | Dark Blue | Claims | Positive claims and conclusions under evaluation | | Red | High Severity | Tests that would reliably detect a false claim | | Orange | Medium Severity | Tests with a reasonable chance of detection | | Yellow | Low Severity | Easy-pass tests or untested gaps | | Dark Teal | Verdicts | Severity verdict assigned to each claim |


---

## Pre-Diagram Checklist

Before creating the diagram, verify:

- [ ] LOADED `/mermaid` skill using the Skill tool
- [ ] Using ONLY classDef styles from the mermaid skill (no invented colors)
- [ ] Diagram will include a color legend table

---

## Related Skills

- `/make-experiment-diag` - Parent skill for experimental lens selection
- `/mermaid` - MUST BE LOADED before creating diagram
- `/exp-lens-error-budget` - For quantifying the statistical error tolerances of each test
- `/exp-lens-validity-threats` - For cataloguing validity threats that undermine the claims

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Trecek](https://github.com/Trecek)
- **Source:** [Trecek/useful-claude-skills](https://github.com/Trecek/useful-claude-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.