test-planning
Test Planning
A test plan is a written argument that this feature works — not the tests themselves, but the case for which tests would prove it. Skipping this step is what produces test suites that hit every line of code but miss the failure modes that actually break in production. The line coverage was fine; nobody tested the empty-cart edge case, the second-time-clicked Submit button, or what happens at 11:59:59 on a leap second.
The job of this skill is to turn "this feature is built" into "we have evidence this feature works under the conditions we can articulate and a list of conditions we know we haven't tested." The plan is the artifact; the tests are the implementation.
When to invoke this skill
Use it when:
- A feature has acceptance criteria (ideally a requirements doc at
docs/requirements/<slug>.md) and you need to plan tests against them. - You're about to write tests and you're not sure what's worth writing.
- A bug was reported and you want to expand the test plan to cover the gap and any neighboring ones.
- You're reviewing a PR and want to ask "what's missing from this test coverage?" in a structured way.
- You're handing a feature to QA / manual testing and you need a list of cases.
Skip it when the change is a one-line fix with an obvious single test, or when the feature is small enough that the test plan would be longer than the tests.