← ClaudeAtlas

us-reviewlisted

Verify that an ingested user story was correctly extracted - restructure it (story, acceptance criteria, business rules, open points) and have the user confirm or fix the extraction. Use right after ingesting a US, and whenever someone asks whether a specification was read faithfully, whether acceptance criteria were missed, or wants to check an extraction before designing tests on top of it. Second step of the QAIA journey, after us-ingest.
QAIA-Project/QAIA · ★ 0 · Testing & QA · score 64
Install: claude install-skill QAIA-Project/QAIA
# us-review — extraction check Follow the shared contract in `../README.md`. Prerequisite: `00-source.md` (else offer `us-ingest`). ## Steps 1. **Structure the capture.** From `00-source.md`, produce a structured extraction: - **Story** — As a / I want / So that, quoted or faithfully paraphrased if present. If absent but a real capability is described, **reconstruct it and mark it `[reconstructed]`**; otherwise write "not expressed in the source". - **Numbered acceptance criteria**, quoted or faithfully paraphrased. - **Business rules and constraints** found outside the AC list. - **Referenced artifacts not analyzed** — attachments, mockups, links. - **Anything present in the source but not classifiable** — keep it visible, never drop content. The `[reconstructed]` marker is what makes a reconstruction legitimate. A story the reader believes came from the source, when in fact you wrote it, silently turns your interpretation into the requirement everything downstream is tested against. **Mentioning it in prose is not enough**: the marker sits on the artifact itself, where the next step reads it. 2. **Show the diff mentality.** Present the structure and explicitly list what you did **not** find — no AC numbering, no story, and so on. Do not invent missing parts. - **If the extraction has no acceptance criteria and no described behavior at all** (a design doc, an RFC, an empty template, a non-spec): say so plainly and r