Create manual test instructions

Read the input ticket or requirements document (and, where needed for accurate navigation, the code it cites). Write the manual-test file in the same directory, naming it by replacing .REQUIREMENTS or .TICKET with .MANUAL-TEST (e.g. FOO.REQUIREMENTS.md → FOO.MANUAL-TEST.md); if the input follows neither convention, append .MANUAL-TEST before .md. If there is no file (pasted text), follow the project's/user's convention for where plans live (default: .agents/plans/), derive a kebab-case <slug> from the content, and write <slug>/<slug>.MANUAL-TEST.md there. Running forked, you can't ask mid-run: flag any guessed location or slug in the final message for the user to verify.

The file must be followable by someone unfamiliar with the ticket — short but complete. Four parts:

1. What changed — 1–2 sentences: the feature and the user-visible difference.
2. How to get there — concrete navigation to the affected area (entry point, page/screen name, any prerequisite state).
3. Before vs after — how the area behaved before, how it should behave now.
4. What to verify — checklist of behaviors to confirm, including edge cases (empty values, multiple items, boundaries) where relevant.

Before writing, actually invoke explain-in-simple-language and follow it — reciting its rules from memory does not count. Not installed: plain words, one idea per sentence, and nothing named only by a stand-in the reader hasn't seen.

Do not modify any source files; the only file you write is the manual-test document.

When done, state the manual-test file's project-relative path.