OpenPlan Test

Use this after $openplan-core when a task needs test strategy, regression proof, quality evidence, or auto/YOLO verification. Testing is evidence for the human and reviewer; it is not approval.

Core Rule

Tests must answer a risk question. Do not run broad commands just to create confidence theater, and do not claim success when the important risk was not exercised.

When To Use

Use this skill when asked to:

• create or refine a test framework for a project;
• decide which checks are proportional for a change;
• add or evaluate regression tests;
• verify an auto/YOLO implementation before review;
• classify skipped checks and residual risk;
• turn a found bug into a minimal reproducing test;
• compare implementation behavior with fixtures, properties, reference models, or formal/independent oracles.

Do not use it as a substitute for $openplan-review. Passing tests are input to review, not a review result.

Test Flow

1. State the test goal in terms of the human goal/intent and the failure mode being controlled.
2. Load local test instructions, build scripts, CI config, and nearby tests only as needed.
3. Build a test map with references/framework.md: commands, dependencies, privilege/environment needs, skip behavior, failure diagnostics, and CI/release treatment.
4. Identify test layers:

• fast local checks;
• safety/sanitizer/adversarial checks;
• integration or environment-touching checks;
• end-to-end checks;
• oracle, property, metamorphic, fixture, or corpus checks.

1. Choose the smallest layer set that can exercise the risk.
2. For every new or changed regression test, prove it is real:

• it fails against the old behavior, baseline, or bug-reproducing fixture;
• it passes against the candidate fix;
• if direct baseline execution is impossible, state the equivalent proof and residual uncertainty.

1. Check for self-deception risks: decorative tests, weak assertions, silent skips, golden files generated by the same code under test, and tests present but not wired into the runner.
2. Keep the fix minimal relative to the proven test. Do not add abstractions only because the test exists.
3. Report checks run, checks skipped, why skipped, and what confidence each check actually supports.
4. Route results:

• implementation issue -> bounded fix task if explicitly authorized;
• review evidence -> $openplan-review;
• durable lesson or testing convention -> $openplan-record;
• broad docs/test framework docs -> $openplan-garden;
• continuation risk -> $openplan-handoff.

Regression Test Reality Rule

A regression test that has not been shown to fail on the buggy behavior is provisional. Mark it as unproven regression coverage instead of calling it proven.

When the test depends on symbols introduced by the fix, construct an equivalent baseline-side test, fixture, trace, property, or oracle comparison that exercises the old failure mode.

Auto/YOLO Rules

• Prefer bounded, non-destructive checks.
• Do not require privileged, destructive, flaky, or expensive checks silently; report them as skipped with impact.
• Do not turn test pass/fail into merge, release, approval, or risk-acceptance decisions.
• If a key check is unavailable, report BLOCKED or HUMAN_DECISION_REQUIRED according to whether the missing item is evidence or a human choice.
• In auto mode, finish with a test evidence report, not "all good."

Output

Use references/output-contract.md for the report shape. Optionally validate a Markdown report:

python3 scripts/validate_test_report.py <report.md>

References

• references/framework.md: portable test layer framework.
• references/output-contract.md: report shape.
• assets/claude-code-command.md: Claude Code command/prompt seed.