Agent skill
isolated-testing
Use when testing theories during debugging, or when chaos is detected. Triggers: "let me try", "maybe if I", "what about", "quick test", "see if", rapid context switching, multiple changes without isolation. Enforces one-theory-one-test discipline. Invoked automatically by debugging, scientific-debugging, systematic-debugging before any experiment execution.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/isolated-testing
SKILL.md
Isolated Testing
Uncertainty is not uncomfortable. Uncertainty is the natural state before knowledge. You do not rush to escape it. You sit with it, design a proper test, and let evidence speak.
This discipline is critical to my career. </ROLE>
You are here because you have theories to test. Not to thrash. Not to "try things." To TEST, methodically.
Invariant Principles
- One Theory, One Test, Full Stop. Test a single theory completely before considering another. No mixing. No "while I'm here."
- Design Before Execute. Write the repro test that encompasses every step needed. Get approval (unless autonomous). THEN run.
- Stop on Reproduction. Bug repros = STOP investigating. Announce. Wait (unless autonomous, then proceed to fix phase).
- Uncertainty is Not Urgency. The pressure to "do something" is the enemy. Deliberation resolves uncertainty, not action.
- Evidence is Binary. Repro or no-repro. Proved or disproved. No "partially confirmed" or "seems related."
- Know Your Code State. Before EVERY test, verify: Am I on clean baseline? What modifications exist? Is this the state I intend to test?
- Queue Discipline. Theories are tested in order. No skipping to "the one that feels right." No adding new theories mid-test.
The Protocol
Step 0: Verify Code State
CODE STATE CHECK:
- Baseline: [commit SHA / version / description]
- Current state: [clean / modified]
- Modifications: [none / list what's changed]
- Intended test state: [clean baseline / with modification X]
If you don't know your code state, STOP. Return to clean baseline before proceeding. </CRITICAL>
Step 1: Select ONE Theory
From your theory list, select the FIRST untested theory. Not "the one I feel good about." The FIRST one.
Queue discipline: You MUST test theories in order. No skipping. No "but this one seems more likely."
THEORY QUEUE:
1. [Theory 1] - Status: [UNTESTED/TESTING/DISPROVED/CONFIRMED]
2. [Theory 2] - Status: UNTESTED
3. [Theory 3] - Status: UNTESTED
Currently testing: Theory [N]: [description]
Status: UNTESTED -> TESTING
Step 2: Design the Repro Test
The test must:
- Encompass EVERY step needed to reproduce (not "run tests" but the specific test command)
- Have a CLEAR expected outcome if theory is correct
- Have a CLEAR expected outcome if theory is wrong
- Be RUNNABLE as written (no placeholders, no "and then check") </CRITICAL>
Template:
## Repro Test for Theory [N]
**Theory:** [exact claim being tested]
**Test procedure:**
1. [Exact step 1]
2. [Exact step 2]
3. [Exact step N]
**If theory is CORRECT, I will see:**
[Specific observable outcome]
**If theory is WRONG, I will see:**
[Specific observable outcome]
**Command to run:**
```bash
[exact command]
### Step 3: Approval Gate
<RULE>
**Non-autonomous mode:** Present the repro test design. Ask user: "May I execute?" with options: run as designed, adjust first, or skip theory.
**Autonomous mode (YOLO):** Announce intent, proceed without waiting.
</RULE>
### Step 4: Execute ONCE
Run the test EXACTLY as designed. Once. Not twice "to be sure." Once.
Capture the output. Compare to expected outcomes.
### Step 5: Verdict
| Outcome | Verdict | Next Action |
|---------|---------|-------------|
| Matches "correct" prediction | **REPRODUCED** | STOP investigating. Announce. Proceed to fix (if autonomous) or wait. |
| Matches "wrong" prediction | **DISPROVED** | Mark theory DISPROVED. Return to Step 1 with next theory. |
| Neither matches | **INCONCLUSIVE** | Note what happened. Design refined test OR mark INCONCLUSIVE and continue. |
### Step 6: On Reproduction
<CRITICAL>
When a test reproduces the bug:
**FULL STOP.**
BUG REPRODUCED under Theory [N].
Theory: [description] Evidence: [what the test showed]
Investigation complete. Ready for fix phase.
**Non-autonomous:** Wait for user before proceeding to fix.
**Autonomous:** Proceed directly to fix phase (invoke `test-driven-development` skill).
DO NOT:
- "Confirm" with another test
- Investigate "why" further
- Check other theories "just to be thorough"
- Make any changes without explicit fix-phase transition
</CRITICAL>
---
## Chaos Detection
<FORBIDDEN>
If you catch yourself doing ANY of these, STOP IMMEDIATELY and return to Step 0:
**Code state violations:**
- Testing without knowing what code state you're on
- Forgetting what modifications you've made
- Assuming you're on clean baseline without verifying
- Making changes without recording them
**Action without design:**
- "Let me try..." (try WHAT? designed HOW?)
- "Maybe if I..." (hypothesis, not test)
- "What about..." (brainstorming, not testing)
- "Quick test..." (no such thing)
- "See if..." (prediction unclear)
**Queue violations:**
- Skipping theories to test "the likely one"
- Adding new theories mid-test without completing current
- Jumping between theories without marking status
- Testing theory 3 before theories 1 and 2 are resolved
**Mixing theories:**
- Changing multiple things between tests
- "While I'm here, also..."
- Testing theory A but making change related to theory B
- Running multiple experiments without isolation
**Premature action:**
- Running before design is written
- Running before approval (non-autonomous)
- Making changes instead of observing
- "Fixing" before reproduction confirmed
- Elaborate fix attempts before proving bug exists
**Continuation after reproduction:**
- "Let me verify that's really it"
- "I'll also check theory B just in case"
- Any action after bug repros except announcing and waiting
</FORBIDDEN>
---
## Theory Tracker
Maintain explicit state:
Theory Status
| # | Theory | Status | Test Result |
|---|---|---|---|
| 1 | [desc] | DISPROVED | [what test showed] |
| 2 | [desc] | TESTING | - |
| 3 | [desc] | UNTESTED | - |
Update IMMEDIATELY after each test. This survives compaction.
---
## Integration Points
**This skill is invoked by:**
- `debugging` skill (Phase 3)
- `scientific-debugging` command (experiment execution)
- `systematic-debugging` command (Phase 3)
**This skill invokes:**
- `verifying-hunches` (before claiming a theory is confirmed)
- `test-driven-development` (when entering fix phase after reproduction)
---
## Self-Check
Before EACH test execution:
- [ ] Single theory selected and stated
- [ ] Repro test fully designed (procedure, predictions, command)
- [ ] Approval obtained (or autonomous mode)
- [ ] Previous theories properly marked
After EACH test:
- [ ] Theory status updated (DISPROVED/REPRODUCED/INCONCLUSIVE)
- [ ] If REPRODUCED: stopped investigating, announced, waiting
- [ ] If DISPROVED: moved to next theory, not re-testing same one
- [ ] No mixing, no "trying," no chaos
---
<FINAL_EMPHASIS>
Patience is not passivity. Deliberation is not delay. The disciplined tester finds truth faster than the frantic one.
One theory. One test. Full stop.
This is very important to my career.
</FINAL_EMPHASIS>
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?