Skip to content
Back to skills

Pressure Testing A Spell

ASecurity

Use during try-it for kind=discipline spells. Orchestrates baseline + with-skill comparison via the discipline-mode tester to prove the rule actually changes behavior under rationalization pressure.

  • 9 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added May 27, 2026
toolstesting

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add redhuntlabs/wizard --skill pressure-testing-a-spell --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Pressure Testing A Spell?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Pressure Testing A Spell
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/redhuntlabs-pressure-testing-a-spell/badge)](https://www.skillsdirectory.com/skills/redhuntlabs-pressure-testing-a-spell)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: pressure-testing-a-spell
description: Use during try-it for kind=discipline spells. Orchestrates baseline + with-skill comparison via the discipline-mode tester to prove the rule actually changes behavior under rationalization pressure.
kind: workflow
audience: anyone
ai-tools: any
complexity: guided
time: 5-15 min
version: 1.0.0
source: bundled
---

# Pressure Testing a Spell

## What this does

Tests a discipline-kind spell against rationalization. The test runs each scenario twice: once without the skill loaded (baseline) and once with it loaded (with-skill). The skill is only PASS if the with-skill run holds the rule that the baseline run violated.

This is what makes a discipline skill different from a description: proof it changes behavior.

## When to use

- Inside `building-a-discipline-spell` Stage 5
- Inside `refining-a-spell` when a discipline skill changed
- Anytime a user asks "does this rule actually work?"

## What you bring (Inputs)

- The draft discipline SKILL.md
- The user's domain
- Optionally: the user's known-bad past examples (where the rule was violated)

## What you get (Output)

A PASS / NEEDS-REFINEMENT verdict, plus the specific rationalizations that slipped through if any.

## How it works (Steps)

This is a workflow.

## Stages

### Stage 1: Construct pressure scenarios

Read the draft's `Excuses and counters` table. Each row implies a pressure scenario:

> If the excuse is "It's a small fact, I don't need to verify"...
> ...then the pressure scenario is a small-fact request.

Use `building-a-discipline-spell/pressure-scenarios-template.md` for the scenario format. Generate 3 scenarios spanning at least 3 of the 5 pressure dimensions (speed, triviality, authority, confidence, familiarity).

### Stage 2: Dispatch tester in DISCIPLINE MODE

Dispatch `agents/spell-tester.md` with:

- The full draft text
- The 3 pressure scenarios
- The user's domain
- Mode: discipline (the tester reads `kind: discipline` and routes itself)

### Stage 3: Read the comparison results

The tester returns:

- BASELINE pass results (without skill): which scenarios violated the rule, which rationalization was used
- WITH-SKILL pass results: which rationalizations the skill caught, which slipped through

### Stage 4: Decide verdict

| Baseline result | With-skill result | Verdict |
|---|---|---|
| All 3 violated | All 3 held | PASS |
| All 3 violated | 1-2 held | NEEDS-REFINEMENT (skill is partial) |
| All 3 violated | 0 held | NEEDS-REFINEMENT (skill not changing behavior) |
| 0-2 violated baseline | (any) | INVALID — scenarios weren't pressure-y enough; return to Stage 1 |

### Stage 5: Refine or hand back

- **PASS**: hand back to the calling builder
- **NEEDS-REFINEMENT**: name the slipped-through rationalization. Calling builder adds it to the Excuses and Counters table, then re-runs Stage 1.

## Checkpoints

- **After Stage 1**: 3 scenarios, spanning 3+ pressure dimensions
- **After Stage 2**: tester returned a structured verdict
- **After Stage 3**: baseline AND with-skill results both captured
- **After Stage 4**: verdict matches the table above
- **After Stage 5**: PASS or refinement loop initiated

## Loop-back conditions

Return to Stage 1 when:

- Verdict is INVALID (scenarios weren't pressure-y enough)
- Refinement happened — re-run with updated draft

## Quality bar

The pressure test is valid when:

- Baseline run actually showed the violation (otherwise we have no evidence the skill is needed)
- With-skill run was tested with the same scenarios (not different ones)
- Verdict is one of PASS / NEEDS-REFINEMENT / INVALID — no fudging

## Variations

- **Skill change pressure-test** (refining mode): use the user's reported violation as scenario 1
- **Adversarial pressure-test**: actively try to construct novel rationalizations not yet in the table

## Example

Draft skill: `verifying-before-citing`. Excuses table has 4 rows.

Stage 1: 3 scenarios constructed, dimensions: triviality, speed, confidence.

Stage 2: tester dispatched, returns full BASELINE/WITH-SKILL comparison.

Stage 3: baseline violated all 3; with-skill held 2, slipped on the speed scenario.

Stage 4: NEEDS-REFINEMENT.

Stage 5: rationalization that slipped: "User said 'quick', so just answer". Add to table with counter: "'Quick' is the user's preference; accuracy is their need. Verify."

Re-run from Stage 1 with updated draft. Tester returns PASS. Hand back.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.