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.
Overall
score
40%
Does it follow best practices?
Validation for skill structure
Install with Tessl CLI
npx tessl i github:sickn33/antigravity-awesome-skills --skill architect-reviewActivation
50%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 over others, and the description uses implied first-person framing through the role declaration.
Suggestions
Replace 'Master software architect specializing in...' with concrete actions like 'Designs system architectures, defines service boundaries, creates component diagrams, and evaluates trade-offs between architectural patterns.'
Expand the 'Use when' clause with specific triggers: 'Use when the user asks about system design, service decomposition, architectural patterns, or mentions terms like microservices, DDD, event sourcing, or clean architecture.'
Add natural user phrases that would trigger this skill, such as 'how should I structure my application', 'is this architecture scalable', or 'review my system design'.
| 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 concrete actions like 'designs microservices boundaries' or 'creates architecture diagrams'. | 2 / 3 |
Completeness | The 'what' is partially covered (reviews designs for integrity, scalability, maintainability). The 'when' clause ('Use PROACTIVELY for architectural decisions') is present but vague - it doesn't specify trigger scenarios or user phrases that would invoke this skill. | 2 / 3 |
Trigger Term Quality | Includes relevant technical terms (microservices, DDD, clean architecture, event-driven) but these are jargon-heavy. Missing natural user phrases like 'system design', 'how should I structure', 'architecture review', or 'scalability concerns'. | 2 / 3 |
Distinctiveness Conflict Risk | Somewhat specific to architecture domain, but 'reviews code changes' could overlap with code review skills, and 'scalability and maintainability' are generic concerns that many development skills might address. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
13%This skill content is a verbose capability catalog rather than actionable guidance. It extensively lists architectural concepts and patterns that Claude already knows, while failing to provide concrete evaluation criteria, templates, or executable workflows. The content would benefit from dramatic reduction and restructuring into a concise overview with specific, actionable review checklists.
Suggestions
Remove the extensive 'Capabilities' and 'Knowledge Base' sections entirely - Claude already knows these concepts. Replace with a brief statement like 'Apply standard architectural patterns (DDD, Clean Architecture, microservices) as appropriate.'
Add concrete evaluation templates or checklists, e.g., 'Architecture Review Checklist: [ ] Service boundaries align with bounded contexts [ ] No synchronous cross-service calls in critical paths [ ] Circuit breakers on external dependencies'
Provide specific output formats, e.g., 'Document findings as: ## Impact Assessment\n**Risk Level**: High/Medium/Low\n**Affected Components**: ...\n**Recommendation**: ...'
Move detailed pattern references to a separate PATTERNS.md file and keep SKILL.md focused on the review workflow with clear validation criteria.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with extensive lists of concepts Claude already knows (SOLID principles, design patterns, cloud technologies). The 'Capabilities' section reads like a resume rather than actionable guidance, wasting significant token budget on enumerating well-known architectural concepts. | 1 / 3 |
Actionability | No concrete code examples, commands, or executable guidance. The 'Instructions' section is vague ('Gather system context', 'Evaluate architecture decisions') without specifying how. The 'Response Approach' lists abstract steps without concrete implementation details or templates. | 1 / 3 |
Workflow Clarity | The 4-step instruction workflow provides a basic sequence, but lacks validation checkpoints, specific criteria for evaluation, or feedback loops. No guidance on what constitutes a 'risk' or how to validate architectural decisions before approval. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. All content is inline despite being far too detailed for a skill overview. The extensive capability lists should be in separate reference documents, with SKILL.md providing only essential guidance. | 1 / 3 |
Total | 5 / 12 Passed |
Validation
75%Validation — 12 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
description_trigger_hint | Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...') | Warning |
metadata_version | 'metadata.version' is missing | Warning |
license_field | 'license' field is missing | Warning |
body_output_format | No obvious output/return/format terms detected; consider specifying expected outputs | Warning |
Total | 12 / 16 Passed | |
Reviewed
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.