Facilitates conversational discovery to create Architectural Decision Records (ADRs) for non-functional requirements using the ISO/IEC 25010:2023 quality model. Use when the user wants to document quality attributes, NFR decisions, security/performance/scalability architecture, or design systems with measurable quality criteria. Part of the skills-for-java project
79
73%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/032-architecture-adr-non-functional-requirements/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong description with excellent trigger term coverage and completeness, including an explicit 'Use when' clause with multiple relevant trigger scenarios. The main weakness is that the core action ('facilitates conversational discovery') is somewhat abstract rather than listing concrete discrete actions the skill performs. The description is distinctive and clearly carved out for a specific niche.
Suggestions
Replace 'Facilitates conversational discovery to create' with more concrete actions, e.g., 'Guides users through structured questions to generate Architectural Decision Records (ADRs), maps quality attributes to measurable criteria, and produces formatted ADR documents.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (ADRs for non-functional requirements) and references a specific standard (ISO/IEC 25010:2023), but the concrete actions are somewhat vague—'facilitates conversational discovery' is abstract rather than listing specific discrete actions like 'generates ADR templates, maps quality attributes to measurable criteria, produces markdown records.' | 2 / 3 |
Completeness | Clearly answers both 'what' (facilitates conversational discovery to create ADRs for NFRs using ISO/IEC 25010:2023) and 'when' (explicit 'Use when' clause covering quality attributes, NFR decisions, security/performance/scalability architecture, or design systems with measurable quality criteria). | 3 / 3 |
Trigger Term Quality | Good coverage of natural terms users would say: 'ADR', 'Architectural Decision Records', 'quality attributes', 'NFR', 'non-functional requirements', 'security', 'performance', 'scalability', 'architecture', 'measurable quality criteria'. These are terms a user working in this domain would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche combining ADRs, non-functional requirements, and the ISO/IEC 25010:2023 standard. Very unlikely to conflict with other skills given the specific domain focus on quality model-based architectural decision records. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill establishes clear behavioral constraints for an interactive ADR creation process and appropriately delegates detailed guidance to a reference file. However, it lacks concrete examples (e.g., sample questions, ADR output snippets) that would make it immediately actionable without reading the reference, and the workflow sequence could be more explicitly structured with numbered steps and validation checkpoints inline.
Suggestions
Add a brief numbered workflow sequence (e.g., 1. Run `date`, 2. Challenge-first opening, 3. Deep dive, 4. Validate summary, 5. Generate ADR) to make the multi-step process explicit inline rather than implied through bullet points.
Include a minimal concrete example of the expected ADR output structure or at least the key sections (e.g., Quality Metrics & Success Criteria format) so Claude has actionable guidance without needing to read the reference file.
Remove or consolidate the 'When to use this skill' section—these trigger phrases are metadata-level content that doesn't add instructional value in the body.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably concise but includes some unnecessary explanation like the 'What is covered' section that largely restates the workflow, and the 'When to use this skill' section lists near-identical trigger phrases. The enumeration of ISO 25010 characteristics in the bullet is informational padding. | 2 / 3 |
Actionability | The skill provides clear constraints and behavioral rules (ask 1-2 questions, validate before generating, run `date`), but the actual conversational workflow and ADR generation steps are deferred entirely to the reference file. There are no concrete examples of questions to ask, ADR output format, or quality metrics templates in the skill itself. | 2 / 3 |
Workflow Clarity | The 'What is covered' section implies a sequence (challenge-first opening → understanding → deep dive → exploration → synthesis → generation), and the constraints enforce validation checkpoints (confirm before proceeding). However, the steps are not explicitly numbered or sequenced as a workflow, and the actual detailed process is delegated to the reference file without inline clarity. | 2 / 3 |
Progressive Disclosure | The skill provides a clear overview with well-signaled one-level-deep reference to the detailed guidance file. The split between high-level constraints/workflow in SKILL.md and detailed content in the reference file is appropriate and clearly navigable. | 3 / 3 |
Total | 9 / 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 — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
1847adc
Table of Contents
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.