CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/non-functional-requirement-extractor

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 acceptance-criteria-extractor handles functional requirements.

75

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, actionable instruction skill with a clear sequenced workflow, real feedback loop, and clean one-level-deep reference split; the main weakness is mild verbosity from concept explanations and slight redundancy with the reference file.

Suggestions

Trim the Overview's quoted ISTQB non-functional-testing definition and drop the ISO 25010 rows marked "out" / "(developer-facing)" — the categorization is load-bearing but the concept explanations and excluded rows add tokens Claude does not need.

Reduce overlap between Step 3 and references/measurement-sources.md: keep Step 3 to a one-line pointer plus the Web Vitals defaults, and let the reference file hold the full per-family source catalog.

Consider condensing the two-pass worked example into a single compact before/after block; the threshold-gap-vs-emitted-table contrast is already clear from the Output format section.

DimensionReasoningScore

Conciseness

Mostly efficient, but the quoted ISTQB definition and the ISO 25010 table (which lists characteristics marked "out") explain concepts Claude largely knows, and Step 3 overlaps with the measurement-sources reference file, so it could be tightened; not at the verbose score-1 level but not fully lean.

2 / 3

Actionability

Provides concrete, copy-paste-ready guidance: signal-phrase tables, real threshold-bound rewrites with named tools (Lighthouse CI, axe-core, OWASP ASVS, ZAP, k6), real default thresholds (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1), and a full output-format template.

3 / 3

Workflow Clarity

A clear 6-step sequence with an explicit validation checkpoint (Step 2 testability test: threshold + measurement source + scope) and a feedback loop (flag threshold gaps, return to author for confirmation), reinforced by the two-pass worked example.

3 / 3

Progressive Disclosure

SKILL.md is an overview pointing to one well-signaled, one-level-deep reference (references/measurement-sources.md, verified present, linked from Steps 3 and 5), with the detailed measurement catalog appropriately split out and clear section navigation.

3 / 3

Total

11

/

12

Passed

Description

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, specific, third-person description that states concrete capabilities, embeds natural trigger terms, gives explicit when-guidance, and cleanly distinguishes itself from a sibling functional-requirements skill.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — "Reads a PRD, design doc, or product brief and pulls out the non-functional requirements ... as concrete, threshold-bound, testable assertions" and "Maps every NFR to its measurement source" — matching the multiple-specific-actions anchor.

3 / 3

Completeness

Answers both what (extract NFRs as testable assertions and map to measurement sources) and when with explicit trigger guidance ("Use after acceptance-criteria-extractor handles functional requirements"), so it is not capped at 2 by the missing-trigger rule.

3 / 3

Trigger Term Quality

Covers natural terms a user would say — "performance, accessibility, security, internationalization, reliability, observability" plus "PRD, design doc, or product brief" — giving good natural-keyword coverage.

3 / 3

Distinctiveness Conflict Risk

Carves out a clear niche — non-functional requirements only, with functional explicitly deferred to acceptance-criteria-extractor — making conflict with sibling skills unlikely.

3 / 3

Total

12

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents

DiscoveryImplementationValidation