Automated Test Planning

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. 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.

• Dispatch in proportion to the question. The size band chosen in Step 1.5 caps the roster, and a narrow question gets one agent and a prose answer rather than a team and a full document. Never dispatch the full roster for a question a single agent can settle BECAUSE the dispatch overhead exceeds the work, and a reader who asked one question pays for a document they did not want.

Project Context

• git installed: !which git 2>/dev/null || echo "not installed"
• CLAUDE.md: !find . -maxdepth 1 -name "CLAUDE.md" -type f
• project-discovery.md: !find . -maxdepth 3 -name "project-discovery.md" -type f
• personal config directory: !bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"
• project .han/config.md: !cat .han/config.md 2>/dev/null || echo ""

As your first action, use the Read tool on .han/config.md inside the personal config directory path above. A read that returns no file is no personal configuration: continue silently. When that file or the project .han/config.md probe supplies content, apply it per config-rule.md, which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Step 1: Determine Scope

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.

Scope determination: Check git installed from Project Context. If empty or not installed, skip to Mode C below.

Run ${CLAUDE_SKILL_DIR}/scripts/detect-test-context.sh and parse its output. If git-available: false, skip to Mode C below.

Mode A: Full git context — git-available: true and the output contains a changed-files-start block with content.

• 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)
• Otherwise: use the changed files list from the script output as scope

Mode B: Uncommitted changes — git-available: true but output contains changed-files: none.

• If the user provided scope: use it as-is
• 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
• If no files found in any of those commands, fall through to Mode C

Mode C: No git / no changes found — git missing, not in a repo, or no changes detected in any state.

• If the user provided file paths, directories, or a description of what to test: use those as-is
• 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

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.

Step 1.5: Classify Size and Mode

Default to small. Start the classification at small and only escalate to medium or large when the signals below clearly require it. When a signal is borderline, stay at the smaller band.

Classify from the user's own request first, and from Step 1's file list only when the request settles nothing. A narrow question asked on a branch with many changed files is still small BECAUSE Step 1 falls back to the whole changed-files list whenever the user named no scope, and that list describes the branch rather than the question.

• Small (default) — the request names specific existing or proposed tests and asks whether they are worth writing, or asks one question a single agent can settle, or the scope from Step 1 is 1-3 files in a single subsystem. Defaults to focused mode.
• Medium — 4-10 files, or one cross-cutting concern such as a single API contract, a schema migration, or a new permission check. Defaults to full mode.
• Large — more than 10 files, multiple subsystems, architectural changes, or security or data implications. Defaults to full mode.

Size override. If $size is non-empty (the user passed small, medium, large, or dynamic as the first argument), use it: a band value is the size and skips the signal-based classification above, while dynamic forces the signal-based classification even when the config sets a default band. If $size is empty and either .han/config.md supplies a band via default-swarm-size (per ../../references/config-rule.md), use that band and skip the signal-based classification. Anything that is not one of the four accepted values is trailing context, not a size.

Bind $focus. Read the user's free-form argument string from the invocation (everything after the optional $size positional). If non-empty, bind $focus to that string verbatim; if empty, bind it to none provided. This binding is the description Step 2 passes to each agent prompt.

State the chosen band and mode in one line with the justification before dispatching anything (for example, Small: the request names two proposed contexts on one method, so focused mode, Medium: passed via $size, or Medium: from the project .han/config.md default-swarm-size, naming whichever file supplied it). Accept the user's override of the band, the mode, or both.

In focused mode, dispatch only han-core:test-engineer in Step 2, skip the conditional specialists, answer in prose per Step 4's focused-mode rules, and skip the two reviewers in Step 5. Step 3 runs in full either way. Its behavioral, prerequisite, and YAGNI sweeps decide what may be recommended at all, so skipping them would let a focused answer recommend a test that cannot be written without an out-of-scope production change. In full mode, run every step as written.

Step 2: Dispatch Testing Agents

In focused mode, dispatch item 1 alone and skip the conditional-dispatch section entirely.

Launch the testing agents in parallel using the Agent tool with run_in_background: true. Pass each agent the file list from Step 1. In Mode A or Mode B, include on branch {branch} in agent prompts if a branch name was detected by the script; in Mode C or when no branch was detected, omit the branch reference entirely. When $focus is anything other than none provided, include it in every agent prompt so they can focus their analysis; it is what the {any additional context from user arguments} placeholder below resolves to.

Always dispatch

1. Launch han-core:test-engineer agent — prompt: "Analyze test coverage for the following files{on branch {branch} if applicable}: {file list}. Recommend tests only at the public API: the inputs a real caller supplies, the outputs and side effects they observe, and the interactions the unit has with the objects and services it collaborates with. Do not recommend tests that reach into private methods, internal state, or implementation structure — if two implementations would produce the same observable behavior, the test must pass for both. Cover the critical behaviors a caller depends on and stop; do not specify a test for every branch, private helper, or intermediate value. Apply the YAGNI rule from ../../references/yagni-rule.md — recommend a test only when the code commits to a behavior the test verifies AND the failure mode is realistic for this codebase. Symmetry, completeness, and hypothetical scaling are YAGNI; defer those to the Deferred Tests section with the trigger that would justify writing them. {any additional context from user arguments}"

2. Launch han-core:edge-case-explorer agent — prompt: "Explore edge cases for the following files{on branch {branch} if applicable}: {file list}. Focus on inputs, integration points, and error paths observable through the public API and through interactions with collaborating objects and services — not internal state or private implementation. Apply the YAGNI rule from ../../references/yagni-rule.md — raise an edge case only when a real caller produces the input, the failure mode has plausible production trigger, or the case is critical-path correctness regardless of caller. Hypothetical adversaries the code doesn't face and symmetry-driven boundaries go to Dropped Edge Cases with the trigger that would justify revisiting. {any additional context from user arguments}"

Conditional dispatch

Skip this whole section in focused mode. Otherwise inspect the file list before launching, and skip any that do not apply.

3. Launch han-core:concurrency-analyst agent — only if the file list touches threads, async/await, goroutines, actors, shared mutable state across requests, timers, locks, or message queues. Prompt: "Identify concurrency test gaps for the following files{on branch {branch} if applicable}: {file list}. Focus on race conditions, lock ordering, shared-resource contention, deadlock potential, and async error handling that should be covered by tests. {any additional context from user arguments}"

4. Launch han-core:adversarial-security-analyst agent — only if the file list touches authentication, authorization, input validation, data isolation, session handling, crypto, file uploads, external API calls with secrets, or SQL/ORM query construction. Prompt: "Identify negative security tests that should exist for the following files{on branch {branch} if applicable}: {file list}. Focus on exploit paths that tests could catch before production — authorization bypass, injection, broken isolation, insecure defaults. Return test recommendations, not general threat modeling. {any additional context from user arguments}"

Extra agents named in the project config's ## Extra Agents list join this conditional-dispatch pool under the same file-list-signal selection, per ../../references/config-rule.md: dispatch one only when the file list carries a signal matching its stated specialty, and skip an entry that does not resolve to a dispatchable agent with a one-line note.

Wait for every dispatched agent to complete and collect full output for processing in Step 3.

Step 3: Merge and Prioritize

Combine findings from every dispatched agent into a unified, prioritized test plan:

1. Classify findings —
   • han-core:test-engineer items (T1, T2, ...): map High to CRIT or HIGH depending on the code path (security, data integrity, auth = CRIT; business logic, error handling = HIGH), Medium to MED, Low to LOW.
   • han-core:edge-case-explorer items (EC1, EC2, ...): map directly — Critical to CRIT, High to HIGH, Medium to MED, Low to LOW.
   • han-core:concurrency-analyst items (C1, C2, ...) when dispatched: races on auth/billing/isolation = CRIT; realistic load contention, async error swallowing = HIGH; theoretical interleaving = MED.
   • han-core:adversarial-security-analyst items (SEC-NNN) when dispatched: every item lands at CRIT. Retain the SEC-### cross-reference in the unified item so the source is visible. CRIT ranks the finding's severity and says nothing about whose ticket the fix belongs to; the prerequisite sweep below still applies to every one of them.
2. Apply the behavioral sweep — walk every surviving recommendation and confirm it verifies observable behavior at a public seam (caller-supplied inputs, observed outputs and side effects, interactions with collaborating objects and services). Rewrite any item that asserts on private methods, internal state, or implementation structure so it tests the same behavior through the public boundary; if no public seam exposes it, drop the item and note that the behavior should be observed at a higher level rather than pinned to internals. Collapse multiple low-level items that protect the same observable behavior into the single behavioral test that catches the same realistic failure modes.
3. Apply the prerequisite sweep — walk every surviving recommendation and ask what has to be true before the test can be written at all. An item whose test approach needs a production-code change first, meaning an added order, a new validation, a changed return value, a schema column, or any other edit to shipped code, is not a test to write. It is a production change wearing a test's clothes, and folding it into the plan hands the implementer a code change nobody authorized. Move it out of the priority tiers into Blocked by a Production Change, recording the change it needs, the file that would carry it, and who else consumes that file, so a reader can see the blast radius and open a separate ticket. Run this sweep before IDs are assigned, and run it over security items too: an honest finding at CRIT is still out of scope if it cannot be tested without first changing shipped code.
4. Assign unified IDs — sequential IDs: TP-001, TP-002, TP-003, etc. Include the original agent ID as a cross-reference (e.g., "TP-001 (from T3)", "TP-002 (from C1, concurrency)", "TP-003 (from SEC-001, security)").
5. Order by priority — interleave items from every agent by priority: all CRIT items first, then HIGH, then MED, then LOW. Within each priority level, order by the agent's own ranking.
6. Cap at 40 items — keep a maximum of 40 items total, prioritized by severity. Security items (SEC-derived) are exempt from the cap. If more than 40 non-security items exist, note how many were omitted and recommend running the skill again after addressing high-priority items.
7. Apply the YAGNI sweep — walk every test recommendation that survived classification and apply ../../references/yagni-rule.md. Demote any test whose justification reduces to "completeness", "best practice", "for future flexibility", symmetry with another test, or hypothetical scaling/adversaries the change doesn't touch — these go to the Deferred Tests section with a Reason: YAGNI — {gate failure} and the trigger that would justify writing the test (a third real customer hits the edge case, the feature actually ships the path, a measured production failure occurs, etc.). When several recommended low-level tests can be replaced by one durable behavioral test that catches the same realistic failure modes, replace them with the single test and record the dropped low-level tests under Deferred with Reason: YAGNI — single behavioral test catches the same realistic failure modes.