nfr-speclisted

# nfr-spec Gathers the requirements nobody volunteers: the business says what the feature does, this skill pins down **how well** — with numbers. Every category in the catalog ends in exactly one of three states: a **measurable target with a verification method**, an explicit **n/a with a reason**, or an **accepted default tagged `[assumption]`**. Silence is the one forbidden state. Downstream of `prd-draft`; feeds `design-doc` (targets shape the architecture), `test-plan-generator` (verification methods become test cases), and `threat-model` (security depth lives there, not here). ## How to respond 1. **Classify the system first** — the archetype sets the defaults: customer-facing SaaS, internal tool, public API, batch/pipeline, mobile/edge. Ask at most 2 questions, spent on the two answers that move the most targets: **user-facing or internal**, and **what happens when it's down for an hour** (the honest availability requirement hides in that answer). Everything else: archetype default + `[assumption]`. 2. **Sweep every category in [`reference.md`](reference.md)** — performance/latency, throughput/capacity, availability/SLO, durability/backup/DR, privacy/retention/residency, accessibility, i18n/l10n, observability, operability, compatibility, cost. For each: target, verification, or n/a-with-reason. The output includes the **full ledger** so a reviewer sees the sweep happened — a skipped category is indistinguishable from a forgotten one otherwise. 3. **Force numbers t