Generate a four-level test plan at .turbo/test-plans/[slug].md from what changed. Use when the user asks to \"create a test plan\", \"what should I test\", \"list test cases\", or \"test plan for this
1---2name: create-test-plan3description: Generate a four-level test plan at .turbo/test-plans/[slug].md from what changed. Use when the user asks to…4---56# claude/skills/create-test-plan/SKILL.md
C
SKILL.mdAgent skill
Transport
File
Status
Listed
SKILL.md
Install
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
shterminal
1npx skills add tobihagemann/turbo --skill create-test-plan -a cursor -y
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
Generate a four-level test plan at .turbo/test-plans/[slug].md from what changed. Use when the user asks to \"create a test plan\", \"what should I test\", \"list test cases\", or \"test plan for this PR\".
FAQ
Questions
Publisher
Updated
2026-11-12
Stars
420
Agents
3
Categories
1
How do I install create-test-plan?
Download claude/skills/create-test-plan/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does create-test-plan live?
The publisher keeps it at https://github.com/tobihagemann/turbo.
Which agents can use create-test-plan?
Claude, Cursor, Codex, and Grok Build can read a SKILL.md you add from the publisher's repository. Grok Bot installs it when you send the skill's GitHub folder link in a chat.
From the publisher
SKILL.md
name
create-test-plan
description
Generate a four-level test plan at .turbo/test-plans/[slug].md from what changed. Use when the user asks to \"create a test plan\", \"what should I test\", \"list test cases\", or \"test plan for this PR\".
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.
If the resolved scope spans more than one git branch and the user named no single branch, cover each of them instead of only the branch currently checked out. Include scenarios that exercise them together where the branches can be combined in the working tree the plan's executor will have, and state the required branch state in each such scenario's steps.
Step 2: 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, unless the scope changes a check's configuration; then use direct terminal execution for that part of the scope
Step 3: Resolve the Output Path
Pick a slug for the test plan from the change under test:
Lowercase
Replace non-alphanumeric characters with hyphens
Collapse consecutive hyphens
Trim leading and trailing hyphens
Truncate to 40 characters at a word boundary
If the work is anchored to an existing plan at .turbo/plans/<slug>.md, reuse that plan's slug verbatim.
The user may pass an explicit slug or output path; honor it.
Resolve a collision at .turbo/test-plans/<slug>.md by how the slug was chosen. A slug generated from the change under test takes -2, -3, and so on until the path is free; do not overwrite. For a slug reused from an anchoring artifact, use AskUserQuestion to offer overwrite or a different slug, since a numeric suffix would break its pairing with that artifact. For a slug or path the user supplied, use AskUserQuestion to offer overwrite, a numeric suffix, or a different slug.
State the chosen slug and the resulting test plan path before continuing.
Step 4: 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 5: 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.
Confirm a scenario's starting state can be reached before writing it. When a precondition depends on a system the executor does not control (another team's service, an external platform), confirm a write path for it exists. Where the write path is uncertain or absent, write the scenario so it names what to attempt and what to record when the attempt fails.
Confirm any control, command, or other affordance a scenario names exists in the code before writing the scenario: search for the API that would implement it rather than inferring it from what the feature does. Where it cannot be confirmed, write the scenario against the outcome to verify and leave the executor to find the affordance.
When a scenario claims an affordance is available in a state, make each such affordance's first observable effect in that state the expected outcome. For an affordance whose effect is not cleanly undoable, write the scenario to stop at its confirmation step and cancel it, or, when the affordance has none, to act on a record the executor creates for the scenario.
When a scenario's pass condition is that nothing happens — no write, no call, no state change — pair it with a control that differs only in the dimension under test and whose expected outcome is that the effect does occur, since a lone negative scenario cannot distinguish the behavior under test from a harness that never reached it. When such a scenario injects a crafted payload, establish that the payload satisfies every validation layer between the injection point and the code under test, and state which layers the trace cannot settle: a payload rejected at a parse boundary produces the expected absence for the wrong reason. When the guard it targets rejects a repeat invocation, establish that the affordance the scenario drives can be invoked a second time, and name an entry point carrying no busy or pending state when the primary one has it: a repeat the entry surface refuses never reaches the guard.
When the scope changes a check's configuration (linter, formatter, type checker, or CI gate rules), write that part's scenarios against the check itself and list direct terminal execution for them in the plan's Approach. Cover each changed rule with a scenario that exports the tree carrying the change to a scratch directory outside the checkout, adds input there that the rule should flag or accept, and runs the check on it, reaching the check's installed toolchain and plugins without installing into or modifying the checkout. Pair each with the same input under the configuration as it stood before the change as its control, naming that ref in the scenario's steps and writing that configuration into the exported tree beside the configuration it stands in for, so a verdict the old configuration also produces is not credited to the change. Include in each expected outcome that every run, the control included, processed a nonzero number of inputs, and state that a run processing none calls for fixing its setup and rerunning, and is inconclusive only when no fix gets the check to process any input. When the change adds or narrows a suppression and the check reports unused suppressions, add a scenario with the suppressed cause removed whose expected outcome is the stale-suppression report.
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
An action re-applied to its own output, checked against what the feature intends on the second application
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 6: Present and Write
Output the plan as text. Then use AskUserQuestion to ask for approval before writing.
Create .turbo/test-plans/ if it does not exist. Write the plan to .turbo/test-plans/<slug>.md using this format:
