CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

software-architecture

Guide for quality focused software architecture. This skill should be used when users want to write code, design architecture, analyze code, in any case that relates to software development.

Quality

56%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/software-architecture/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

53%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a well-organized single-file rule collection with several genuinely concrete directives (specific line limits, library examples, naming conventions), but it is undermined by verbatim duplication between the Best Practices and Anti-Patterns sections, a circular and useless 'When to Use' section, and a substantial fraction of abstract architectural principle with no application examples or workflow for how to apply the rules.

Suggestions

Remove the duplication between 'Architecture and Design' and 'Anti-Patterns to Avoid' (the business-logic/UI mixing and DB-in-controllers items appear in both) and the repeated 200-line file-size rule, which pad tokens without adding information.

Delete or rewrite the 'When to Use' section — 'This skill is applicable to execute the workflow or actions described in the overview' says nothing; replace it with concrete application guidance, e.g., when to check these rules during a coding task.

Add one short before/after or minimal example for the most abstract directives (e.g., a 2-3 line snippet showing a generic `utils.js` function renamed to `OrderCalculator`, or a one-line early-return refactor) to raise actionability without much token cost.

DimensionReasoningScore

Conciseness

Mostly directive bullets rather than explanations of known concepts, but with clear padding: the 'Anti-Patterns to Avoid' section restates 'Architecture and Design' items verbatim ("Mixing business logic with UI components", "Database queries directly in controllers"), the 200-line file rule appears twice, and "When to Use" is circular filler ("This skill is applicable to execute the workflow or actions described in the overview"). It fits 'mostly efficient but includes some unnecessary explanation' rather than anchor 2, since the majority of bullets are genuine directives.

3 / 5

Actionability

Some guidance is concrete and executable ("use `cockatiel` instead of writing your own retry logic", "AVOID generic names: `utils`, `helpers`, `common`, `shared`", "Avoid deep nesting (max 3 levels)", "Don't build custom auth when Auth0/Supabase exists"), but a large portion is abstract principle with no examples or application steps ("Keep business logic independent of frameworks", "Define use cases clearly and keep them isolated", "Follow bounded context naming patterns"). It sits between anchors 3 and 4; the substantial abstract fraction keeps it at 3.

3 / 5

Workflow Clarity

The content is a static rule collection with no multi-step process, no sequencing guidance for when to apply which rules, and no validation checkpoints; the only process-oriented section ('When to Use') states nothing actionable. No destructive/batch operations are involved so validation is not strictly required, but there is no workflow to speak of, matching 'sequence present but checkpoints missing or implicit' only weakly and not the clearer levels above.

3 / 5

Progressive Disclosure

A single-file skill (~74 lines) with no bundle files and no need for external references, organized under clear headers (General Principles, Best Practices, Anti-Patterns, Code Quality). It matches 'Good structure; most content is appropriately placed; minor organization gaps' — the filler 'When to Use' section and the inline duplication between Architecture and Anti-Patterns sections are the minor gaps that keep it below 5.

4 / 5

Total

13

/

20

Passed

Description

41%Weight 40%Scale 1-5

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 correctly uses third person and includes an explicit 'when' clause, but the 'what' is vague, the trigger scope is an unlimited catch-all for all software development, and no concrete capabilities are listed. This makes it both uninformative and highly likely to conflict with other development-related skills.

Suggestions

State the 'what' concretely: list the actual capabilities, e.g., 'Enforces code style rules (early returns, function/file size limits, naming conventions), a library-first approach over custom code, and Clean Architecture/DDD boundaries.'

Replace the catch-all "in any case that relates to software development" with specific trigger phrases users would naturally say, e.g., 'Use when the user asks to design a system's architecture, structure a new module, review code organization, or decide whether to use a library versus custom code.'

Narrow the trigger terms to distinctive phrases (e.g., 'design architecture', 'domain-driven design', 'clean architecture', 'refactor module structure') to reduce conflict risk with general coding, review, and refactoring skills.

DimensionReasoningScore

Specificity

The description names the domain ("software architecture") but its actions are generic ("write code, design architecture, analyze code") with no concrete capabilities; the skill's actual content (early returns, library-first, naming rules) is not surfaced. It matches 'Names the domain but actions are minimal or generic' rather than the level above, which requires 1-2 concrete actions.

2 / 5

Completeness

A 'when' clause is present ("This skill should be used when users want to write code..."), but the 'what' ("Guide for quality focused software architecture") is vague and does not state what the skill actually does. It sits between anchor 3 (clear what, weak when) and anchor 4 (both present, when could be more specific); the vague 'what' and over-broad 'when' keep it noticeably below 4.

3 / 5

Trigger Term Quality

"write code", "design architecture", and "analyze code" are natural user phrases, but the catch-all "in any case that relates to software development" replaces the specific trigger contexts and synonyms users would actually say. Some relevant keywords exist, but common variations and concrete trigger situations are missing, fitting anchor 3 rather than 4.

3 / 5

Distinctiveness Conflict Risk

The phrase "in any case that relates to software development" makes the trigger scope effectively unlimited, creating high overlap risk with virtually any coding-related skill (code review, refactoring, testing skills, etc.). It matches 'Very broad; high overlap risk with many similar skills'; not 3, because the description explicitly claims all software development rather than merely overlapping with adjacent domains.

2 / 5

Total

10

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

administrakt0r/AI-Agents-Safe-Coding-Skills

Path

skills/software-architecture/SKILL.md

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.