Smithery Logo
MCPsSkillsDocsPricing
Login
Smithery Logo

Accelerating the Agent Economy

Resources

DocumentationPrivacy PolicySystem Status

Company

PricingAboutBlog

Connect

© 2026 Smithery. All rights reserved.

    masanao-ohba

    acceptance-criteria

    masanao-ohba/acceptance-criteria
    Planning
    2
    1 installs

    About

    SKILL.md

    Install

    Install via Skills CLI

    or add to your agent
    • Claude Code
      Claude Code
    • Codex
      Codex
    • OpenClaw
      OpenClaw
    • Cursor
      Cursor
    • Amp
      Amp
    • GitHub Copilot
      GitHub Copilot
    • Gemini CLI
      Gemini CLI
    • Kilo Code
      Kilo Code
    • Junie
      Junie
    • Replit
      Replit
    • Windsurf
      Windsurf
    • Cline
      Cline
    • Continue
      Continue
    • OpenCode
      OpenCode
    • OpenHands
      OpenHands
    • Roo Code
      Roo Code
    • Augment
      Augment
    • Goose
      Goose
    • Trae
      Trae
    • Zencoder
      Zencoder
    • Antigravity
      Antigravity
    ├─
    ├─
    └─

    About

    Defines measurable acceptance criteria using SMART principles and Given-When-Then format

    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"
    
    Recommended Servers
    vastlint - IAB XML VAST validator and linter
    vastlint - IAB XML VAST validator and linter
    OpenZeppelin
    OpenZeppelin
    Cosmetic Regulatory Intelligence
    Cosmetic Regulatory Intelligence
    Repository
    masanao-ohba/claude-manifests
    Files