Master software architect specializing in modern architecture patterns, clean architecture, microservices, event-driven systems, and DDD. Reviews system designs and code changes for architectural integrity, scalability, and maintainability. Use PROACTIVELY for architectural decisions.
47
36%
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 ./.agent/skills/architect-review/SKILL.mdQuality
Discovery
50%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 identifies a clear domain (software architecture) and mentions relevant patterns, but relies too heavily on technical jargon and role-based language ('Master software architect') rather than concrete actions. The 'Use PROACTIVELY' guidance is too vague to help Claude determine when to select this skill, and the description uses implied first-person framing through the role declaration.
Suggestions
Replace 'Master software architect specializing in...' with concrete actions like 'Reviews system designs, creates architecture decision records (ADRs), evaluates microservice boundaries, and validates DDD implementations'
Expand the 'Use when' clause with specific triggers: 'Use when user asks about system design, service boundaries, architectural patterns, scaling strategies, or requests design review'
Add natural user phrases as trigger terms: 'how should I structure', 'design review', 'is this architecture good', 'microservice vs monolith'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names domain (software architecture) and some actions (reviews system designs, code changes), but uses vague terms like 'Master software architect' and lists patterns without specifying concrete actions like 'creates architecture diagrams' or 'generates ADRs'. | 2 / 3 |
Completeness | Has a 'what' (reviews designs for architectural integrity) but the 'when' clause ('Use PROACTIVELY for architectural decisions') is vague and doesn't provide explicit trigger scenarios or user phrases that would invoke this skill. | 2 / 3 |
Trigger Term Quality | Includes some relevant technical terms (microservices, DDD, clean architecture, event-driven) but these are jargon-heavy. Missing natural user phrases like 'design review', 'system design', 'how should I structure', 'architecture decision'. | 2 / 3 |
Distinctiveness Conflict Risk | Somewhat specific to architecture domain but could overlap with general code review skills or design pattern skills. Terms like 'code changes' and 'maintainability' are broad enough to conflict with other development-focused skills. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
22%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable organizational structure with well-linked sub-skills but fails to deliver actionable guidance in the main file. The instructions are abstract descriptions of what an architect does rather than concrete steps Claude can execute. The skill would benefit significantly from specific review checklists, example architectural assessments, and concrete validation criteria.
Suggestions
Replace the abstract 4-step instructions with a concrete architectural review checklist containing specific questions to evaluate (e.g., 'Does the design have a single point of failure?', 'Are service boundaries aligned with domain boundaries?')
Add an example architectural review showing input (a design description) and expected output (structured assessment with specific findings and recommendations)
Include specific validation criteria for what constitutes architectural risks and how to document them (e.g., a template for Architecture Decision Records)
Remove the redundant 'Expert Purpose' section since it duplicates the opening statement and 'Use this skill when' content
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill has some redundancy (e.g., 'Expert Purpose' section largely repeats the opening statement and 'Use this skill when' section). The content is reasonably efficient but could be tightened by removing duplicate explanations of the architect's role. | 2 / 3 |
Actionability | The instructions are vague and abstract ('Gather system context', 'Evaluate architecture decisions', 'Recommend improvements') without concrete examples, specific commands, checklists, or executable guidance. No actual architectural review templates, specific questions to ask, or concrete outputs are provided. | 1 / 3 |
Workflow Clarity | The 4-step process is too abstract to be actionable. There are no validation checkpoints, no specific criteria for what constitutes 'risks' or 'improvements', and no feedback loops for iterating on architectural decisions. The 'Safety' section mentions validation plans but doesn't explain how to create them. | 1 / 3 |
Progressive Disclosure | The skill appropriately references 10 sub-skills with clear one-level-deep links, which is good structure. However, the main file lacks a meaningful quick-start or concrete overview—it's mostly abstract guidance with links, making it unclear what value the main file provides beyond navigation. | 2 / 3 |
Total | 6 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
332e58b
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.