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/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 ADR-specific mention adds some distinctiveness. However, the capability descriptions lean toward abstract process terms rather than concrete actions, and the trigger terms could be expanded to cover more natural user phrasings. The 'system design' trigger is broad enough to potentially conflict with other architecture or design-related skills.
Suggestions
Add more concrete action verbs like 'generates ADR markdown documents', 'compares technology alternatives in structured matrices', or 'documents architectural rationale'.
Expand trigger terms to include natural variations like 'tech stack choice', 'design tradeoffs', 'RFC', 'architecture review', 'design rationale', or 'technology comparison'.
| 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
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 files that don't exist in the bundle. The body itself contains no actionable guidance—no templates, no concrete steps, no executable examples for architecture decision-making. The content map is well-organized but the skill is essentially hollow without its supporting files, and even as an overview it lacks a clear workflow sequence.
Suggestions
Add a concrete, sequenced workflow (e.g., 1. Gather requirements → 2. Classify project → 3. Evaluate trade-offs → 4. Document ADR) with explicit validation checkpoints between steps.
Include at least one concrete, copy-paste-ready ADR template or trade-off matrix directly in the SKILL.md so the skill is actionable even without bundle files.
Remove the generic 'When to Use' and 'Limitations' boilerplate sections that add no skill-specific value.
Provide the referenced bundle files (context-discovery.md, trade-off-analysis.md, etc.) or inline their key content to make the progressive disclosure functional.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient with a clean table-based content map and brief core principle section. However, the 'When to Use' and 'Limitations' sections are generic boilerplate that add no value, and the core principle quotes are somewhat padded. | 2 / 3 |
Actionability | The skill body contains no concrete code, commands, templates, or executable guidance. It is entirely a navigation hub with abstract principles ('start simple', 'add complexity only when proven necessary') and a generic checklist. The actual actionable content is deferred entirely to referenced files that are not provided. | 1 / 3 |
Workflow Clarity | There is no clear sequenced workflow for making architecture decisions. The validation checklist at the end is a static list without ordering, feedback loops, or explicit steps for how to proceed from requirements to ADR documentation. For a multi-step process like architecture decision-making, this is insufficient. | 1 / 3 |
Progressive Disclosure | The content map table with file descriptions and 'When to Read' guidance is well-structured and one-level deep. However, no bundle files are provided, meaning all referenced files (context-discovery.md, trade-off-analysis.md, etc.) are missing, so the progressive disclosure structure is aspirational but unverifiable and currently non-functional. | 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 | |
95574f3
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.