manual-acceptance

Write human-executable acceptance checklists for requirements that cannot be tested automatically.

9|Updated Mar 4, 2026
One-click install
npx skills add https://github.com/timcsy/semorphe --skill manual-acceptance-timcsy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: manual-acceptance
Source: https://github.com/timcsy/semorphe/tree/main/knowledge/skills/manual-acceptance
Command: npx skills add https://github.com/timcsy/semorphe --skill manual-acceptance-timcsy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Some requirements can never turn red in automated tests—scroll position persistence, block highlight order, what the user sees after pressing undo. This Skill guides you in writing manual acceptance checklists that a human can actually execute, while avoiding the three known failure modes of such checklists. ## Core Features & Use Cases - Testability triage: Before writing a manual item, determine whether the requirement is truly untestable or just not yet decomposed—split off the mechanizable half into automated guardrails. - Three-part acceptance items: Every item must state what it tests (motivation), how to operate it (a verified step-by-step sequence), and what both good and bad outcomes look like. - Baseline control groups: Distinguish failures caused by your code from host-environment behavior by requiring baseline measurements and "no worse than baseline" criteria. - Use Case: When shipping a Blockly-based editor change, produce a checklist table with screenshot-based verification of toolbox categories, dragged blocks, and cross-language block consistency. ## Quick Start Write a manual acceptance checklist for the undo behavior requirement, with steps, expected good and bad outcomes, and a host-environment baseline comparison.

Frequently Asked Questions about manual-acceptance

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write acceptance criteria for features that cannot be automated?

Structure each item in three parts: a one-sentence motivation, a step-by-step operation sequence you have personally walked through, and descriptions of both passing and failing outcomes. Missing any part leads to known failure modes like items being skipped or false defect reports.

When should a requirement use manual acceptance testing instead of automated tests?

Only after checking whether the requirement is truly untestable or merely not yet decomposed. Requirements about visual appearance, like whether a block looks correct, need human eyes, while behavioral rules like no-write-during-drag can usually be automated.

Why do manual acceptance tests produce false defect reports?

False reports usually come from two causes: operation steps that were never actually walked through, so testers cannot find the control, and missing baseline controls, so host-environment behavior gets blamed on your code.

How do I verify visual UI changes like block rendering?

Use screenshots rather than API queries, since no API can tell you whether a block looks right. Capture the toolbox categories, a dragged-out block, and the same block in the other language side by side for consistency checks.

What are the limitations of manual acceptance checklists?

Checklists rot silently when the underlying system changes, since old items may describe behavior that is no longer possible or relevant. They also require a human in a real environment and must never be self-certified by the developer who delivered the change.