Reads a PRD, design doc, or product brief and pulls out the non-functional requirements (performance, accessibility, security, internationalization, reliability, observability) as concrete, threshold-bound, testable assertions. Maps every NFR to its measurement source (Lighthouse, axe, OWASP ASVS, WCAG criterion, etc.) so the test suite knows what to assert against. Use after gherkin-from-stories (qa-bdd) handles functional requirements.
日本語の概要は準備中です。原文の説明を表示しています。
実行スコア 未検証
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
ISTQB defines non-functional testing as "A test type to evaluate that a component or system complies with non-functional requirements" (istqb-nft). The eight ISO/IEC 25010:2011 product-quality characteristics define the canonical NFR categories (cite by stable standard ID; iso.org is paywalled / Cloudflare-protected):
| ISO/IEC 25010 characteristic | Common shorthand | This skill covers |
|---|---|---|
| Functional Suitability | functional | (out - handled by gherkin-from-stories in qa-bdd) |
| Performance Efficiency | performance / perf | yes |
| Compatibility | compatibility | yes |
| Usability | a11y / UX | yes (a11y subset) |
| Reliability | reliability | yes |
| Security | security | yes |
| Maintainability | (developer-facing) | (out) |
| Portability | (developer-facing) | (out) |
Plus two practitioner-emergent NFR families that are increasingly treated as first-class:
| Family | Source |
|---|---|
| Internationalization (i18n) | W3C i18n best practices |
| Observability | DORA / SRE practitioner literature |
Acceptance-criteria-extractor handles functional requirements (Given/When/Then). This skill handles everything else - the threshold-and-measurement requirements that don't fit Gherkin's shape.
gherkin-from-stories (qa-bdd); this skill takes everything else.Per family, look for the canonical signal phrases:
| Family | Signal phrases |
|---|---|
| Performance | "fast", "responsive", "within Xms", "p95", "throughput", "latency", "time to" |
| Accessibility | "WCAG", "screen reader", "keyboard navigation", "color contrast", "ARIA" |
| Security | "auth", "encrypt", "OWASP", "CSP", "rate limit", "secret" |
| Compatibility | "browser", "iOS", "Android", "version", "device" |
| Reliability | "uptime", "SLO", "SLA", "graceful degradation", "circuit breaker", "retry" |
| Internationalization | "locale", "RTL", "translation", "Unicode", "timezone" |
| Observability | "metric", "log", "trace", "alert", "dashboard" |
Each signal becomes a candidate NFR - but NOT every signal is testable as authored. Run each through Step 2.
Per ISTQB testability (istqb-testability), an NFR is testable only when it has:
| Untestable NFR | Threshold-bound rewrite |
|---|---|
| "The site should be fast" | "p95 page-load time on /dashboard is ≤2.5s, measured by Lighthouse CI under 4G throttling." |
| "Accessible to screen reader users" | "WCAG 2.2 AA conformance on /checkout; axe-core scan returns zero serious or critical violations." |
| "Secure against attacks" | "OWASP ASVS Level 2 controls 1-7; verified by npm audit --audit-level=high exit zero AND ZAP baseline scan zero alerts." |
| "Works on all browsers" | "Functional E2E tests pass on Chrome ≥120, Firefox ≥120, Safari ≥17 (latest two majors per WebRumStats data)." |
| "Highly available" | "Uptime ≥99.9% measured monthly via external prober; recovery from any single-AZ failure ≤5 min." |
The agent never fabricates a threshold. If the doc says "fast" without a number, the agent emits an explicit question ("What's the target p95? Common defaults: 2.5s for landing, 1.5s for cached, 200ms for API."), it does not invent 2.5s.
Each NFR must name how it's measured. Look up the canonical source for its family in references/measurement-sources.md, which catalogs sources for Performance (Web Vitals, k6), Accessibility (WCAG 2.2, axe-core), Security (OWASP ASVS, ZAP), Compatibility (MDN, Can I use), Reliability (Google SRE Workbook), and Internationalization (W3C i18n, Unicode CLDR).
Load-bearing defaults - Web Vitals: LCP ≤2.5s, INP ≤200ms,
CLS ≤0.1. Per-criterion a11y citations use the WCAG SC ID format
(WCAG 2.2 SC 1.4.3 Contrast (Minimum)) so the test report
back-references the standard.
# NFRs extracted from `<doc-id>`
**Source doc:** `<path or URL>`
**Date extracted:** YYYY-MM-DD
**NFRs found:** N
**Threshold gaps flagged:** M
## Performance
| ID | Requirement | Threshold | Measurement | Scope |
|-------|------------------------------------------------------------|-----------|-------------|----------------------|
| PRF-1 | LCP on /dashboard | ≤2.5s | Lighthouse CI; Web Vitals 75th-percentile field data | logged-in user, 4G, 1280x800 |
| PRF-2 | p95 latency on POST /api/orders | ≤200ms | k6 load test, 50 RPS for 5 min | production-like staging |
## Accessibility
| ID | Requirement | Threshold | Measurement | Scope |
|-------|------------------------------------------------------------|------------------|-------------|------------------|
| A11Y-1| WCAG 2.2 AA conformance | zero serious/critical violations | axe-core scan | every page in app sitemap |
## Security
| ID | Requirement | Threshold | Measurement | Scope |
|-------|------------------------------------------------------------|------------------|-------------|------------------------|
| SEC-1 | No high-severity dependency vulnerabilities | zero high/critical | npm audit --audit-level=high | every PR; production deps |
| SEC-2 | OWASP ASVS Level 2 baseline | pass | ZAP baseline scan + manual ASVS checklist | release readiness gate |
## Compatibility / i18n / Reliability / Observability
(similar tables, only included when the source doc raised them)
## Threshold gaps (HUMAN INPUT REQUIRED)
| Vague phrase | Where in doc | Suggested concretization |
|------------------------------------|-----------------------|----------------------------------------------------------------|
| "fast checkout" | line 12 | LCP ≤1.5s (typical for cached transactional flow)? |
| "supports global users" | line 28 | Locale list? RTL support? Timezone handling? Unicode in fields? |
The agent does NOT pick the answers - author must confirm.
A team submits a checkout PRD. The skill runs it through two passes.
Pass 1 - vague PRD. Input:
"Checkout must feel snappy and work for users worldwide. We need to meet enterprise security requirements."
Every phrase fails the Step 2 testability test, so nothing is emitted as an NFR - each becomes a threshold-gap question:
**NFRs found:** 0 (all phrases are vague)
**Threshold gaps flagged:** 3
| Vague phrase | Suggested concretization |
|-------------------------------------------|-------------------------------------------------------------------------------------------|
| "feel snappy" | LCP ≤2.5s, INP ≤200ms (Web Vitals defaults)? |
| "work for users worldwide" | Specify: which locales? RTL? timezones? Unicode validation? CLDR-based number/date formatting? |
| "enterprise security requirements" | OWASP ASVS Level 2 (typical baseline) or Level 3 (strict)? SOC 2 Type II audit? FedRAMP? |
The output is a question list, not a fabricated set of thresholds.
Pass 2 - author returns with concrete thresholds. Input:
"Page load on /dashboard must be ≤1.5s p95 measured by Lighthouse CI on the GitHub Actions ubuntu-latest runner. Color contrast ratio ≥4.5:1 for normal text per WCAG 2.2 SC 1.4.3."
Every phrase is now threshold-bound and measurement-cited, so the skill emits tables with zero gaps:
## Performance
| ID | Requirement | Threshold | Measurement | Scope |
|-------|------------------------------------------------------------|-----------|-------------|----------------|
| PRF-1 | Page load on /dashboard | ≤1.5s p95 | Lighthouse CI on GitHub Actions ubuntu-latest | /dashboard route |
## Accessibility
| ID | Requirement | Threshold | Measurement | Scope |
|-------|------------------------------------------------------------|-----------|-------------|----------------|
| A11Y-1| Color contrast ratio for normal text | ≥4.5:1 | WCAG 2.2 SC 1.4.3 | every page |
**Threshold gaps:** 0 - all NFRs are threshold-bound and measurement-cited.
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Inventing thresholds the doc didn't specify | Tests pass for fabricated baselines; real users see worse perf. | Flag as threshold gap; require author input. |
| One generic "performance" NFR for every page | Different surfaces have different budgets (cached vs non-cached). | One NFR per measurable scope (route × viewport × auth state). |
| Mapping every security NFR to "OWASP Top 10" | Top 10 is awareness-tier; ASVS is verifiable. Compliance maps to ASVS. | Specify ASVS Level (1/2/3) and which controls. |
| Treating "uptime SLA" as a test requirement | SLA is a runtime / monitoring concern, not a pre-deploy test. | Map to monitoring metric + alert rule, not to a CI gate. |
gherkin-from-stories (qa-bdd plugin) - for functional requirements.まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
Builds a CI gate that fails the build on **new** WCAG / a11y violations introduced by a PR while grandfathering pre-existing violations on a per-rule / per-page baseline. Aggregates verdicts from axe-core / pa11y / Lighthouse a11y / WAVE / IBM Equal Access scans. Use when a project has accumulated a11y debt and a strict "zero violations" gate would block every PR - the ratchet pattern lets the team ship while preventing regressions.
日本語の概要は準備中です。原文の説明を表示しています。
Workflow skill that builds an A/B-test validity checklist from an experiment proposal, walking the canonical design-correctness gates - pre-registered OEC/power/guardrails, randomization unit + SRM check, assignment integrity, telemetry, peeking discipline, novelty/primacy, post-experiment SRM re-check - into a per-experiment checklist + sign-off form. Use when launching, auditing, or governing an experiment. For pitfall mechanics (guardrails, peeking) see experiment-results-interpreter's references; to read an already-valid result use experiment-results-interpreter; for per-SDK harness tests use experiment-sdk-testing - this gates DESIGN, not SDK code.
日本語の概要は準備中です。原文の説明を表示しています。
The single install-flow skill: the reference contract for the PWA install flow (installability gate fields, `beforeinstallprompt` handshake, per-platform paths - Android WebAPK / iOS Share menu / Firefox no-op - and the `display-mode` post-install signal, in references/install-flow-reference.md) plus the build-an-X workflow that emits the Add-to-Home-Screen suite. Walks the four-stage timeline, emitting one test per gate cell per [web.dev/articles/install-criteria][install-criteria], the deferred-prompt → `prompt()` → `userChoice` chain per [web.dev/articles/customize-install][customize-install], the iOS Safari manual-metadata branch (`apple-touch-icon`) per [web.dev/learn/pwa/installation][learn-pwa], and the post-install `(display-mode: standalone)` MQ assertion. Output: a Playwright spec with per-stage cells plus a coverage matrix. Use when a PWA's manifest, icons, or install handler change, when install conversion drops at an unknown stage, or when triaging a flaky install assertion.
日本語の概要は準備中です。原文の説明を表示しています。
Build-an-X workflow that uses an LLM to map existing tests to spec sections - given a spec doc + the test suite, the LLM identifies which tests cover which sections, surfaces uncovered sections (gap), and recommends specific tests to add. Output is a coverage matrix per spec ID. Scope is mapping tests that already exist and naming the gaps, not authoring tests for new acceptance criteria. Use when a spec doc and a test suite both exist but nobody can say which requirements are actually covered - before a release sign-off, an audit, or a decision about where to spend the next round of test effort.
日本語の概要は準備中です。原文の説明を表示しています。
Generates tests from natural-language specs (acceptance criteria, user stories, requirements) using an LLM, with confidence scoring per test case (LLM self-assessment plus heuristics: assertion quality, naming, completeness), batching uncertain cases for human review, and integration with the team's existing test framework. Use when the user asks to generate unit tests from acceptance criteria, convert user stories to test cases, automate test creation from requirements, or augment a spec-driven test suite with AI-generated stubs that are then curated before merge.
日本語の概要は準備中です。原文の説明を表示しています。
Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to the sunset ExtentReports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.
日本語の概要は準備中です。原文の説明を表示しています。