Create manual test instructions
Skill eai-org/agent-toolkit/skills/create-manual-test-instructions
Turn a ticket or requirements document into a concise QA manual-test file a non-author can follow. Invoke manually only.From its SKILL.md
npx -y skills add eai-org/agent-toolkit --skill create-manual-test-instructionsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
1.6 KB, as published. Nobody here has run it
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:
- What changed — 1–2 sentences: the feature and the user-visible difference.
- How to get there — concrete navigation to the affected area (entry point, page/screen name, any prerequisite state).
- Before vs after — how the area behaved before, how it should behave now.
- 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.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most test skills give
Counted across 1,201 of the 2,096 authors here whose files we hold, read 2026-09-06
- Write a failing test before writing codein 43 of 1201, across 36 files
- Run the full test suitein 36 of 1201, across 35 files
- Test only one variable per experimentin 34 of 1201, across 17 files
- Read product marketing context before asking questionsin 34 of 1201, across 14 files
- Mock external dependenciesin 34 of 1201, across 30 files
- Define primary, secondary, and guardrail metricsin 33 of 1201, across 16 files
- Pre-determine sample size before startingin 31 of 1201, across 14 files
- Test behavior rather than implementationin 31 of 1201, across 29 files
- Formulate a hypothesis before designing a testin 30 of 1201, across 13 files
- Document every test hypothesis, variant, and resultin 29 of 1201, across 11 files
- Use descriptive test function namesin 25 of 1201, across 21 files
- Commit to the methodology without stopping earlyin 24 of 1201, across 8 files
Said here and by no other author read
- Read the input ticket or requirements document
- Write the manual test file in the same directory
- Name the file using the manual test convention
- Write the file for someone unfamiliar with the ticket
- Include what changed in one to two sentences
- Provide concrete navigation to the affected area
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.