openplan-test

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.
5. Choose the smallest layer set that can exercise the risk.
6. 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.
7. 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.
8. Keep the fix minimal relative to the proven test. Do not add abstractions only because the test exists.
9. Report checks run, checks skipped, why skipped, and what confidence each check actually supports.
10. 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.