version: "1.0.0" name: "caspar-create_test_guide" description: "Generate a right-sized manual test guide for completed work — feature-based checklists scaled to change size, focused on risk. Use after execute/validate when you need a human-runnable QA pass before clean/test. Do NOT use to write automated tests (that's the test phase) or to validate wiring (that's validate)." user-invocable: true

create_test_guide

Produce a manual testing guide, scaled to the change, that a human can run to validate the work. Input is the current task's changes; output is one checklist artifact.

Inputs

• $ARGUMENTS — optional focus areas to emphasize.
• Task context: features added/modified/removed, stack/environment, user personas, integration points/dependencies. Read from canonical artifacts (scope.md, plan.md, tasks.json slices) and the diff. Use execute.md only to locate tasks.json; do not inline the full task graph.

Working Set

• Read-only: task artifacts under docs/tasks/{branch}/, the implemented diff.
• Write: the single test-guide artifact only.

Outputs + DONE

Write to {OUT_DIR}/testing/{branch}_test_guide.md where branch=$(git rev-parse --abbrev-ref HEAD) and OUT_DIR = user-specified target_dir if given, else docs/tasks/{branch} (run mkdir -p "$OUT_DIR/testing").

DONE when:

• Complexity classified Simple | Medium | Complex with a one-line rationale (Simple = smoke/happy-path + quick regression; Medium = edge cases, error handling, basic integration; Complex = advanced scenarios, performance, cross-feature, security).
• Required sections present (always): Testing Overview (scope, environment, prerequisites) · Environment Setup (steps + verification) · Core Test Cases (primary functionality) · Results Documentation (how to record/report).
• Optional sections included only when relevant: Known Issues & Limitations · Rollback Procedures (high-risk/prod) · Performance · Accessibility (UI/UX) · Cross-Browser/Device (frontend) · Data Validation · Security (auth/permissions/data-access).
• Organized by user workflow/feature, not procedural phases; headers name the user goal.
• Each checkbox is an action + verification pair (e.g. "Send POST to /api/users → verify 201 with user ID returned"), using [ ] for tracking; related steps grouped under one scenario; concrete test data (paths, names, shortcuts/UI elements in parens) included.
• Depth scaled to change size (CSS tweak ≠ payment system); instructions runnable by someone unfamiliar with the code; no over-engineering for trivial changes.
• A coverage summary returned: # workflows, # steps, estimated time, and the chosen complexity tier + rationale.

Feature-section shape:

### 1. Feature Name (User Action/Context)
-[ ] Action to perform → what to verify/expect
-[ ] Edge case or error handling → expected behavior

Method / guardrails

• Scale to risk: prioritize what is most likely to break or impact users; only include sections that add value.
• Each scenario validates one capability end-to-end.

Handoff

• Return the coverage summary in-thread (no extra docs). Close with a one-line Next Steps pointing to caspar-clean or caspar-test.

Escalate-If

• Task context is too thin to identify the changed features or personas — ask before guessing.