メニュー
Prepare for manual testing session with test plan based on known issues, recent changes, and acceptance criteria.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/joris887/exosuit --skill manual-testコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | manual-test |
| version | 2.4.0 |
| description | Prepare for manual testing session with test plan based on known issues, recent changes, and acceptance criteria. |
| trigger | manual |
| depends-on | [] |
| references | [] |
| disable-model-invocation | true |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Bash |
Preparing manual test session...
Read these files to understand what to test:
# What changed recently (last 20 commits or since last tag)
git log --oneline -20
git diff --stat HEAD~10
Identify which areas of the project were modified and map to testable features.
Check the backlog for known gaps and bugs that are still TODO:
docs/reference/backlog/docs/progress.md for latest sprint infodocs/sprints/ for recent sprint specs with acceptance criteriadocs/testing/UAT_COVERAGE.md (if it exists) for test case statusdocs/context/personas.md (if it exists) for lean persona cards — these provide CONTEXT, GOALS, FRUSTRATIONS, BEHAVIORS, EVALUATES BY, and FAILURE LOOKS LIKE fields that directly inform exploratory testing in Phase 3Cdocs/reference/PRD_SUMMARY.md (if it exists) for success criteria and user flowsBefore manual testing, verify the system is ready:
Run the project's test command (from CLAUDE.md) to ensure automated tests pass.
If pre-flight fails, fix issues before proceeding to manual testing.
Generate a structured test plan covering three areas:
Based on the git diff, generate specific test scenarios for recently modified code:
#### Regression: [Area changed]
- [ ] **Scenario**: [What to test] — : [How to test] — : [What should happen]
For each recently fixed issue, generate a verification test:
#### Verify Fix: [Story ID] — [Title]
- [ ] [Specific step to verify the fix still works]
For each open issue, note it as a known limitation:
#### Known Limitation: [Story ID] — [Title]
- Warning: [Brief description] — skip testing this area
Based on architecture and project knowledge, suggest areas to probe.
If personas.md was loaded: Structure exploratory testing around each persona. For each persona, create scenarios that exercise their GOALS, probe their FRUSTRATIONS, use their CONTEXT constraints, and check for their FAILURE LOOKS LIKE scenarios. Apply their EVALUATES BY questions to each tested feature.
If only PRD_SUMMARY.md was loaded (no personas.md): Structure exploratory testing around each persona from PRD Section 2. For each persona, create scenarios that exercise their primary goal, pain points, and constraints.
Example: a persona with "low connectivity" context → test offline/slow-network behavior. A persona with "screen reader" context → test keyboard navigation and ARIA labels. A persona with "FAILURE LOOKS LIKE: gets stuck on jargon-filled error messages" → verify all error messages are plain English.
#### Exploratory: [Feature Area] (as [Persona Name])
- [ ] [Step 1 — what to do and what to look for, from persona's perspective]
- [ ] [Step 2]
#### Exploratory: Error Handling
- [ ] [Provoke an error condition and verify graceful handling]
#### Exploratory: Edge Cases
- [ ] [Test boundary conditions, empty states, large inputs]
Output the complete test plan:
## Manual Test Plan — [Date]
### Environment
- [List required services, tools, and their status]
### A. Regression Tests ([count] scenarios)
[generated scenarios]
### B. Known Issue Checks
**Verified fixes**: [count]
**Known limitations**: [count]
[generated checks]
### C. Exploratory Testing ([count] areas)
[generated areas]
### How to Report Findings
Use `/testing-cycle <description of what you found>` for each issue.
This will classify it and handle it through the right process.
For structured UAT, use `/UAT-cycle <test-case-id>` to execute formal test cases.
Tell the user:
The test plan is ready. Start the application if not already running, then work through the checklist. Report each finding with
/testing-cycle <feedback>. When done, wrap up with/sprint-end.
Do not proceed until user reports back.