architecture
Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.
55
44%
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 structurally sound with a clear 'Use when' clause and identifies the domain well. However, the capabilities listed are somewhat abstract rather than concrete actions, and the trigger terms could be expanded to cover more natural user language variations. The skill could benefit from more specific action verbs and additional distinguishing keywords.
Suggestions
Add more concrete actions like 'generate ADR templates, compare technology options, document pros/cons matrices' to increase specificity.
Expand trigger terms to include natural variations users might say, such as 'tech stack choice', 'design tradeoffs', 'architecture review', 'RFC', 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 fully concrete actions like 'generate ADR templates' or 'compare technology options'. | 2 / 3 |
Completeness | Clearly answers both what (requirements analysis, trade-off evaluation, ADR documentation) and when ('Use when making architecture decisions or analyzing system design') with an explicit trigger clause. | 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', 'design patterns', 'scalability', 'microservices vs monolith', or 'architecture review'. | 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 adds some distinctiveness but the overall scope is still somewhat 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 other files, but provides almost no actionable content on its own. The content map is well-organized, but the absence of any concrete framework steps, executable examples, or meaningful workflow in the main file means Claude would gain very little from reading it alone. The boilerplate 'When to Use' and 'Limitations' sections waste tokens without adding value.
Suggestions
Add a concrete, sequenced workflow in the SKILL.md itself (e.g., '1. Classify project using context-discovery.md → 2. Identify constraints → 3. Evaluate trade-offs using trade-off-analysis.md → 4. Document decision as ADR') so the skill has standalone actionability.
Include at least one concrete, minimal example of an architecture decision record (ADR) directly in the SKILL.md so Claude has an immediately usable template without needing to read referenced files.
Remove the generic 'When to Use' and 'Limitations' boilerplate sections—they add no information beyond what the description and content map already convey.
Add validation checkpoints to the workflow (e.g., 'Before proceeding to pattern selection, confirm requirements are signed off') to provide feedback loops for this multi-step decision process.
| 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 motivational quote at the top is unnecessary filler. | 2 / 3 |
Actionability | The skill provides no concrete, executable guidance—no code, no commands, no specific examples, no actual decision framework steps. It's entirely a navigation page pointing to other files, with only a vague checklist and abstract principles like 'start simple.' | 1 / 3 |
Workflow Clarity | There is no clear multi-step workflow or sequenced process for making architecture decisions. The validation checklist is a static list of items with no ordering, no feedback loops, and no guidance on what to do when checks fail. The actual workflow presumably lives in the referenced files, but the SKILL.md itself provides no actionable sequence. | 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, so the referenced files (context-discovery.md, trade-off-analysis.md, etc.) cannot be verified to exist. The SKILL.md itself is almost entirely a navigation page with very little standalone value. | 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
- boisenoise/skills-collections
- Commit
431bfad
- 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.