product-test
Use to turn a PRD section, user story, feature slice, or behavior description into product test scenarios and pass/fail conditions.
What this skill does
Product Test
Use this skill to define the observable behavior that must be true for a story or feature to be considered done. It turns product context into concise, testable Given/When/Then scenarios that engineers and QA can verify without guessing intent.
Do not use this skill to write a full PRD, redesign the feature, break work into engineering tasks, write implementation plans, run tests, write automation code, or create exhaustive test suites. Stay focused on product-level acceptance scenarios for a specific story, feature slice, or behavior.
When To Use
- A user story, PRD section, or feature slice already exists.
- The team needs clear pass/fail conditions before or during implementation.
- QA needs explicit happy path, edge case, error state, or non-functional scenarios.
- A story is too vague and needs observable done conditions.
If the feature scope is unclear, ask for the smallest missing context before drafting criteria.
Instructions
- Confirm the slice: identify the exact story, workflow, user role, or behavior being accepted.
- Capture inputs and assumptions: list source material, scope boundaries, and missing context.
- Separate scenario types: cover happy path first, then edge cases, error states, and non-functional expectations.
- Use Given/When/Then only: each criterion should be independently testable and observable.
- Describe recovery behavior: when validation fails or a dependency breaks, state what the user sees and how they can recover.
- Avoid implementation leakage: do not mention internal classes, tables, functions, or code paths unless the acceptance surface is technical by nature.
- Review for pass/fail clarity: rewrite subjective criteria into measurable outcomes.
- End with handoff: state what is ready for QA or the implementation team and what still needs clarification.
Output Format
Use references/product-test-template.md as the default structure. Keep scenarios concise and avoid duplicate coverage.
Required Boundaries
- Do not invent product behavior that is not implied by the source material. Mark assumptions clearly.
- Do not convert every possible test case into acceptance criteria; focus on story-level pass/fail behavior.
- Do not include implementation instructions, file names, commands, or detailed QA automation steps.
- Do not use vague outcomes such as "works correctly" or "is user-friendly"; make the observable result explicit.
- If current legal, pricing, policy, or platform behavior affects acceptance, verify sources before relying on it.
Quality Checklist
Before finalizing, verify:
- Criteria map to a specific story, feature slice, or behavior.
- Happy path appears before edge cases and error states.
- Each criterion has one clear observable outcome.
- Error states include user-visible recovery behavior.
- Non-functional criteria are included when relevant.
- Assumptions and open questions are visible.
- No implementation details leak into acceptance criteria.
Files in this skill
- references/product-test-template.md
- SKILL.md
How to use in Orkas
Open the Orkas desktop app, go to the marketplace, and install this item with one click. Don't have Orkas yet? Download Orkas.
用于将 PRD 片段、用户故事、功能切片或行为描述转成产品测试场景和通过/失败条件；适合\"给这个需求写产品测试\"\"给这个需求写验收标准\"\"把这个 story 转成 Given/When/Then\"\"补齐 QA 可测场景、边界条件、错误状态和非功能验收\"；触发词：产品测试、验收测试、验收标准、Given When Then、QA交接、测试场景、用户故事、边界条件、错误状态、通过条件
该技能的功能
Product Test
Use this skill to define the observable behavior that must be true for a story or feature to be considered done. It turns product context into concise, testable Given/When/Then scenarios that engineers and QA can verify without guessing intent.
Do not use this skill to write a full PRD, redesign the feature, break work into engineering tasks, write implementation plans, run tests, write automation code, or create exhaustive test suites. Stay focused on product-level acceptance scenarios for a specific story, feature slice, or behavior.
When To Use
- A user story, PRD section, or feature slice already exists.
- The team needs clear pass/fail conditions before or during implementation.
- QA needs explicit happy path, edge case, error state, or non-functional scenarios.
- A story is too vague and needs observable done conditions.
If the feature scope is unclear, ask for the smallest missing context before drafting criteria.
Instructions
- Confirm the slice: identify the exact story, workflow, user role, or behavior being accepted.
- Capture inputs and assumptions: list source material, scope boundaries, and missing context.
- Separate scenario types: cover happy path first, then edge cases, error states, and non-functional expectations.
- Use Given/When/Then only: each criterion should be independently testable and observable.
- Describe recovery behavior: when validation fails or a dependency breaks, state what the user sees and how they can recover.
- Avoid implementation leakage: do not mention internal classes, tables, functions, or code paths unless the acceptance surface is technical by nature.
- Review for pass/fail clarity: rewrite subjective criteria into measurable outcomes.
- End with handoff: state what is ready for QA or the implementation team and what still needs clarification.
Output Format
Use references/product-test-template.md as the default structure. Keep scenarios concise and avoid duplicate coverage.
Required Boundaries
- Do not invent product behavior that is not implied by the source material. Mark assumptions clearly.
- Do not convert every possible test case into acceptance criteria; focus on story-level pass/fail behavior.
- Do not include implementation instructions, file names, commands, or detailed QA automation steps.
- Do not use vague outcomes such as "works correctly" or "is user-friendly"; make the observable result explicit.
- If current legal, pricing, policy, or platform behavior affects acceptance, verify sources before relying on it.
Quality Checklist
Before finalizing, verify:
- Criteria map to a specific story, feature slice, or behavior.
- Happy path appears before edge cases and error states.
- Each criterion has one clear observable outcome.
- Error states include user-visible recovery behavior.
- Non-functional criteria are included when relevant.
- Assumptions and open questions are visible.
- No implementation details leak into acceptance criteria.
技能包含的文件
- references/product-test-template.md
- SKILL.md
如何在 Orkas 中使用
打开 Orkas 桌面应用，进入市场，一键安装此项。还没有 Orkas？ 下载 Orkas.