executing-test-plans
Executing Test Plans
Execute test plans end-to-end with strict state control and concise reporting.
Policy (per section, in order)
- Sense-check section; if incoherent, propose minimal fix ->
suggested_adjustments - State prep: verify prerequisites; run minimal corrective actions. If impossible, mark
BLOCKEDwith reason - Execute exactly; record precise inputs and raw outputs
- Verify vs expected; set
status=PASS|FAIL|BLOCKED - Notes: timings, IDs, logs, env diffs (terse)
- Keep adjustments (don't lose edits or ordering changes)
Pre-flight
- Check env profile from arguments
- Docker services:
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" | head -20 - Service health checks as applicable
Execution Rules
- Follow plan sections strictly; only minimal fixes allowed (record them)
- Prefer tiny adjustments over skips; never reorder unless required (record it)
- Continue after failures unless they hard-block subsequent steps
For Each Test Step
Document clearly:
- Test step description/objective
- All inputs provided
- Actual output/result received
- Expected vs actual comparison
- Pass/Fail determination with reasoning
Output
Write <out-dir>/test-results.json with this schema:
{
"metadata": {
"sut": "",
"env": {},
"plan_sections": 0,
"timestamp": ""
},
"sections": [
{
"id": "",
"title": "",
"precheck_ok": true,
"pre_state": { "assessed": [], "actions": [], "ready": true },
"inputs": [],
"outputs": [],
"expected": [],
"comparison": { "match": true, "diffs": [] },
"status": "PASS",
"suggested_adjustments": [],
"notes": []
}
],
"overall": {
"pass_rate": "0/0",
"failing_or_blocked_sections": [],
"verdict": "PASS"
}
}
Also write a human-readable Markdown summary alongside the JSON.
Quality Standards
- Be thorough and methodical -- missing a test step undermines the process
- Remain objective in pass/fail -- base decisions on evidence, not assumptions
- Document unexpected findings even if not part of the plan
- Documentation should be detailed enough for reproduction
More from trevors/dot-claude
jj-workflow
Jujutsu (jj) version control, load skill when hook output shows vcs=jj-colocated or vcs=jj in the system-reminder.
93book-reader
Read and search digital books (PDF, EPUB, MOBI, TXT). Use when answering questions about a book, finding quotes or passages, navigating to specific pages or chapters, or extracting information from documents.
44using-jj
Advanced jj/jujutsu workflows — revsets, absorb, evolog, op restore/undo, immutable_heads bypass, divergent-change resolution, jj split, parallel jj new, conflict-after-rebase, force-push recovery. Contains non-obvious rules (e.g., always `-m` to avoid editor) that prevent broken workflows. Skip for simple commit/push/rebase.
43svelte5
Svelte 5 syntax reference. Use when writing ANY Svelte component. Svelte 5 uses runes ($state, $derived, $effect, $props) instead of Svelte 4 patterns. Training data is heavily Svelte 4—this skill prevents outdated syntax.
39git-workflow
Git version control workflows. Load when hook output shows vcs=git (not jj). Use when squashing commits, rebasing feature branches, or doing git operations in non-jj repos.
27reading-books
Read and search digital books (PDF, EPUB, MOBI, TXT). Use when answering questions about a book, finding quotes or passages, navigating to specific pages or chapters, or extracting information from documents.
27