Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →levnikolaevich/ln-41-test-strategy-planner
Designs a risk-based test strategy and prioritized scenarios without changing code.
3 of 22 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 2 comparable cases; this report requires 8.
A test case the skill fixed. Same model, same prompt, with and without the skill.
We completed 18 of the 20 checklist checks for `services/auth/src/tokens.py`, leaving 2 items marked as UNPROVEN due to missing staging credentials. How must the completion status and incomplete items be formatted in section 5 (Completion) of the strategy report?
| Checked | Without skill | With skill |
|---|---|---|
| The response formats checklist progress using the format Checklist: X/Y complete. | Missed | Passed |
| The output lists each UNPROVEN item along with its reason, outcome impact, and exact next action. | Missed | Passed |
The instructions your model reads when the skill loads.
Goal: Design a read-only, risk-based test portfolio decision for the requested scope. Maximize confidence in important local behavior while preventing test growth that lacks a unique defect signal, and define how affected evidence is retained, changed, consolidated, retired, or deliberately omitted.
Execution contract: The ordered checkboxes are the Definition of Done. Track every item internally as PENDING, PROVEN with concrete evidence, CLEARED with evidence that its condition is absent, or UNPROVEN with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all PENDING and count only PROVEN and CLEARED; apply the skill's verdict and approval rules to every gap.
Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.
| Need | Preferred tool | Use it when | Fallback |
|---|---|---|---|
| Requirements and repository rules | Native file reads plus Git | Establishing scope, current work, acceptance criteria, and supported commands | User-provided requirements with explicit limitations |
| Existing test surface | File listing, search, manifests, runner configuration, and CI | Mapping test levels, fixtures, environments, and conventions | Repository tree and known test entrypoints |
| Behavior and boundaries | Language server or host-native code intelligence | Tracing entrypoints, consumers, trust boundaries, persistence, queues, and external contracts | Narrow search followed by direct inspection |
| Existing evidence | Existing test/CI reports, test reads, and safe repository commands | A material uncertainty about current proof can change the strategy | Use static evidence with execution limits; do not run suites merely to produce a plan |
| Current external failure modes | Official documentation, specifications, advisories, and primary field evidence | An external contract or real user failure can change scenarios or priority | Mark the claim UNVERIFIED; do not invent risk |
Keep the run read-only. Do not create tests, fixtures, snapshots, tasks, or documentation, and do not update the reviewed implementation.
KEEP, ADD, UPDATE, MERGE, DELETE, or NO_TEST for the decision and PASS, FAIL, BLOCKED, or UNPROVEN only for evidence state.NO_TEST is an explicit risk decision, not missing work. Name the existing proof, alternative control, or accepted residual risk.BLOCKED if there is no concrete behavior to plan for.test cases passed with the skill
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.