{
  "schema_version": 2,
  "kind": "shortening-method",
  "format": "agent-skill",
  "id": "acceptance-criteria",
  "name": "Acceptance criteria",
  "category": "Work",
  "summary": "Compress existing acceptance conditions without weakening boundaries or checks.",
  "use_cases": [
    "Acceptance test lists",
    "Story completion criteria",
    "QA handoff criteria"
  ],
  "word_count": 153,
  "url": "https://sho.rten.it/methods/acceptance-criteria/",
  "instructions_url": "https://sho.rten.it/methods/acceptance-criteria/SKILL.md",
  "skill_url": "https://sho.rten.it/methods/acceptance-criteria/SKILL.md",
  "json_url": "https://sho.rten.it/methods/acceptance-criteria/llms.txt",
  "plain_text_url": "https://sho.rten.it/methods/acceptance-criteria/prompt.txt",
  "license": "MIT",
  "sources_url": "https://sho.rten.it/sources/#acceptance-criteria",
  "skill_name": "acceptance-criteria",
  "skill_description": "Compress existing acceptance conditions without weakening boundaries or checks. Use for Acceptance test lists, Story completion criteria, QA handoff criteria.",
  "agents_md_url": "https://sho.rten.it/methods/acceptance-criteria/AGENTS.md",
  "sources": [],
  "instructions": "Condense supplied acceptance criteria or testable requirements into the smallest clear set of checks. Use this to remove repetition from stated conditions, not to invent test coverage or decide what the product should do.\n\nGroup checks that share an actor and precondition, but retain distinct outcomes. Keep exact values, inclusive boundaries, roles, states, timings, error behavior, and requirements for persistence or side effects. Preserve identifiers so each condensed check can be traced to its source.\n\nUse \"Given / When / Then\" only where it clarifies a conditional behavior; otherwise use short checklist items. State the expected observable result, not vague judgments such as \"works correctly\". Do not turn an example value into the only accepted value or replace several edge conditions with \"handles errors\".\n\nFlag a condition that lacks a required expected result. Keep unresolved requirements separate from accepted checks. Return only the condensed criteria and any unresolved gaps, without adding implementation steps.",
  "example": {
    "before": "AC1: Given a signed-in editor is creating a label, when they enter a name of between 1 and 40 characters inclusive and save, then the label is created. AC2: If that same editor leaves the name empty and presses Save, the system must show \"Enter a name\" and must not create a label. AC3: If the editor enters 41 or more characters and presses Save, the system must show \"Use 40 characters or fewer\" and must not create a label. AC4: A signed-in viewer cannot create a label and must not be shown the Save button. These four criteria repeat that no existing labels should be changed by a create attempt. AC5 is still open: the team has not decided whether names that differ only in letter case count as duplicates. The reviewer noted that the criteria should be easy to read.",
    "after": "Label creation\n- AC1, editor: Saving 1–40 characters inclusive creates a label.\n- AC2, editor: Saving an empty name shows \"Enter a name\"; no label is created.\n- AC3, editor: Saving 41+ characters shows \"Use 40 characters or fewer\"; no label is created.\n- AC4, viewer: Cannot create a label; Save is not shown.\n- AC1–AC4: Users are signed in. No create attempt changes existing labels.\n\nOpen — AC5: Whether name uniqueness ignores letter case is undecided.",
    "context": "Label creation acceptance checks",
    "must_preserve": [
      "Signed-in users; editor versus viewer permissions",
      "AC1 inclusive 1–40; create success",
      "AC2 empty and exact error; no creation",
      "AC3 41+ and exact error; no creation",
      "AC4 cannot create and no Save button",
      "No existing-label changes on any attempt",
      "AC5 case-insensitive uniqueness undecided"
    ],
    "omitted": [
      "Repeated shared preconditions and general readability comment"
    ],
    "kind": "illustrative"
  }
}