create-test-plan

Name: create-test-plan
Author: tobihagemann

3installs29forks

How to install create-test-plan?

tobihagemann/turbo/create-test-plan

$npx -y skills add tobihagemann/turbo --skill create-test-plan

Installs into the current project.

Summary

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 sho

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type

create-test-plan

3installs29forks

View on GitHub

How to install create-test-plan?

tobihagemann/turbo/create-test-plan

$npx -y skills add tobihagemann/turbo --skill create-test-plan

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type