acceptance-criteria-design

Design executable acceptance criteria for approved requirements by converting goals/specs into binary pass/fail checks with observable outcomes. Use when implementation handoff, QA validation, or release decisions need testable criteria for stable `REQ-*`/`NFR-*` baselines; do not use for requirement discovery, prioritization, or sprint slicing.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "acceptance-criteria-design" with this command: npx skills add kentoshimizu/sw-agent-skills/kentoshimizu-sw-agent-skills-acceptance-criteria-design

Acceptance Criteria Design

Overview

Use this skill to translate approved requirements into acceptance criteria that engineering and QA can execute without interpretation drift.

Scope Boundaries

  • Use this skill when the task matches the trigger condition described in description.
  • Do not use this skill when the primary task falls outside this skill's domain.

Inputs To Gather

  • Approved requirements (REQ-*) and relevant non-functional requirements (NFR-*).
  • Business intent, out-of-scope boundaries, and policy constraints.
  • User-visible behaviors, system side effects, and error paths.
  • Test environment capabilities and observability limits.

Deliverables

  • Acceptance criteria set with binary pass/fail expectations.
  • Scenario matrix covering happy path, boundary, negative, and failure cases.
  • Traceability map: requirement -> criterion -> verification method.
  • Open ambiguity list that blocks objective verification.

Quality Standard

  • Each criterion is independently testable and yields one clear result.
  • Each criterion states preconditions, action, expected observable outcome, and evidence source.
  • Boundary values, invalid inputs, authorization errors, and integration failure behavior are covered when applicable.
  • Criteria describe required behavior, not implementation detail.
  • Overlap and contradiction across criteria are removed.

Workflow

  1. Normalize requirement intent and explicit assumptions.
  2. Split requirements into observable behavior units.
  3. Draft pass/fail criteria for normal, boundary, negative, and failure scenarios.
  4. Define evidence sources (API response, UI state, logs, metrics, events) for each criterion.
  5. Run ambiguity and overlap review; publish unresolved blockers.

Failure Conditions

  • Stop when requirement intent is unstable or contradictory.
  • Stop when a criterion cannot be verified with available test/observability capabilities.
  • Escalate when missing instrumentation prevents objective pass/fail judgment.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Automation

architecture-clean-architecture

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

db-logical-design

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

api-error-handling

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

documentation-rfc

No summary provided by upstream source.

Repository SourceNeeds Review