test-planning

Name: test-planning
Author: testdouble

122stars12forks

How to install test-planning?

testdouble/han/test-planning

$npx -y skills add testdouble/han --skill test-planning

Installs into the current project.

Summary

Produce a standalone test plan by analyzing code for test coverage gaps and edge cases. Use when you need to create, generate, or draft a test plan for a branch, need to analyze test coverage, or need to identify what tests to write for specific files or directories. Does not wri

Files · 1

View on GitHub

SKILL.md

1	## Operating Principles
2
3	- Test behavior through the public API, never internals. Every recommended test verifies observable behavior at a public seam: the inputs a real caller supplies, the outputs and side effects they observe, and the interactions the unit has with the other objects and services it collaborates with. Do not recommend tests that reach into private methods, internal state, or implementation structure — those tests pin the how and break on every refactor. When two designs would produce the same observable behavior, the test must pass for both. If a behavior can only be observed by inspecting internals, that is a signal the behavior belongs at a different seam, not a license to test the internal; note it and move the recommendation to the public boundary that exposes it. This is the depth ceiling: cover the critical behaviors a caller depends on, and stop. Do not specify tests for every branch, every private helper, or every intermediate value.
4	- YAGNI is a first-class operating principle for tests. Apply the evidence-based YAGNI rule from [../../references/yagni-rule.md](../../references/yagni-rule.md). A test is worth recommending only when (a) the code under review commits to a behavior the test verifies and (b) the failure mode the test would catch is realistic for this codebase. Tests for code paths that don't exist yet, hypothetical adversaries the code doesn't face, hypothetical scaling problems the workload doesn't have, "completeness" with existing tests, or symmetry ("we have a test for create, so we should have one for delete") are YAGNI candidates and go to the Deferred Tests section with the trigger that would justify writing them. When many speculative low-level tests can be replaced by one durable behavioral test that catches the same realistic failure modes, recommend the single test instead. Every test is ongoing maintenance and a brittleness surface.
5
6	## Project Context
7
8	- git installed: !`which git 2>/dev/null \|\| echo "not installed"`
9	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
10	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
11
12	## Step 1: Determine Scope
13
14	Resolve project config: read CLAUDE.md's `## Project Discovery` section for test command (under `### Commands and Tests`, not `### Frameworks and Tooling`), language, and framework; fall back to project-discovery.md. Store found values for use in later steps.
15
16	Scope determination: Check `git installed` from Project Context. If empty or `not installed`, skip to Mode C below.
17
18	Run `${CLAUDE_SKILL_DIR}/scripts/detect-test-context.sh` and parse its output. If `git-available: false`, skip to Mode C below.
19
20	Mode A: Full git context — `git-available: true` and the output contains a `changed-files-start` block with content.
21	- If the user provided file paths, directories, or a description: use those as scope (do not go searching for plan files or try to locate plans)
22	- Otherwise: use the changed files list from the script output as scope
23
24	Mode B: Uncommitted changes — `git-available: true` but output contains `changed-files: none`.
25	- If the user provided scope: use it as-is
26	- Otherwise: run `git diff` (unstaged changes), `git diff --cached` (staged changes), and `git status --short` (untracked files) to identify changed files; if any files are found, use those as scope
27	- If no files found in any of those commands, fall through to Mode C
28
29	Mode C: No git / no changes found — git missing, not in a repo, or no changes detected in any state.
30	- If the user provided file paths, directories, or a description of what to test: use those as-is
31	- Otherwise: use Glob to discover source files in the current directory, excluding `node_modules/`, `.git/`, `vendor/`, `dist/`, `build/`, `__pycache__/`, lock files; present the discovered files and ask the user to confirm scope
32
33	Build a list of source files to analyze: expand directories to find source files; identify relevant source files from branch changes or project structure for descriptions.
34
35	## Step 2: Dispatch Testing Agents
36
37	Launch the testing agents in parallel using the `Agent` tool

People who liked this also viewed

6 picks

Type

test-planning

122stars12forks

View on GitHub

How to install test-planning?

testdouble/han/test-planning

$npx -y skills add testdouble/han --skill test-planning

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Operating Principles
2
3	- Test behavior through the public API, never internals. Every recommended test verifies observable behavior at a public seam: the inputs a real caller supplies, the outputs and side effects they observe, and the interactions the unit has with the other objects and services it collaborates with. Do not recommend tests that reach into private methods, internal state, or implementation structure — those tests pin the how and break on every refactor. When two designs would produce the same observable behavior, the test must pass for both. If a behavior can only be observed by inspecting internals, that is a signal the behavior belongs at a different seam, not a license to test the internal; note it and move the recommendation to the public boundary that exposes it. This is the depth ceiling: cover the critical behaviors a caller depends on, and stop. Do not specify tests for every branch, every private helper, or every intermediate value.
4	- YAGNI is a first-class operating principle for tests. Apply the evidence-based YAGNI rule from [../../references/yagni-rule.md](../../references/yagni-rule.md). A test is worth recommending only when (a) the code under review commits to a behavior the test verifies and (b) the failure mode the test would catch is realistic for this codebase. Tests for code paths that don't exist yet, hypothetical adversaries the code doesn't face, hypothetical scaling problems the workload doesn't have, "completeness" with existing tests, or symmetry ("we have a test for create, so we should have one for delete") are YAGNI candidates and go to the Deferred Tests section with the trigger that would justify writing them. When many speculative low-level tests can be replaced by one durable behavioral test that catches the same realistic failure modes, recommend the single test instead. Every test is ongoing maintenance and a brittleness surface.
5
6	## Project Context
7
8	- git installed: !`which git 2>/dev/null \|\| echo "not installed"`
9	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
10	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
11
12	## Step 1: Determine Scope
13
14	Resolve project config: read CLAUDE.md's `## Project Discovery` section for test command (under `### Commands and Tests`, not `### Frameworks and Tooling`), language, and framework; fall back to project-discovery.md. Store found values for use in later steps.
15
16	Scope determination: Check `git installed` from Project Context. If empty or `not installed`, skip to Mode C below.
17
18	Run `${CLAUDE_SKILL_DIR}/scripts/detect-test-context.sh` and parse its output. If `git-available: false`, skip to Mode C below.
19
20	Mode A: Full git context — `git-available: true` and the output contains a `changed-files-start` block with content.
21	- If the user provided file paths, directories, or a description: use those as scope (do not go searching for plan files or try to locate plans)
22	- Otherwise: use the changed files list from the script output as scope
23
24	Mode B: Uncommitted changes — `git-available: true` but output contains `changed-files: none`.
25	- If the user provided scope: use it as-is
26	- Otherwise: run `git diff` (unstaged changes), `git diff --cached` (staged changes), and `git status --short` (untracked files) to identify changed files; if any files are found, use those as scope
27	- If no files found in any of those commands, fall through to Mode C
28
29	Mode C: No git / no changes found — git missing, not in a repo, or no changes detected in any state.
30	- If the user provided file paths, directories, or a description of what to test: use those as-is
31	- Otherwise: use Glob to discover source files in the current directory, excluding `node_modules/`, `.git/`, `vendor/`, `dist/`, `build/`, `__pycache__/`, lock files; present the discovered files and ask the user to confirm scope
32
33	Build a list of source files to analyze: expand directories to find source files; identify relevant source files from branch changes or project structure for descriptions.
34
35	## Step 2: Dispatch Testing Agents
36
37	Launch the testing agents in parallel using the `Agent` tool

People who liked this also viewed

6 picks

Type