create-manual-test-instructions

Solid

Turn a ticket or requirements document into a concise QA manual-test file a non-author can follow. Invoke manually only.

Testing & QA 46 stars 6 forks Updated today MIT

Install

View on GitHub

Quality Score: 86/100

Stars 20%
56
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
71
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# 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. 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**.

Details

Author
eai-org
Repository
eai-org/agent-toolkit
Created
3 months ago
Last Updated
today
Language
Shell
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Listed

create-manual-test-guide

Generate a self-contained HTML manual-testing guide for an implemented change — environment setup, a visual test-flow diagram, step-by-step scenarios with expected results, and interactive pass/fail checkboxes with a Markdown results export. Use when the user wants to verify an implementation by hand, asks "how do I test this", or wants a verification document for a feature/branch/PR.

2 Updated today
atman-33
Testing & QA Listed

writing-qa-test-instructions

Decides whether a ticket is manually testable by non-developers and writes the German QA test instructions for the Linear comment. Defines the three-part testability test, the not-testable categories, the deployed-environment URL resolution order, the role-instead-of-credentials rule, and the comment format for both cases. Activates whenever a command hands a merged or submitted ticket to QA (ticket-cycle, git:ship, dev-submit). NOT for the developer-facing local re-test manual with literal passwords (that is ticket-cycle STEP 3b). NOT for the browser walk itself (use validating-changes-in-browser).

0 Updated 3 days ago
lenneTech
Testing & QA Featured

manual-test-planning

Produce a plain-language manual test plan from the context supplied to it — an executive summary, a high-level list of named tests, and a detail section per test with the steps a person follows by hand and the outcomes they should expect. Use when you want to create, draft, generate, or outline a manual test plan, manual QA steps, hands-on verification steps, or an acceptance walkthrough for a feature, change, branch, plan, or PR. When the plan holds more than five tests and at least two natural categories emerge, both the test list and the detail sections are organized under plain-language categories. When nothing in the supplied context can be manually tested, it says so and asks for more context instead of producing a document. Does not analyze code for automated test coverage gaps — use automated-test-planning. Does not write test code — use tdd. Does not review code quality — use code-review. Does not stress-test an existing plan — use iterative-plan-review.

263 Updated today
testdouble