القائمة
Use when defining testable criteria that determine whether a requirement is met
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when a bug, failing test, regression, or unexpected behavior needs a root-cause-first debugging loop before code changes, especially when brownfield seams, recent releases, or historical defect matches make guesswork unsafe.
Use when E2E tests must go beyond shallow happy-path checks — multi-step user journeys, stateful sessions, cross-boundary state consistency, failure-mode edges — or when the suite passes but production still breaks. Platform- and framework-agnostic (web, mobile, desktop; Playwright, XCUITest, Cypress).
Use when discovery has narrowed an idea enough that the team must make a go/no-go, pivot, or scope-down decision based on technical, economic, operational, or timeline viability before requirements, architecture, or major implementation.
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
Use when discovery needs evidence about market demand, competitors, pricing pressure, or underserved segments for a new product or expansion idea before feasibility, user research, or requirements are finalized.
Use when intake has identified the likely lifecycle path but the problem statement, solution direction, or key trade-offs are still too fuzzy for requirements, research, or architecture work to start cleanly
| name | pc-acceptance-criteria |
| description | Use when defining testable criteria that determine whether a requirement is met |
| metadata | {"phase":"01-specification","inputs":["requirements-doc","spec-doc"],"outputs":["acceptance-criteria-set"],"prerequisites":["pc-requirements-engineering"],"quality_gate":"Every P0/P1 requirement has at least one acceptance criterion, QA team has reviewed","roles":["product-manager","qa-engineer"],"methodologies":["all"],"effort":"medium"} |
If you can't test it, you can't ship it. Acceptance criteria make requirements verifiable.
Acceptance criteria bridge the gap between "what we want" (requirements) and "how we verify it works" (tests).
See context and anti-pattern notes.
I/O contract notes define required inputs and authority.
Use Given-When-Then (Gherkin) for behavior-driven criteria:
Given [precondition]
When [action]
Then [expected result]
Or use checklist format for simpler requirements:
- [ ] User can reset password via email link
- [ ] Link expires after 24 hours
- [ ] User sees error if link is expired
For each requirement, write criteria for:
Bad: "Page loads quickly" Good: "Page loads in under 2 seconds on 3G connection with 95th percentile"
Bad: "System handles many users" Good: "System supports 500 concurrent users with < 200ms response time at p95"
QA engineers are expert at finding missing edge cases. Review criteria with them before finalizing. They should be able to write test cases directly from acceptance criteria.
Produce only declared outputs at their documented quality boundary.