Test Plan Mode
Generate structured test plans. Test Plan analyzes your branch changes and produces manual test cases with steps, expected results, and priorities.
Generate structured test plans.
Test Plan mode analyzes the changes on your branch and produces a structured set of manual test cases. Each case includes the steps to follow, the expected result, and a priority level — ready to hand to a QA team or work through yourself before shipping.
What it does
Test Plan reads the Git diff on your current branch, understands what changed, and derives test cases from the actual code changes. It produces a structured document with specific test scenarios, step-by-step instructions, expected outcomes, and priority levels (High, Medium, Low). The plan is based on real changes — not generic templates.
When to use it
- Before releasing a batch of changes to verify nothing was missed
- When preparing work for manual QA or a QA team handoff
- After a significant feature implementation to define the acceptance criteria
- When you want to verify edge cases that automated tests don't cover
- Before merging a long-running branch with many changes
Run Test Plan after a Feature or Bug agent finishes its work. The agent knows exactly what changed, which makes the generated test cases directly relevant to the implementation.
How it works
- Branch analysis — the agent reads all changes on the current branch compared to the base.
- Change understanding — for each changed file, the agent understands the intent of the change and its potential impact.
- Test case derivation — test scenarios are derived from the changes: happy paths, edge cases, error conditions, and regression checks.
- Test plan structured — each test case is written with a title, preconditions, numbered steps, expected result, and priority.
- Plan delivered — the complete test plan is returned as a structured markdown document.
Key features
- Change-driven — test cases are derived from actual code changes, not generic checklists
- Structured format — each case has title, steps, expected result, and priority (High / Medium / Low)
- Edge case coverage — includes error conditions and boundary cases, not just happy paths
- Ready to use — the plan can be handed directly to a QA engineer or used as a self-test checklist
- Read-only — Test Plan never modifies any files; it only analyzes and generates
Tips
Use Test Plan after Review, not instead of it. Review checks code quality; Test Plan generates the user-facing test scenarios. Both serve different purposes.
High-priority test cases should always be completed before merging. Medium and Low can be deferred based on release constraints.