Criteria

---
name: criteria
description: Draft test-ready acceptance criteria (a recette checklist) from a Requivo session's model, in this Claude session, and save them as a tracked artifact. Use when the user wants Given/When/Then scenarios a QA engineer can run and a client can sign off on.
allowed-tools: Bash(requivo doctor:*), Bash(requivo model show:*), Bash(requivo status:*), Bash(requivo artifact save:*), Read
---

# /requivo:criteria

Write **acceptance criteria** — a test-ready specification a QA engineer can run against the built
feature and a client can sign off on. **You** write it; Requivo tracks the document. This mirrors
`src/requivo/assets/prompts/criteria.md` and the `AcceptanceCriteria` contract in `core/contracts.py`,
at commit `969cfd9` — the same rules the CLI's `requivo criteria` gives its own reasoning call,
restated here because the plugin cannot import that file at runtime (`decision:
plugin-skills-mirror-a-pinned-cli-commit`). Read `${CLAUDE_PLUGIN_ROOT}/REASONING.md` unless you already hold it from an earlier
`/requivo:*` in this conversation — and read it again whenever you are unsure you still do.

## 0. Preflight
Run the shared **preflight** from REASONING.md before anything else: `requivo doctor --json`, checking
whether the command ran *at all* rather than what it reported. If it could not run, the `requivo` CLI
is not installed — follow REASONING.md's missing-CLI flow. Nothing has been saved at this
point, so there is no half-written checklist to find.

## 1. Load the model
```
requivo model show <slug>
requivo status <slug> --json
```
Note the `revision` — call it `N`. It is the model these criteria will rest on, and you will state it
when you save.

## 2. Reason → write the checklist
- Write scenarios in **Given / When / Then** form: `given` is the starting state, `when` is the single
  triggering action, `then` is the observable outcomes to check — either can hold more than one line
  when the scenario genuinely needs it (a precondition with two parts, an outcome with two effects);
  write the first as **Given**/**Then** and every one after it as **And**, the same convention
  `criteria_markdown` renders with.
- Group scenarios under **features** — one per coherent area of behaviour (a workflow step, a business
  rule set, a permission boundary), named in business terms.
- Each scenario has an id (`AC-1`, `AC-2`, … — unique across the whole document, not per feature), a
  title, and a kind: `happy_path`, `edge_case`, `error`, or `permission`.
- **Cover where it matters, not everything.** Prioritise business rules, permission boundaries, and
  edge cases that would actually break the feature or the client's trust. A happy path plus its
  meaningful failure modes beats twenty trivial checks.
- Use only what the model supports. Where it is thin or uncertain about a behaviour, do **not** invent
  a definitive criterion — put the open point in `open_questions` instead. A criterion QA can't
  objectively pass or fail is worthless, and every `then` must be observable and checkable. A
  behaviour the model holds as a proposal or a domain fact (`proposed:` or `domain:` evidence) gets a
  scenario tagged from REASONING.md's *Source tags*, expected and to confirm; a new proposal of yours
  is an open question carrying your recommendation.
- Honour `confidence` and `impact`: `explicit` → a firm scenario; `inferred` → phrase the `then` as
  *expected, to confirm*, or route it to `open_questions`; `empty` + high impact → `open_questions`,
  never a definitive AC; `empty` + low impact → a non-blocking open question or leave it out.
- **Never collapse an open fork into one AC.** Where two behaviours are both plausible and unconfirmed,
  list the choice in `open_questions` — never assert one side as the criterion.
- Fold in the model's reasoning layer where present: `decisions` become criteria for the decided path
  (note the tradeoff, don't re-open it); an unresolved `challenges` entry is an `open_question`
  presenting the alternative, never a definitive AC that silently picks a side.

**Voice.** Write for QA and a client — no slot ids, completeness percentages, or confidence labels
(explicit/inferred/empty) in the prose. Say the business thing; this calibration is invisible to the
reader, never printed as a label.

**Language.** Criteria anchor English whatever language the request arrived in — they feed dev teams
and trackers, unlike the mirrored conversation (`docs/requirements-model.md`, *The language of the
outputs*).

Write it as Markdown:
```
# <Title>

> Acceptance criteria — generated by Requivo

## <Feature name>

### [ ] AC-1 — <title>  _<Happy path | Edge case | Error | Permission>_

- **Given** <precondition>
- **And** <a second precondition, only if there is one — repeat for a third, and so on>
- **When** <action>
- **Then** <outcome>
- **And** <a second outcome, only if there is one — repeat for a third, and so on>

## Open questions

- <open question>
```

## 3. Save it as a tracked artifact
```
requivo artifact save <slug> --type criteria --file - --revision N --json
```
`--revision N` is the revision you read in step 1. Read `stale` back from the save output: if it is
`true`, the model moved while you were writing — say so plainly and offer to redo it.

## 4. Point at the next step, once
The same model turned into a work breakdown is `/requivo:epic <slug>` — the delivery epic a dev team
tracks and ships. If a scenario surfaced a gap the model should record, `/requivo:run <slug>` is
where that goes back in.