菜单
How to write comprehensive manual testing playbooks. Use when creating manual test procedures for new features, writing playbook sections in docs/manual-testing-playbooks.md, or when a project plan includes Step 6 manual testing.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Project architecture and design principles for vm_builds Ansible project. Includes bake vs configure patterns, two-role service model, and deployment lifecycle.
Python code conventions. Functions return errors, .env parsing strips quotes, type hints required.
Proactive validation patterns to catch issues early, prevent debugging blind, and establish testing habits before problems escalate.
Update skills and rules when encountering new issues to prevent recurrence. Includes hard-fail patterns, code custodianship, and mandatory testing requirements.
LXC container provisioning and configuration patterns. Use when creating LXC services, managing container networking, or handling LXC template operations.
Molecule test performance optimization patterns. Template caching, NTP sync, pct_remote overhead, apt cache, selective rebuilds.
| name | manual-testing-playbook-writing |
| description | How to write comprehensive manual testing playbooks. Use when creating manual test procedures for new features, writing playbook sections in docs/manual-testing-playbooks.md, or when a project plan includes Step 6 manual testing. |
Any project plan that includes Standard Work Cycle Step 6 (manual testing)
MUST produce a playbook in docs/manual-testing-playbooks.md as a plan
deliverable. This skill governs HOW to write that playbook.
NEVER defer playbook writing to implementation. The playbook is written DURING plan creation and committed alongside the project plan. The implementation milestone EXECUTES the playbook — it does not CREATE it.
NEVER duplicate playbook content in the project plan. The plan references the playbook by file path and section number. One source of truth.
NEVER use "or" when listing features to test. "Test App A or App B" means only one gets tested. Enumerate and test EVERY feature individually.
NEVER write vague expected outcomes. "Verify it works" is not an outcome. "KasmVNC iframe shows the Jellyfin library, NOT the kiosk hub" is.
ALWAYS update .agents/skills/webui-manual-testing/SKILL.md to list the
new playbook immediately — not deferred to a later milestone.
Before writing test steps, inventory EVERY testable surface in the feature.
Read the source code — data.py constants, hub service lists, nav items,
route registrations, page modules. Do not rely on memory or the user's
description.
Categorize by interaction type, then test EVERY item in each category:
| Category | How it works | What to verify |
|---|---|---|
| Screen takeover | Stops current app, launches VM/CT | Launch confirmation → takeover → interact → exit → return to hub → still connected |
| External web UI | Opens in /view iframe with nav bar | Viewer loads → iframe content renders → interact inside iframe → back to hub |
| Internal page | Navigates within the app | Page loads → content renders → interact → back to previous page |
| API action | Button triggers backend operation | Click → status feedback → verify real effect on infrastructure |
If a hub has 15 services, the playbook tests all 15. If a dashboard has 6 host cards, test all 6. Partial coverage is not coverage.
### N.X Section title
<1-2 line description of what this section tests>
1. Specific action (what to click, what command to run)
2. Specific expected outcome (what appears, NOT "verify it loads")
3. Specific interaction (click inside the app, navigate, type)
4. Specific exit (how to leave — each app has different exit UX)
5. Verify connection/state is preserved after exit
Per-app steps within a section use bold headers:
**App Name (context):**
1. Step with specific expected outcome
2. ...
ALWAYS include infrastructure setup the tester needs BEFORE the test:
ssh -L syntax) for every port the
browser must reach. Do not assume the tester is on the fleet LAN.source test.env, virtualenv activation).Apps live on specific hosts. The playbook MUST specify which host to VNC into / connect to for each test. Do not write "launch Kodi from the hub" when Kodi only exists on home's kiosk. State "VNC into home's kiosk" explicitly. If testing a host without an app, verify the tile shows "Not available" — that IS a test.
Every playbook MUST end with error/edge case testing:
The project plan's manual testing milestone references the playbook:
- [ ] **EXECUTE Playbook N, ALL sections (N.1–N.X)** against the fully
converged system. Run every command. Click every button. Verify every
expected outcome. No section may be skipped.
NEVER say "walkthrough," "review," or "verify playbook exists." The verb is EXECUTE. The milestone is hands-on hardware testing, not a read-through.
docs/manual-testing-playbooks.md.
User had to ask twice. Fix: playbook is written during plan creation.