ln-41-test-strategy-planner

Name: ln-41-test-strategy-planner
Author: levnikolaevich

520stars73forks

How to install ln-41-test-strategy-planner?

levnikolaevich/claude-code-skills/ln-41-test-strategy-planner

$npx -y skills add levnikolaevich/claude-code-skills --skill ln-41-test-strategy-planner

Installs into the current project.

Summary

Designs a risk-based test strategy and prioritized scenarios without changing code. Use when requirements need a test plan; not for auditing or implementing tests.

Files · 1

View on GitHub

SKILL.md

1	# Test Strategy Planner
2
3	Goal: Design a read-only test strategy that maximizes confidence in important local behavior. Select test levels by the boundary that must be crossed and the defect that must be detected, not by a fixed pyramid, coverage target, or scenario count.
4
5	Execution contract: Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete.
6	Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend Checklist: X/Y complete<br>Incomplete: None \| section/item — reason; outcome impact; exact next action; list every incomplete item.
7
8	## Tool Routing
9
10	\| Need \| Preferred tool \| Use it when \| Fallback \|
11	\|---\|---\|---\|---\|
12	\| Requirements and repository rules \| Native file reads plus Git \| Establishing scope, current work, acceptance criteria, and supported commands \| User-provided requirements with explicit limitations \|
13	\| Existing test surface \| File listing, search, manifests, runner configuration, and CI \| Mapping test levels, fixtures, environments, and conventions \| Repository tree and known test entrypoints \|
14	\| 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 \|
15	\| Existing evidence \| Safe repository-defined test and coverage commands \| Determining what behavior is already proved and where confidence is weak \| Inspect tests and CI; mark execution unavailable \|
16	\| 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 \|
17
18	Keep the run read-only. Do not create tests, fixtures, snapshots, tasks, or documentation, and do not update the reviewed implementation.
19
20	## Evidence Rules
21
22	- Test level follows the observable boundary: use the lowest level that can expose the intended defect without bypassing the behavior under test.
23	- Coverage is discovery evidence, not proof. Require an oracle that would fail for the named defect.
24	- Prioritize by impact, plausible failure, uniqueness, detectability, and recovery cost; do not convert those judgments into universal numeric thresholds.
25	- Existing tests reduce a gap only when their setup and assertions prove the same behavior and failure mode.
26	- Framework, language, ORM, serializer, or library behavior is not a product test unless local configuration or integration changes its contract.
27	- External research is actionable only when it adds a concrete failure mode, boundary, or oracle to this plan.
28
29	## Checklist
30
31	### 1. Establish Scope and Evidence
32
33	- [ ] Resolve the feature, requirements, acceptance criteria, actors, explicit non-goals, and observable outcomes; return `BLOCKED` if there is no concrete behavior to plan for.
34	- [ ] Read applicable repository instructions and inspect Git state so current work and unrelated changes are not mistaken for established behavior.
35	- [ ] Detect languages, frameworks, runners, test directories, fixtures, factories, environments, CI gates, coverage, contract tests, and manual test surfaces.
36	- [ ] Map existing evidence to each requirement and mark it `PROVED`, `PARTIAL`, `MISSING`, or `UNAVAILABLE` based on the actual oracle.
37	- [ ] Inspect manual, exploratory, incident, and production evidence when it reveals behavior that automated suites do not cover.
38	- [ ] Identify environment, data, credentials, services, devices, browsers, and destructive-state constraints before proposing scenarios.
39	- [ ] Record assumptions and unknowns that can change test level, priority, or feasibility.
40
41	### 2. Build the Risk Map
42
43	- [ ] Trace critical flows from actor trigger through entrypoint, runtime wiring, state change, and durable or user-visible outcome.
44	- [ ] Identify uniquely important local behavior involving money, authentication, authorization, ownership, data integrity, destructive actions, migrations, public contracts, or irreversible workflows.
45	- [ ] Enumerate plausible defect classes: incorrect success, rejected valid input, accepted invalid input, boundary error, partial failure, duplicate delivery, ordering, timeout, retry, cancellation, race, rollback, recovery, and compatibility drift.
46	- [ ] Separate product risks from implementation details and from behavior already guaranteed by a dependency.
47	- [ ] Identify privacy-sensitive or regulated test data and require synthetic, minimized, or explicitly approved fixtures.
48	- [

levnikolaevichPublisher · 19 listings

Preview

levnikolaevich/claude-code-skills

# Test Strategy Planner

**Goal:** Design a read-only test strategy that maximizes confidence in important local behavior. Select test levels by the boundary that must be crossed and th

**Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete onl

Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: Non

Repolevnikolaevich/claude-code-skills

LicenseMIT

TypeSkills

CategoryTesting

UpdatedJul 2026

Repo stars520

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

ln-41-test-strategy-planner

520stars73forks

View on GitHub

How to install ln-41-test-strategy-planner?

levnikolaevich/claude-code-skills/ln-41-test-strategy-planner

$npx -y skills add levnikolaevich/claude-code-skills --skill ln-41-test-strategy-planner

Installs into the current project.

Summary

Designs a risk-based test strategy and prioritized scenarios without changing code. Use when requirements need a test plan; not for auditing or implementing tests.

Files · 1

View on GitHub

SKILL.md

1	# Test Strategy Planner
2
3	Goal: Design a read-only test strategy that maximizes confidence in important local behavior. Select test levels by the boundary that must be crossed and the defect that must be detected, not by a fixed pyramid, coverage target, or scenario count.
4
5	Execution contract: Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete.
6	Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend Checklist: X/Y complete<br>Incomplete: None \| section/item — reason; outcome impact; exact next action; list every incomplete item.
7
8	## Tool Routing
9
10	\| Need \| Preferred tool \| Use it when \| Fallback \|
11	\|---\|---\|---\|---\|
12	\| Requirements and repository rules \| Native file reads plus Git \| Establishing scope, current work, acceptance criteria, and supported commands \| User-provided requirements with explicit limitations \|
13	\| Existing test surface \| File listing, search, manifests, runner configuration, and CI \| Mapping test levels, fixtures, environments, and conventions \| Repository tree and known test entrypoints \|
14	\| 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 \|
15	\| Existing evidence \| Safe repository-defined test and coverage commands \| Determining what behavior is already proved and where confidence is weak \| Inspect tests and CI; mark execution unavailable \|
16	\| 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 \|
17
18	Keep the run read-only. Do not create tests, fixtures, snapshots, tasks, or documentation, and do not update the reviewed implementation.
19
20	## Evidence Rules
21
22	- Test level follows the observable boundary: use the lowest level that can expose the intended defect without bypassing the behavior under test.
23	- Coverage is discovery evidence, not proof. Require an oracle that would fail for the named defect.
24	- Prioritize by impact, plausible failure, uniqueness, detectability, and recovery cost; do not convert those judgments into universal numeric thresholds.
25	- Existing tests reduce a gap only when their setup and assertions prove the same behavior and failure mode.
26	- Framework, language, ORM, serializer, or library behavior is not a product test unless local configuration or integration changes its contract.
27	- External research is actionable only when it adds a concrete failure mode, boundary, or oracle to this plan.
28
29	## Checklist
30
31	### 1. Establish Scope and Evidence
32
33	- [ ] Resolve the feature, requirements, acceptance criteria, actors, explicit non-goals, and observable outcomes; return `BLOCKED` if there is no concrete behavior to plan for.
34	- [ ] Read applicable repository instructions and inspect Git state so current work and unrelated changes are not mistaken for established behavior.
35	- [ ] Detect languages, frameworks, runners, test directories, fixtures, factories, environments, CI gates, coverage, contract tests, and manual test surfaces.
36	- [ ] Map existing evidence to each requirement and mark it `PROVED`, `PARTIAL`, `MISSING`, or `UNAVAILABLE` based on the actual oracle.
37	- [ ] Inspect manual, exploratory, incident, and production evidence when it reveals behavior that automated suites do not cover.
38	- [ ] Identify environment, data, credentials, services, devices, browsers, and destructive-state constraints before proposing scenarios.
39	- [ ] Record assumptions and unknowns that can change test level, priority, or feasibility.
40
41	### 2. Build the Risk Map
42
43	- [ ] Trace critical flows from actor trigger through entrypoint, runtime wiring, state change, and durable or user-visible outcome.
44	- [ ] Identify uniquely important local behavior involving money, authentication, authorization, ownership, data integrity, destructive actions, migrations, public contracts, or irreversible workflows.
45	- [ ] Enumerate plausible defect classes: incorrect success, rejected valid input, accepted invalid input, boundary error, partial failure, duplicate delivery, ordering, timeout, retry, cancellation, race, rollback, recovery, and compatibility drift.
46	- [ ] Separate product risks from implementation details and from behavior already guaranteed by a dependency.
47	- [ ] Identify privacy-sensitive or regulated test data and require synthetic, minimized, or explicitly approved fixtures.
48	- [

levnikolaevichPublisher · 19 listings

Preview

levnikolaevich/claude-code-skills

# Test Strategy Planner

**Goal:** Design a read-only test strategy that maximizes confidence in important local behavior. Select test levels by the boundary that must be crossed and th

**Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete onl

Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: Non

Repolevnikolaevich/claude-code-skills

LicenseMIT

TypeSkills

CategoryTesting

UpdatedJul 2026

Repo stars520

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type