create-test-plan-ff35c8 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited create-test-plan-ff35c8 (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Analyze what changed and generate a comprehensive test plan covering four escalating levels of testing depth.
Resolve scope using the first match:
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.
Always check for project-specific testing skills or MCP tools first. Use the fallbacks below when nothing project-specific is available:
$agent-browser skill if available, otherwise Codex browser automationcomputer-use MCPPick a slug for the test plan from the change under test:
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 request_user_input 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 request_user_input to offer overwrite, a numeric suffix, or a different slug.
State the chosen slug and the resulting test plan path before continuing.
After identifying scope, read the actual code in depth to understand:
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.
Does the feature work at all? Verify the happy path and the most obvious behavior.
Combine multiple actions in sequence. Verify state consistency across operations.
Actively try to break the feature. Explore boundary conditions and unexpected inputs.
Explore state interactions across system boundaries. These surface the hardest bugs.
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.
Output the plan as text. Then use request_user_input 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:
# Test Plan: <Feature/Change Name>
## Context
<Brief description of what changed and why>
## Approach
<Testing approach: agent-browser / Codex browser automation / 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>Then call update_plan to mark this step completed and continue with the next step of the active workflow.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.