032-architecture-adr-non-functional-requirements
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 solid description with strong completeness (explicit 'Use when' clause), excellent trigger term coverage across the NFR/architecture domain, and a highly distinctive niche. The main weakness is that the core action 'facilitates conversational discovery' is somewhat abstract—listing more concrete actions (e.g., 'generates ADR templates, maps quality attributes to measurable criteria') would strengthen specificity.
Suggestions
Replace 'Facilitates conversational discovery to create' with more concrete actions like 'Guides users through structured questions to generate ADR markdown documents, map quality attributes to measurable criteria, and define acceptance thresholds' to improve specificity.
| 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 is a moderately well-structured conversational skill that clearly defines behavioral constraints and delegates detail to a reference file. Its main weaknesses are the lack of concrete examples (e.g., sample conversation snippets, example ADR output structure) and a workflow that is described rather than explicitly sequenced with numbered steps and validation checkpoints. The 'What is covered' and 'When to use' sections add some redundancy without proportional value.
Suggestions
Add a brief numbered workflow (e.g., 1. Run `date` → 2. Challenge-first opening → 3. Deep dive → 4. Summarize and validate → 5. Generate ADR) to make the multi-step conversational process explicit with clear checkpoints.
Include a short example of expected ADR output structure or a snippet showing the Quality Metrics & Success Criteria section, so Claude knows the target format without needing to read the reference file.
Remove or consolidate the 'What is covered' bullet list with the constraints section to reduce redundancy and improve token efficiency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably concise but includes some unnecessary elaboration. The 'What is covered' section largely restates what the constraints already imply, and the 'When to use this skill' section lists near-synonymous trigger phrases that add little value. | 2 / 3 |
Actionability | The skill provides clear behavioral constraints (ask 1-2 questions, validate before generating, run `date` command) but lacks concrete examples of what the conversation flow looks like, what a good ADR output looks like, or any executable templates. The actual actionable content is deferred entirely to the reference file. | 2 / 3 |
Workflow Clarity | The bullet list in 'What is covered' implies a sequence (challenge-first opening → understanding → deep dive → exploration → synthesis → generation), and the constraints add validation checkpoints (confirm before proceeding). However, the workflow is not explicitly numbered or sequenced with clear validation gates—it's more of a description than a step-by-step process with feedback loops. | 2 / 3 |
Progressive Disclosure | The skill provides a clear overview with behavioral constraints and appropriately delegates detailed guidance, examples, and the reference template to a single well-signaled reference file one level deep. This is well-structured progressive disclosure. | 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.
- Repository
- jabrena/cursor-rules-java
- Commit
9ec21dd
- 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.