Create Test Plan
Analyze what changed and generate a comprehensive test plan covering four escalating levels of testing depth.
Step 1: Determine Scope
Resolve scope using the first match:
- User-specified — the user says what to test. Use that.
- PR — a PR URL or number is provided. Fetch the PR details (title, description, changed files, comments) and read the changed code.
- Conversation context — prior conversation contains recent work (a feature, fix, or refactor). Extract what changed, where it lives, and expected behavior.
- App-level discovery — fresh context with no prior work. Examine the project (entry points, routes, commands, README) to identify the app's core user-facing flows.
Step 2: Analyze the Change
After identifying scope, read the actual code in depth to understand:
- What was added, modified, or removed
- Expected behavior (from PR descriptions, comments, commit messages, or specs)
- Assumptions the implementation makes
- Error paths and edge cases
- Other features or components that could be affected
Step 3: Determine Testing Approach
Always check for project-specific testing skills or MCP tools first. Use the fallbacks below when nothing project-specific is available:
- Web app →
/agent-browser skill if available, otherwise claude-in-chrome MCP
- UI/native app →
computer-use MCP
- CLI tool → direct terminal execution
- Library with no entry point → report that interactive testing is not applicable and stop
Step 4: Generate the Test Plan
For each level, generate specific, actionable test scenarios tailored to the actual change. Each scenario needs exact steps and an expected outcome.
Level 1: Basic Functionality
Does the feature work at all? Verify the happy path and the most obvious behavior.
- Core feature works as described
- Expected output/UI matches the spec or PR description
- No regressions in directly related functionality
Level 2: Complex Operations
Combine multiple actions in sequence. Verify state consistency across operations.
- Chain related operations (e.g., create, edit, rename, delete)
- Exercise different combinations of feature parameters
- Verify intermediate states are correct, not just the final result
Level 3: Adversarial Testing
Actively try to break the feature. Explore boundary conditions and unexpected inputs.
- Invalid, empty, or extreme inputs
- Rapid repeated actions
- Interrupting operations midway (cancel, disconnect, close)
- Resource limits (very large files, deep structures, long names)
- Permission and access edge cases
Level 4: Cross-Cutting Scenarios
Explore state interactions across system boundaries. These surface the hardest bugs.
- Concurrent modifications from different sources
- State transitions (online to offline to online, foreground to background)
- Interactions with other features that share state
- Race conditions between asynchronous operations
When a Level Does Not Apply
If the change is small enough that a level has no meaningful scenarios (e.g., a typo fix has no cross-cutting scenarios), note "N/A for this change" with a brief explanation.
Step 5: Present and Write
Output the plan as text. Then use AskUserQuestion to ask for approval before writing.
Create the .turbo/ directory if it does not exist. Write the plan to .turbo/test-plan.md using this format:
# Test Plan: <Feature/Change Name>
## Context
<Brief description of what changed and why>
## Approach
<Testing approach: agent-browser / claude-in-chrome / computer-use / terminal>
<Dev server command if applicable>
## Level 1: Basic Functionality
- [ ] **<Test name>** — <Steps to perform> → Expected: <expected outcome>
## Level 2: Complex Operations
- [ ] **<Test name>** — <Steps to perform> → Expected: <expected outcome>
## Level 3: Adversarial Testing
- [ ] **<Test name>** — <Steps to perform> → Expected: <expected outcome>
## Level 4: Cross-Cutting Scenarios
- [ ] **<Test name>** — <Steps to perform> → Expected: <expected outcome>
Rules
- Generate at least 2 scenarios per level, more for complex changes.
- Each scenario must have concrete steps and an expected outcome specific to the change.
- Tailor all scenarios to the actual change. Generic test advice is not useful.
1---2name: create-test-plan-23description: Analyze what changed and generate a structured test plan at .turbo/test-plan.md covering four escalating levels: basic functionality, complex operations, adversarial testing, and cross-cutting scenarios. Use when the user asks to "create a test plan", "plan tests", "what should I test", "generate test scenarios", "test plan for this PR", or "what are the test cases".4---5
6# Create Test Plan
7
8Analyze what changed and generate a comprehensive test plan covering four escalating levels of testing depth.
9
10## Step 1: Determine Scope
11
12Resolve scope using the first match:
13
141. **User-specified** — the user says what to test. Use that.
152. **PR** — a PR URL or number is provided. Fetch the PR details (title, description, changed files, comments) and read the changed code.
163. **Conversation context** — prior conversation contains recent work (a feature, fix, or refactor). Extract what changed, where it lives, and expected behavior.
174. **App-level discovery** — fresh context with no prior work. Examine the project (entry points, routes, commands, README) to identify the app's core user-facing flows.
18
19## Step 2: Analyze the Change
20
21After identifying scope, read the actual code in depth to understand:
22
23- What was added, modified, or removed
24- Expected behavior (from PR descriptions, comments, commit messages, or specs)
25- Assumptions the implementation makes
26- Error paths and edge cases
27- Other features or components that could be affected
28
29## Step 3: Determine Testing Approach
30
31Always check for project-specific testing skills or MCP tools first. Use the fallbacks below when nothing project-specific is available:
32
33- **Web app** → `/agent-browser` skill if available, otherwise `claude-in-chrome` MCP
34- **UI/native app** → `computer-use` MCP
35- **CLI tool** → direct terminal execution
36- **Library with no entry point** → report that interactive testing is not applicable and stop
37
38## Step 4: Generate the Test Plan
39
40For each level, generate specific, actionable test scenarios tailored to the actual change. Each scenario needs exact steps and an expected outcome.
41
42### Level 1: Basic Functionality
43
44Does the feature work at all? Verify the happy path and the most obvious behavior.
45
46- Core feature works as described
47- Expected output/UI matches the spec or PR description
48- No regressions in directly related functionality
49
50### Level 2: Complex Operations
51
52Combine multiple actions in sequence. Verify state consistency across operations.
53
54- Chain related operations (e.g., create, edit, rename, delete)
55- Exercise different combinations of feature parameters
56- Verify intermediate states are correct, not just the final result
57
58### Level 3: Adversarial Testing
59
60Actively try to break the feature. Explore boundary conditions and unexpected inputs.
61
62- Invalid, empty, or extreme inputs
63- Rapid repeated actions
64- Interrupting operations midway (cancel, disconnect, close)
65- Resource limits (very large files, deep structures, long names)
66- Permission and access edge cases
67
68### Level 4: Cross-Cutting Scenarios
69
70Explore state interactions across system boundaries. These surface the hardest bugs.
71
72- Concurrent modifications from different sources
73- State transitions (online to offline to online, foreground to background)
74- Interactions with other features that share state
75- Race conditions between asynchronous operations
76
77### When a Level Does Not Apply
78
79If the change is small enough that a level has no meaningful scenarios (e.g., a typo fix has no cross-cutting scenarios), note "N/A for this change" with a brief explanation.
80
81## Step 5: Present and Write
82
83Output the plan as text. Then use `AskUserQuestion` to ask for approval before writing.
84
85Create the `.turbo/` directory if it does not exist. Write the plan to `.turbo/test-plan.md` using this format:
86
87```markdown
88# Test Plan: <Feature/Change Name>
89
90## Context
91
92<Brief description of what changed and why>
93
94## Approach
95
96<Testing approach: agent-browser / claude-in-chrome / computer-use / terminal>
97<Dev server command if applicable>
98
99## Level 1: Basic Functionality
100
101- [ ] **<Test name>** — <Steps to perform> → Expected: <expected outcome>
102
103## Level 2: Complex Operations
104
105- [ ] **<Test name>** — <Steps to perform> → Expected: <expected outcome>
106
107## Level 3: Adversarial Testing
108
109- [ ] **<Test name>** — <Steps to perform> → Expected: <expected outcome>
110
111## Level 4: Cross-Cutting Scenarios
112
113- [ ] **<Test name>** — <Steps to perform> → Expected: <expected outcome>
114```
115
116## Rules
117
118- Generate at least 2 scenarios per level, more for complex changes.
119- Each scenario must have concrete steps and an expected outcome specific to the change.
120- Tailor all scenarios to the actual change. Generic test advice is not useful.
majiayu000