acceptance-criteria-genlisted

## What It Does Turns a scoped request into testable acceptance criteria that describe observable behavior, guardrails, and failure handling without relying on implied implementation details. ## Use This When Use this when a request is entering planning or solutioning and the current brief has goals but not enough precise behavior to verify. It is especially important before stories, test mapping, or handoff artifacts are written. ## Inputs - Read the active request, tracker entry, or plan summary first. - Read the canonical module docs or feature spec that defines the current behavior. - Read `references/criteria-template.md` before drafting criteria so wording stays consistent. ## Procedure 1. Run `scripts/extract-ac-ids.sh <spec-file>` to get the set of AC ids already taken; never reuse a removed id. 2. For each new criterion, run `scripts/next-ac-id.sh <spec-file>` to allocate the next free flat id. 3. List the user-visible outcomes and constraints; convert each into one observable Given/When/Then line using `assets/output.template.md` as the shape, ending each line with an explicit `(proof: automated|manual|visual)` tag. 4. Surface negative and edge paths with the shared rubric instead of relying on the happy path alone: run `edge-case-detection` (`runtime/base/skills/edge-case-detection/SKILL.md`) over the same request as a sub-step. It is reused as-is — do not clone it — and its category set (empty, stale, loading, retry, permission, concurrency, rollback, integ