025-quality-attribute-discovery

Use when a problem under exploration needs its quality attributes (non-functional requirements) identified and prioritized before architecture and design begin. This should trigger when an issue's Quality Attribute Discovery point of view needs evaluation, or when a maintainer directly asks to discover and prioritize candidate quality attributes for a problem, before any ADR or design work starts. Part of Plinth Toolkit

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/025-quality-attribute-discovery/SKILL.md

Quality

Content

71%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-structured, disciplined instruction skill: clear scope boundary (stop before architecture decisions), a concrete workflow with named upstream inputs, and exemplary progressive disclosure to a single reference file. Its main weakness is redundancy: the stop-at-discovery-list rule and the coverage bullets repeat the workflow and constraints.

Suggestions

Consolidate the 'What is covered in this Skill?' bullets into the Workflow section, or keep only the boundary statement (produces a prioritized discovery list, not an ADR) once in Constraints, to remove the triple repetition of the stop-before-architecture rule.

Merge the two MUST/MUST NOT constraint bullets about not recording an architecture decision or ADR into one bullet, since they state the same prohibition.

Add one brief inline example of an evidence-grounded prioritized entry (or point to the reference's Example 2 explicitly) so step 3's prioritization guidance is actionable without opening the reference.

Dimension	Reasoning	Score
Conciseness	The body is mostly tight but repeats the stop-before-architecture rule across the coverage bullets, three Constraints bullets, and Workflow steps 4-5, and the 'What is covered' bullets largely restate the workflow. This is more than minor trimming (anchor 4) but far from padded concept explanation (anchor 2).	3 / 5
Actionability	Concrete instruction-skill guidance: MUST read a specific reference path, review named upstream artifacts (problem frame, root-cause findings, assumptions, context map), and prioritize by stakeholder impact and risk. Not fully actionable at score 5 because steps like 'identify candidates grounded in that evidence' defer the how to the reference file with no inline example.	4 / 5
Workflow Clarity	A clear 5-step sequence with a reporting checkpoint in step 5 (flag items left open pending a clarifying answer). Not score 5 because there is no explicit validation step confirming each candidate is evidence-grounded before reporting, though no destructive/batch cap applies.	4 / 5
Progressive Disclosure	The body is a clean overview pointing to exactly one real, one-level-deep reference file (references/025-quality-attribute-discovery.md, verified to exist), signaled three ways: a MUST-read constraint, Workflow step 1, and a dedicated Reference section with a markdown link. Matches the clear-overview anchor.	5 / 5
	Total	16 / 20 Passed

Description

78%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 description: it states what the skill does and gives explicit, natural trigger conditions with a clear pre-architecture boundary. Its gaps are minor — thin action coverage in the what-clause and a missing common synonym ('NFRs') — and the trailing 'Part of Plinth Toolkit' adds no trigger value.

Suggestions

State the concrete output in the what-clause, e.g. 'Produce a prioritized, evidence-grounded discovery list of quality attributes (non-functional requirements) for a problem under exploration, before architecture and design begin.'

Add the common synonym 'NFRs' alongside 'non-functional requirements' and 'requirements' to broaden natural trigger matching.

Lead with the what-statement before the 'Use when' clause and drop or compress 'Part of Plinth Toolkit', which contributes no trigger information.

Dimension	Reasoning	Score
Specificity	The description names the domain (quality attributes / non-functional requirements before architecture and design) with 1-2 concrete actions ('identified and prioritized'), but does not comprehensively state what the skill produces (e.g., a prioritized, evidence-grounded discovery list). Between anchors 3 and 4; the action coverage is closer to the 1-2-action anchor than to 'several specific actions'.	3 / 5
Completeness	It explicitly answers both what (quality attributes / non-functional requirements identified and prioritized before architecture and design begin) and when ('Use when a problem under exploration needs...', 'This should trigger when... a maintainer directly asks...'), with concrete trigger phrases matching the anchor-5 example.	5 / 5
Trigger Term Quality	Good natural keyword coverage: 'quality attributes', 'non-functional requirements', 'before any ADR or design work', 'discover and prioritize'. Missing common variations such as 'NFRs' or 'requirements' alone, so it falls short of the comprehensive-synonym anchor 5 but clearly exceeds the 3 anchor's missing-variation profile.	4 / 5
Distinctiveness Conflict Risk	A clear niche (pre-architecture NFR discovery, explicitly 'before any ADR or design work starts') with mostly distinct triggers. Minor overlap risk with sibling Plinth Toolkit skills for ADR or design work, keeping it just below the clear-niche anchor 5.	4 / 5
	Total	16 / 20 Passed

Validation

100%

Warnings & errors only

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.

Repository: jabrena/plinth
Path: skills/025-quality-attribute-discovery/SKILL.md
Commit: dca88dc

Reviewed: 3 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.