CtrlK
BlogDocsLog inGet started
Tessl Logo

architecture

Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation. Use when making architecture decisions or analyzing system design.

70

1.18x
Quality

64%

Does it follow best practices?

Impact

98%

1.18x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/AI-Agents-Safe-Coding-Skills-claude/skills/architecture/SKILL.md

The canonical home for this skill is architecture in sickn33/agentic-awesome-skills

SKILL.md
Quality
Evals
Security

Quality

Content

38%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, token-lean overview with a genuinely good selective-reading map and a validation checklist. But it defers all substantive guidance to five reference files that are absent from the bundle, leaving the skill as delivered with abstract principles, a decorative filler section, and dead links.

Suggestions

Ship the five referenced files (context-discovery.md, trade-off-analysis.md, pattern-selection.md, examples.md, patterns-reference.md) in references/, or remove them from the content map — as delivered, every 'When to Read' pointer is a dead link and progressive disclosure collapses at the first hop.

Add an explicit numbered core workflow to the body (clarify requirements → enumerate candidate patterns → score trade-offs → write ADR) with a small inline ADR template/example, so the skill remains actionable even before (or without) opening the reference files.

Trim the tautological 'When to Use' line ('This skill is applicable to execute the workflow or actions described in the overview.'), the opening epigraph, and the generic simplicity quotes — replace them with substantive guidance such as one concrete decision heuristic or a worked micro-example.

DimensionReasoningScore

Conciseness

The body is short and mostly efficient (terse bullets, a compact content map, no explaining of concepts Claude already knows), but it carries removable padding: the decorative epigraph ("Requirements drive architecture. Trade-offs inform decisions. ADRs capture rationale."), the generic wisdom section ("'Simplicity is the ultimate sophistication.'" / "Start simple"), and the tautological filler "This skill is applicable to execute the workflow or actions described in the overview." Not 4 because that filler line and two quote ornaments are clear trim candidates, per the 'could be tightened' anchor.

3 / 5

Actionability

The body offers only high-level hints: "Start simple", "Add complexity ONLY when proven necessary", and abstract checklist criteria like "Requirements clearly understood" and "Each decision has trade-off analysis". There are no concrete steps, no ADR template snippet, no example decision, and all substantive guidance (questions, decision trees, templates) is deferred to reference files that are not in the bundle — so the missing-specific-steps condition of the 2 anchor applies; not 3 because even the checklist items are criteria rather than executable guidance.

2 / 5

Workflow Clarity

A rough sequence is only implied via the content map's "When to Read" column ("Starting architecture design" → "Choosing patterns" → "Documenting decisions"), and the "Validation Checklist" supplies a final checkpoint ("Before finalizing architecture"). But the decision process is never explicitly sequenced as steps, intermediate checkpoints are absent, and there is no fix-and-retry loop; this matches 'sequence present but checkpoints missing or implicit'. Not 2 because validation is present rather than absent.

3 / 5

Progressive Disclosure

Scored against the actual bundle per the judging guidelines: the directories references/, scripts/, and assets/ do not exist, so all five mapped files (context-discovery.md, trade-off-analysis.md, pattern-selection.md, examples.md, patterns-reference.md) are dead references. The map itself is well designed — clear descriptions, one level deep, 'Read ONLY files relevant to the request!' — but navigation dead-ends immediately and the detailed content simply does not exist, leaving the structure non-functional rather than merely imperfectly signaled (3) or well-executed (5).

2 / 5

Total

10

/

20

Passed

Description

75%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.

A solid description with an explicit 'Use when...' clause, domain-specific vocabulary (trade-offs, ADRs), and a distinguishable niche. Its main weaknesses are the near-tautological trigger phrasing and thin synonym coverage, which keep every dimension at 4 rather than 5.

Suggestions

Replace the tautological trigger with additional concrete trigger variations, e.g. 'Use when choosing a tech stack, evaluating design alternatives, reviewing an architecture, or writing ADRs.'

Lead the capability list with concrete verb phrases and objects (e.g. 'Analyzes requirements, evaluates design trade-offs, selects patterns, and documents decisions as ADRs') to sharpen the 'what' and cover the pattern-selection work the body advertises.

Add common synonyms users would say (software design, system architecture, design review) to broaden natural trigger coverage without adding length.

DimensionReasoningScore

Specificity

"Requirements analysis, trade-off evaluation, ADR documentation" lists several concrete action areas within the named architectural domain, matching the 'several specific actions; minor gaps' anchor. Not 5 because the actions are terse noun phrases without objects (vs. 'Extract text and tables from PDF files') and coverage omits pattern selection, which the body shows is part of the skill; not 3 because three concrete actions exceeds '1-2 concrete actions'.

4 / 5

Completeness

Both parts are present: what ("Architectural decision-making framework. Requirements analysis, trade-off evaluation, ADR documentation") and an explicit when ("Use when making architecture decisions or analyzing system design"). Not 5 because the trigger clause is partly tautological — 'use the architectural decision skill when making architecture decisions' restates the name — and offers only one additional trigger variation; the 'what' is also a category label rather than a fully concrete capability statement.

4 / 5

Trigger Term Quality

"Use when making architecture decisions or analyzing system design" plus "trade-off evaluation" and "ADR" give good natural-term coverage users would actually say. Missing common variations like "software design", "design review", or "choosing a tech stack", so it falls short of the comprehensive synonym coverage of the 5 anchor.

4 / 5

Distinctiveness Conflict Risk

"architecture decisions", "trade-off evaluation", "ADR documentation", and "analyzing system design" carve a mostly distinct niche with minor overlap risk against closely related design/planning skills (e.g., the database-design and api-patterns skills it itself lists). Not 5 because "analyzing system design" is broad enough to occasionally collide with general software-design skills.

4 / 5

Total

16

/

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
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.