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 gherkin-from-stories (qa-bdd) handles functional requirements.

72

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Quality

Content

92%Weight 40%Scale 1-5

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

A well-engineered skill body: actionable signal-phrase lists, threshold-bound rewrites, a concrete output template, and a worked two-pass example, all sequenced with a validation checkpoint and a human-confirmation feedback loop. The only minor weakness is some conceptual scaffolding (ISO 25010 and ISTQB definitions) that Claude already knows and could be trimmed for token efficiency.

DimensionReasoningScore

Conciseness

The body is dense and information-rich with minimal padding, but includes some explanatory scaffolding (e.g., the ISO 25010 framing table and references to ISTQB definitions) that Claude largely already knows and could be trimmed.

4 / 5

Actionability

Highly actionable: concrete signal-phrase lists, a before/after threshold-bound rewrite table, an exact output-format template, and a full two-pass worked example all give copy-paste-ready, executable guidance.

5 / 5

Workflow Clarity

The six-step 'How to use' sequence is explicit with a validation checkpoint (Step 2 testability test, the never-fabricate rule) and a feedback loop (emit threshold gaps and return to the author for confirmation), matching the cap-satisfying validation pattern for batch/extractive operations.

5 / 5

Progressive Disclosure

Clear overview in SKILL.md with a single well-signaled one-level-deep reference (references/measurement-sources.md) that exists and holds the detailed source catalog; navigation is easy and content is appropriately split.

5 / 5

Total

19

/

20

Passed

Description

85%Weight 40%Scale 1-5

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 description that names concrete actions, the six NFR families, and measurement sources, while staking out a clear niche distinct from functional-requirement skills. The 'when' clause is explicit but framed as sequencing guidance rather than natural user-spoken trigger phrases, which keeps completeness and trigger quality just short of full marks.

Suggestions

Add explicit user-sayable trigger phrases to the 'when' clause (e.g., 'Use when the user mentions performance budgets, accessibility conformance, SLOs, or non-functional requirements in a PRD') so it matches natural phrasing.

Consider noting when NOT to use it (purely functional Gherkin-style requirements) up front to reinforce the boundary with qa-bdd.

DimensionReasoningScore

Specificity

Names multiple concrete actions ('pulls out the non-functional requirements ... as concrete, threshold-bound, testable assertions', 'Maps every NFR to its measurement source') with comprehensive coverage across six NFR families.

5 / 5

Completeness

Clearly answers 'what' with concrete actions and 'when' ('Use after gherkin-from-stories (qa-bdd) handles functional requirements'), but the trigger is a sequencing hint rather than explicit user-sayable trigger phrases, so it is not a full 5.

4 / 5

Trigger Term Quality

Strong coverage of natural input terms ('PRD, design doc, or product brief') and measurement vocabulary (Lighthouse, axe, OWASP ASVS, WCAG), but the 'when' trigger leans on the output artifact rather than the phrasing a user would naturally say.

4 / 5

Distinctiveness Conflict Risk

Clear niche (non-functional requirements mapped to measurement sources) explicitly delimited from the functional-requirements skill ('after gherkin-from-stories'), giving it minimal conflict risk.

5 / 5

Total

18

/

20

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents