architecture
Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
44
44%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/architecture/SKILL.mdQuality
Discovery
67%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 covers the basics with a clear 'what' and 'when' clause, and the mention of ADR documentation provides some specificity. However, the actions listed are somewhat abstract rather than concretely actionable, and the trigger terms could be broader to capture more natural user phrasings. The domain overlap risk with general system design or code architecture skills is moderate.
Suggestions
Add more concrete actions like 'generate ADR markdown documents', 'compare technology alternatives in structured tables', or 'evaluate scalability and maintainability tradeoffs'.
Expand trigger terms to include natural user phrases like 'tech stack choice', 'which technology should I use', 'design tradeoffs', 'architectural decision record', or 'RFC'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (architectural decisions) and some actions (requirements analysis, trade-off evaluation, ADR documentation), but these are somewhat abstract and not deeply concrete actions like 'generate ADR markdown files' or 'compare technology options in a matrix'. | 2 / 3 |
Completeness | Clearly answers both 'what' (requirements analysis, trade-off evaluation, ADR documentation) and 'when' (explicitly states 'Use when making architecture decisions or analyzing system design'). | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'architecture decisions', 'system design', and 'ADR', but misses common natural variations users might say such as 'tech stack choice', 'design tradeoffs', 'which database should I use', 'architectural decision records', or 'system architecture'. | 2 / 3 |
Distinctiveness Conflict Risk | 'System design' and 'architecture' are fairly broad terms that could overlap with skills focused on code structure, infrastructure setup, or general software design. The ADR mention helps narrow it, but 'analyzing system design' is still quite broad. | 2 / 3 |
Total | 9 / 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 functions primarily as a table of contents pointing to supporting files that don't exist in the bundle. It lacks any concrete, actionable guidance in the body itself—no templates, no executable steps, no examples. The core principle section is generic advice Claude already knows, and the boilerplate 'When to Use' and 'Limitations' sections waste tokens without adding value.
Suggestions
Add a concrete, sequenced workflow in the body (e.g., Step 1: Discover context using these questions → Step 2: Classify project type → Step 3: Analyze trade-offs using this template → Step 4: Write ADR → Step 5: Validate against checklist) so the skill is actionable even without the referenced files.
Include at least one inline ADR template or trade-off analysis example directly in SKILL.md so there is immediately executable/usable content.
Remove the generic 'When to Use' and 'Limitations' boilerplate sections—they add no skill-specific value.
Provide the referenced bundle files (context-discovery.md, trade-off-analysis.md, etc.) or inline their essential content, since without them the skill is an empty shell.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient with a clean table-based content map and concise core principle section. However, the 'When to Use' and 'Limitations' sections are generic boilerplate that add no value, and the quotes/emoji headers are unnecessary padding. | 2 / 3 |
Actionability | The skill body contains no concrete code, commands, templates, or executable guidance. It is entirely a navigation page pointing to other files, with only a vague validation checklist and abstract principles like 'start simple.' There's nothing copy-paste ready or directly actionable. | 1 / 3 |
Workflow Clarity | There is no clear sequenced workflow for making architecture decisions. The checklist at the end is a static list without ordering, validation checkpoints, or feedback loops. A multi-step process like architecture decision-making needs explicit sequencing (e.g., discover context → analyze trade-offs → select pattern → document ADR → validate). | 1 / 3 |
Progressive Disclosure | The content map table is well-structured with clear 'When to Read' guidance, and references are one level deep. However, no bundle files were provided, meaning all referenced files (context-discovery.md, trade-off-analysis.md, etc.) are missing, so the progressive disclosure structure is incomplete and unverifiable. The related skills references are a nice touch. | 2 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- sickn33/antigravity-awesome-skills
- Commit
45bad85
- 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.