Sweep a feature or system through the full non-functional requirements catalog — performance, throughput, availability, durability, privacy/retention, accessibility, i18n, observability, operability, compatibility, cost — forcing every category to a measurable target, an explicit n/a, or a tagged default. Use when the user needs NFRs, quality attributes, "how fast/reliable does it need to be", SLO targets for a feature, or the requirements everyone forgets until they're incidents.
In Claude Code, with the solution-architect plugin installed, invoke it as:
/solution-architect:nfr-spec
Try it
A realistic prompt from the skill's acceptance evals:
Sweep the non-functional requirements for our new checkout service.
What a good result looks like
Every category lands in one of three states — target, n/a-with-reason, or tagged default. The ledger shows all of them; silence fails the doc.
Every target has a percentile, a load condition, and a verification. A latency number without load is a screenshot of a quiet day.
Availability matches the down-for-an-hour answer, not the marketing instinct. The cost of each extra nine is named when the target exceeds the archetype default.
Every data class has a retention period and a deletion mechanism. "Indefinite" is written as the decision it is.
Accessibility names level and scope — "WCAG 2.2 AA on all agent-facing screens, axe + manual screen-reader pass" — not "accessible".
Cost has a number at target volume, or a tagged [assumption] placeholder that explicitly hands the sizing to capacity-cost-model. Either way the line is present — an NFR spec that's silent on cost has delegated it to the first invoice.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 66% of its checks, against 45% without it, and a blind judge preferred it. How skills are checked
18 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Every category in the catalog lands in one of three states — a target, not-applicable with a reason, or a tagged default; silence in any category is a failure
Every target states a percentile, a load condition, and how it will be verified — a latency number with no load condition is rejected
The availability target matches the honest answer to what an hour of downtime costs, not a marketing instinct
Privacy and retention are given concrete periods rather than 'per policy'
The output is a reviewable ledger covering all categories, not a prose paragraph about quality
Points out that 2,000 bookings a day does not imply 500 requests per second, and bases the load target on the evidence given (the 1 March opening rush of 6,000 bookings in the first hour)
Replaces '100% of the time' with a measurable availability target and explains why 100% is not a usable requirement
Requires ramp scanning to keep working when the mobile signal drops out at Harrick pier and Saltness slipway
Flags the conflict between keeping passenger details forever and the 3-year manifest deletion and marketing opt-in rules, and does not adopt 'forever'
Does not treat accessibility as not applicable, given passengers must be able to request an accessible space
Does not invent facts about the business not in the brief; any figure not derived from it is marked as an assumption
Fits within two pages
Answers with bullets the owner can pass on directly, without asking questions first
Uses plain English; any technical term is explained or avoided
Gives concrete, checkable targets (for example a page-load time or how much downtime is acceptable) rather than only words like 'fast' or 'reliable'
Covers looking after customers' personal and payment details
Marks figures as suggestions to confirm, and does not state facts about the bakery (order volumes, opening hours, prices) that were not given
Stays to a few bullets (roughly 10 or fewer)
When it should and shouldn't activate
Should activate:
What are the non-functional requirements for this service?
Sweep the NFRs — latency, availability, privacy, accessibility, operability
Set performance and availability targets for this feature
We keep forgetting the -ilities; give me the full NFR ledger
Should leave to another skill:
Write the functional requirements and user stories
Draft the OpenAPI contract for this service
Design the dashboards, SLOs, and alerts we should build
Model the capacity and cost for this workload
Hands off to
design-doc — when the quality targets are set. Design against the stated numbers rather than against taste.
threat-model — when the design has a trust boundary worth attacking. Attack the design before it is ratified.
test-plan-generator — when the targets need verifying, not just stating. Turn each quality target into a coverage entry.