Manual Test Planning

Project Context

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

Operating Principles

• Group outcomes only when the steps are identical. A test verifies a single outcome, or a group of related outcomes only when the exact same steps produce every outcome in the group. If any outcome needs a different or additional step, it gets its own test, BECAUSE a person following one step list can only check the outcomes those steps actually produce.
• Every test states its expected outcomes. A step list without an expected outcome is not a test. Each test's detail section ends with the outcome or outcomes the person should observe, so they can tell pass from fail on the spot.
• No manual tests means no document. When the supplied context contains nothing a person can test by hand, say so clearly and ask for more context instead of writing a file. Never invent or pad testable outcomes, BECAUSE a plan built on guesses sends the tester chasing outcomes the work never promised.
• Plain language only. The plan is written for the person who runs the tests by hand, who may not be technical. Short, concise sentences. No file paths, function names, code, or framework jargon anywhere in the document. Describe what the person does and sees through the product's own surfaces (screens, commands, pages, messages), not how the code works, BECAUSE the reader follows the plan without ever reading the code.

Step 1: Gather the Context

Collect everything supplied to the skill call: the arguments, the conversation so far, and any files, plans, specs, diffs, or pull requests referenced. Read referenced files with Read. If a branch, PR, or change set is referenced and git is available, use git diff, git log, and git status to understand what changed; if git is unavailable or the directory is not a repository, skip the git commands and work from the rest of the supplied context. The git detail informs your understanding only — none of it appears in the plan.

If no context was supplied at all, ask the user what they want a manual test plan for, and wait for their answer before continuing.

Step 2: Identify What Can Be Manually Tested