joris887
joris887/exosuit
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/joris887/exosuit --skill manual-test命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Execute comprehensive backlog review. Analyzes story quality, Definition of Ready compliance, dependencies, zombie stories, and generates a backlog health report.
First-run framework setup. Detects existing project stack or guides new project creation from vision/braindump.
Use when the user has a complex idea that needs design exploration before story decomposition.
基于 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.