automated-test-planning
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 produce a plain-language plan for a person to run tests by hand — use manual-test-planning for that. Does not write test code — use tdd to implement behavior test-first. Does not refine existing plans — use iterative-plan-review. Does not review code quality, security, or style — use code-review for full code review. Does
npx skills add testdouble/han --skill automated-test-planning --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
## Operating Principles - **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. - **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 u
- Operating Principles
- Project Context
- Step 1: Determine Scope
- Step 2: Dispatch Testing Agents
- Always dispatch
- Conditional dispatch
- Step 3: Merge and Prioritize
- Step 4: Generate Output
- Step 5: Review the Output
What does the automated-test-planning skill do?
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 produce a plain-language plan for a person to run tests by hand — use manual-test-planning for that. Does not write test code — use tdd to implement behavior test-first. Does not refine existing plans — use iterative-plan-review. Does not review code quality, security, or style — use code-review for full code review. Does
How do I install it?
Run `npx skills add testdouble/han --skill automated-test-planning --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From testdouble/han, a repository with 154 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.