09.03.08 — State skill#

A single skill: question-state. Interrogates the environment before believing a result.

The skill#

input  : a surprising result ("the test fails")
output : a series of questions about state:
            - which browser are we running on?
            - which commit?
            - is the SUT warm or cold?
            - is Redis available?
            - what's the configured wait-timeout?
            - what's the driver version?
            - does ChromeDriver have its password-manager-off fix?
            - is this an isolated run or a parallel run?
            - are other tests touching the same SUT resources?

Approach#

CLAUDE.md:

Don’t propagate a previous run’s diagnosis without re-deriving it.

Logs, screenshots, and prior comments describe a past failure. For a current failure, treat them as hypotheses to test, not conclusions to inherit. Re-derive the cause from this run’s evidence (current screenshot, current network response, current PHP) before reaching for the previously-tried fix. One extra check is cheap; stacking workarounds on a wrong diagnosis is what ends in a reboot.

question-state is the ritual that forces this re-derivation. It can also be supplemented by environment knowledge:

  • Are there stubs?
  • What isn’t ISO Prod?

Example#

USER : "the login test fails, is it Chrome BFCache?"
   ↓
CLAUDE (question-state):
   - Which browser?  → Chrome
   - Which failing test? → "valid_login" (smoke gate)
   - BFCache concerns post_logout_*, not valid_login → hypothesis rejected
   - Which commit?  → main branch latest
   - Is ChromeDriver password-manager-off active? → check create_drivers_pool
   - Is the SUT (CURA) "warm"?
   - Did the test retry? → check logs
   - How many tries? → if > 5, transient; if 1, real defect
   ↓
REVISED HYPOTHESIS: maybe A-ENV-2 if the custom adapter was removed

State, not legend#

Don’t trust a failure because “we’ve seen it fail like that before.” Re-acquire the current state.

CLAUDE.md details why this is crucial:

  • Workarounds based on assumptions pile up silently.
  • Each bad diagnosis adds technical debt.
  • Eventually: a stack of patches that fixes nothing.

Cross-cutting discipline#

This skill is often invoked at the start of a debug session:

USER : "run review-report"
   ↓
CLAUDE : (review-report identifies the failing test)
   ↓
CLAUDE : "Before proposing a fix, I'm running question-state..."
   ↓
CLAUDE : (question-state reveals an overlooked detail, e.g. the Heroku warm-up that didn't run)
   ↓
CLAUDE : "The fail is probably A-ENV-1 (cold dyno). Want to re-run with warm-up?"