smithery/masanao-ohba

acceptance-criteria

Invoke when goal-clarifier produces acceptance criteria for a task. Provides SMART-formatted criteria with Given-When-Then scenarios, verification methods, and priority levels that feed into the task object contract.

Installation

$ npx skills add smithery/masanao-ohba --skill acceptance-criteria

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/masanao-ohba.

npx skills add smithery/masanao-ohba

Browse all from smithery/masanao-ohba

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,469 B
  • docs SUMMARY.md 115 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Acceptance Criteria

A technology-agnostic skill for defining clear, measurable acceptance criteria.

Core Purpose

Transform requirements into verifiable acceptance criteria that:

  • Are specific and unambiguous
  • Can be objectively measured
  • Guide implementation
  • Enable evaluation

Acceptance Criteria Format

Given-When-Then (GWT)

format: given_when_then
structure:
  given: "Initial context or precondition"
  when: "Action or trigger"
  then: "Expected outcome or result"

example:
  given: "User is logged in with valid credentials"
  when: "User clicks the 'Export' button"
  then: "System generates a CSV file with all user data"

SMART Criteria

specific:
  definition: "Clear and unambiguous"
  bad: "System should be fast"
  good: "API response time under 200ms for 95% of requests"

measurable:
  definition: "Quantifiable outcome"
  bad: "Good test coverage"
  good: "Test coverage >= 80%"

achievable:
  definition: "Technically feasible"
  check: "Can this be implemented with current resources?"

relevant:
  definition: "Aligned with business goals"
  check: "Does this contribute to user value?"

time_bound:
  definition: "Has clear completion point"
  check: "When is this considered done?"

Criteria Categories

Functional Criteria

type: functional
focus: "What the system must do"

templates:
  - "User can [action] to [achieve outcome]"
  - "System [processes/calculates/displays] [data] when [trigger]"
  - "Given [state], when [action], then [result]"

examples:
  - criteria: "User can reset password via email"
    given: "User has registered email"
    when: "User requests password reset"
    then: "Reset link sent within 5 minutes"

Non-Functional Criteria

type: non_functional
focus: "How the system should perform"

categories:
  performance:
    - "Response time < 200ms"
    - "Supports 1000 concurrent users"

  security:
    - "All passwords hashed with bcrypt"
    - "No SQL injection vulnerabilities"

  reliability:
    - "99.9% uptime"
    - "Automatic failover within 30s"

  usability:
    - "Form can be completed in < 2 minutes"
    - "Error messages are descriptive"

Quality Criteria

type: quality
focus: "Code and implementation standards"

categories:
  code_standards:
    - "No linting errors"
    - "All functions documented"

  test_coverage:
    - "Unit test coverage >= 80%"
    - "All edge cases tested"

  maintainability:
    - "Cyclomatic complexity < 10"
    - "No duplicate code blocks"

Criteria Generation Process

Step 1: Extract Requirements

from_user_request:
  - Identify explicit requirements
  - Infer implicit requirements
  - Note constraints

from_goals:
  - Map achievement indicators to criteria
  - Define verification methods

Step 2: Transform to Criteria

for_each_requirement:
  - Define specific outcome
  - Add measurable threshold
  - Specify verification method
  - Assign priority

Step 3: Validate Criteria

validation_checklist:
  - [ ] Is it specific enough to implement?
  - [ ] Can it be objectively measured?
  - [ ] Is it achievable with current resources?
  - [ ] Does it align with user value?
  - [ ] Is the scope bounded?

Output Format

acceptance_criteria:
  functional:
    - id: "AC-FUNC-001"
      description: "User login functionality"
      given: "User has valid credentials"
      when: "User submits login form"
      then: "User is authenticated and redirected to dashboard"
      priority: must
      verification: "Integration test"

  non_functional:
    - id: "AC-PERF-001"
      description: "Login response time"
      criterion: "Login completes within 2 seconds"
      threshold: "< 2000ms"
      priority: should
      verification: "Load test"

  quality:
    - id: "AC-QUAL-001"
      description: "Code coverage"
      criterion: "Test coverage for auth module"
      threshold: ">= 80%"
      priority: must
      verification: "Coverage report"

Integration

Used By Agents

primary_users:
  - goal-clarifier: "Criteria generation"

secondary_users:
  - deliverable-evaluator: "Evaluation reference"