Test manual

Skill knowhowlab/agent-testkit/skills/test-manual

Conduct the repository's TESTS_MANUAL.md plan as a guided manual test — the USER runs every command and GUI action while Claude presents one step at a time, evaluates reported results, proposes (never applies unasked) fixes, and keeps the protocol file. Use when the user wants to test by hand, run commands themselves, do a guided walkthrough or acceptance session, or verify the app manually — with optional scope arguments.From its SKILL.md

Install

npx -y skills add knowhowlab/agent-testkit --skill test-manual

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.7 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

test-manual — Conduct the manual plan

Goal: Walk the user through TESTS_MANUAL.md (repository root) with the user executing every command and GUI action. Claude conducts: one step at a time, exact command/action + expected result up front, evaluate what the user reports, log everything to <protocol dir>/<protocol prefix>-YYYYMMDD-HHMM.md (UTC timestamp at start; create the directory if missing).

Pre-flight

Locate TESTS_MANUAL.md at the repo root (or nearest ancestor). Missing → say so and offer to run test-init. Do not improvise.
Read the plan: Meta, Scopes, Facts, Fixtures, Phases, Wrap-up.
Resolve arguments against ## Scopes; unknown scope → ask. The user may also name phases directly ("just Phase 4 and 5").

Critical rules (inverted from test-e2e)

The user runs the commands and drives the GUI — never Claude. Do not execute build, run, curl, kill, docker, or any stack-exercising command yourself, even if it would be faster. Present each shell command copy-paste-ready and suggest the ! prefix (! npm test …) so its output lands directly in the conversation for evaluation. Present each GUI action as: what to click/drag/type, and exactly what should appear.
One step at a time. Present exactly one step: the command or action, what it does, and the expected result (exit code, key output lines, thresholds, visible UI state). Then stop and wait. Never dump a phase's worth of steps at once.
Evaluate, don't assume. When a report arrives, state PASS/FAIL against the Expect: explicitly and say why. Ambiguous or truncated report → ask for the missing piece (or a screenshot description) before judging. Check ## Facts before judging — documented caveats are not failures.
Propose fixes, apply only on instruction. On failure: diagnose root cause, present the fix (file, before → after), and wait. The user decides — Claude applies it, the user applies it, or log-and-continue. Never edit code unasked.
The user may skip. Any step or phase can be skipped on request — log it SKIPPED (user) and move on. Missing prerequisites → SKIPPED (prereq), recording which.
Claude keeps the books. Writing the protocol file, creating the protocol directory, and preparing inert Fixtures from the plan (scratch configs, broken-config samples, helper scripts) are Claude's job — offer each fixture before writing it, and never write into the repo except the protocol, plan-declared fixtures, and agreed fixes. Everything that executes is the user's.
Retry guidance, not retry execution. On timing-shaped failures (connection refused, still initializing) tell the user to wait 15–30 s and rerun once before treating it as a failure. Per-step Retry: and plan Facts (slow first compiles, known warm-up) override the default.
Destructive steps are announced. A step marked Destructive: is presented with its consequence stated plainly ("this wipes the app's cached state — binary selection will be gone") before the user runs it.

Session flow

Setup: create the protocol file with the environment header — ask the user to run the plan's Environment commands and report, or accept "skip environment" and note it. Agree on a scratch directory (suggest $(mktemp -d)) — the user creates it.
Walk the phases in order (minus skips). Before each phase: one-line goal + step count. After each phase: one-line verdict, protocol updated.
Wrap-up: conduct the plan's Re-run: phases; summary table with totals (passed / failed / fixed / skipped); list fixes applied and by whom; surface the plan's Remind: bullets (uncommitted changes, spec checkboxes to tick — offer to tick them).

Protocol file format

# Manual Test Protocol — <project>

**Date**: YYYY-MM-DD HH:MM UTC
**Branch**: <current git branch>
**Commit**: <HEAD short hash>
**Plan**: TESTS_MANUAL.md (format v1, generated <date>) · Scope: <scopes or full>
**Environment**: <results of the plan's Environment commands>

## Summary

| Phase | Result | Tests | Passed | Fixed | Failed | Blocked | Skipped |
|-------|--------|-------|--------|-------|--------|---------|---------|

## Phase N: <name>

### Results

| # | Step | Result | Details |
|---|------|--------|---------|

### Issues & Fixes

#### Issue N.1: <title>
- **Error**: <exact error message>
- **Root cause**: <analysis>
- **Fix**: <what was changed>
- **Files modified**: <list>
- **Verified**: Yes/No

Total: N passed, N fixed-then-passed, N blocked, N skipped.
Repo files changed: <list or none>.

Who executed is always the user for commands and GUI actions; quote the user's pasted output or wording verbatim for anything FAIL, ambiguous, or surprising. Issues & Fixes blocks per failure (root cause, fix proposed, decision, who applied, state). Final summary table with totals. Skips marked SKIPPED (user) / SKIPPED (prereq) / SKIPPED (scope).

Console style

Conductor voice, minimal — one step block at a time:

Step 4.2 — readiness probe. Run: curl -i http://127.0.0.1:9464/readyz · Expect: HTTP/1.1 200, body ready. Paste the output (or run it with a leading !).

— then wait.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.