CtrlK
BlogDocsLog inGet started
Tessl Logo

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

64

Quality

75%

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

Fix and improve this skill with Tessl

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

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.

The body is a well-structured, navigable overview with a clear sequenced workflow and an appropriately placed single reference. Its weakness is redundancy: the core constraints are restated three times across sections, which inflates the token budget without adding guidance.

Suggestions

Collapse the duplicated grounding/prioritization/stop-before-ADR rules so each appears once (e.g., keep them in Constraints and reference them from the Workflow) to tighten conciseness from 3 toward 4.

Add an explicit validation checkpoint in the workflow (e.g., 'Verify each candidate cites a specific upstream evidence item before ranking it') to strengthen workflow clarity toward 5.

Inline one short worked example of a grounded, prioritized candidate so the body is actionable without requiring the reference read.

DimensionReasoningScore

Conciseness

The prose is tight and avoids explaining concepts Claude already knows, but the same core rules (ground in evidence, prioritize by impact/risk, stop before ADR) are repeated across 'What is covered', 'Constraints', and 'Workflow', which is more than minor padding.

3 / 5

Actionability

As an instruction-only skill it gives concrete, specific directives — named evidence sources (problem frame, root causes, assumptions, context map), named prioritization criteria (stakeholder impact and risk), an explicit stop condition, and a concrete report statement — with only the minor gap that worked examples live in the reference.

4 / 5

Workflow Clarity

Five numbered steps form a clear, well-sequenced procedure with soft checkpoints ('flag the gap instead of inventing', 'stop before architecture decisions'), but there is no explicit validate-the-candidate-is-grounded step or feedback loop, leaving a minor validation gap.

4 / 5

Progressive Disclosure

The body is a clean overview (intro, scope, constraints, when-to-use, workflow) pointing to a single well-signaled, one-level-deep reference that exists on disk, with no nested references and easy navigation.

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.

The description is strong: it clearly answers both what and when with multiple concrete triggers and relevant natural keywords, and uses explicit boundary language to stay distinct. The main limitation is that the concrete action set is narrow (identify + prioritize) rather than a broad list of operations.

Suggestions

Add one or two more distinct concrete actions (e.g., 'ground each candidate in upstream evidence', 'flag gaps for clarifying questions') to lift specificity from 3 toward 4.

Include a couple more natural user phrasings or synonyms (e.g., 'NFRs', 'non-functional requirements discovery') to push trigger-term coverage toward 5.

Sharpen the distinctiveness signal by naming the explicit handoff (e.g., 'outputs feed later ADR/architecture work') so it is less likely to collide with a sibling ADR skill.

DimensionReasoningScore

Specificity

Names the domain (quality attributes / non-functional requirements) and two concrete actions — 'identified and prioritized' / 'discover and prioritize' — but does not list several distinct actions, matching the anchor for 1-2 concrete actions rather than the broader coverage of a 4.

3 / 5

Completeness

Explicitly states what the skill does (identify and prioritize quality attributes before architecture/design) and gives multiple concrete 'Use when...' / 'This should trigger when...' trigger phrases, satisfying the anchor for clear what-and-when with concrete triggers.

5 / 5

Trigger Term Quality

Includes natural terms a user would say ('quality attributes', 'non-functional requirements', 'ADR', 'architecture and design') plus the POV trigger 'Quality Attribute Discovery', with a synonym pair, but a few common phrasings are absent so it is not fully comprehensive.

4 / 5

Distinctiveness Conflict Risk

It carves a distinct niche (discovery before ADR/design) with explicit boundary language, but 'quality attributes' / 'non-functional requirements' terms and the 'Part of Plinth Toolkit' framing imply minor overlap risk with sibling architecture/ADR skills.

4 / 5

Total

16

/

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.

Repository
jabrena/plinth
Reviewed

Table of Contents

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.