Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
63
54%
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/antigravity-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 is competent with a clear structure covering both what and when, 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 expanded to cover 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', 'create comparison matrices for technology choices', or 'evaluate scalability and reliability tradeoffs'.
Expand trigger terms to include natural variations like 'tech stack decision', 'design tradeoffs', 'RFC', 'architecture review', 'should I use X or Y'.
| 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', 'architecture review', 'RFC', or 'design document'. | 2 / 3 |
Distinctiveness Conflict Risk | 'System design' and 'architecture' are fairly broad terms that could overlap with skills focused on code structure, infrastructure, 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
42%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 well-organized navigation hub with good progressive disclosure, but it lacks actionable content in the main file itself. The core principle section is generic wisdom Claude already knows, and the 'When to Use' section is a meaningless placeholder. The actual value depends entirely on the referenced sub-files, making this SKILL.md more of a table of contents than a skill.
Suggestions
Add a concrete quick-start workflow in the main file (e.g., '1. Run context discovery questions → 2. Classify project → 3. Select patterns via decision tree → 4. Document in ADR'), so the skill is actionable even without reading sub-files.
Remove the 'When to Use' section (it's a tautology) and the generic 'Core Principle' quote—Claude already understands simplicity in design.
Include at least one concrete, minimal ADR template or example directly in the SKILL.md so there's immediately executable guidance.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient but includes some unnecessary filler like the motivational quote, the 'When to Use' section that says nothing, and the 'Core Principle' section which states things Claude already knows about simplicity in design. | 2 / 3 |
Actionability | The SKILL.md itself contains no concrete code, commands, or executable guidance—it's entirely a navigation page with a vague checklist. The actual actionable content is deferred entirely to sub-files, leaving this file as abstract direction rather than concrete instruction. | 1 / 3 |
Workflow Clarity | The validation checklist provides some structure for the decision-making process, and the content map implies a sequence (context discovery → trade-off analysis → pattern selection). However, there's no explicit workflow sequence with validation checkpoints or feedback loops for the architecture decision process itself. | 2 / 3 |
Progressive Disclosure | Excellent use of a content map with clear file descriptions and 'When to Read' guidance. References are one level deep, well-signaled, and organized for selective reading. Related skills are also clearly linked. | 3 / 3 |
Total | 8 / 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 | |
f1697b6
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.