Tessl • The management layer for AI agent skills

SkillPublic

system-design

Design systems, services, and architectures. Trigger with "design a system for", "how should we architect", "system design for", "what's the right architecture for", or when the user needs help with API design, data modeling, or service boundaries.

Quality

82%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

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

An exceptionally lean, well-organized framework that assumes Claude's competence and wastes no tokens. Its weakness is actionability: it tells Claude what topics to cover in each phase but not how to execute them, with no worked example or design-document template to make the output concrete.

Suggestions

Add a brief design-document output template (section headings for Assumptions, Component Diagram, Data Model, API Contracts, Trade-offs) so the deliverable structure is prescribed, not just described.

Convert a few topic bullets into executable instructions, e.g. "Load estimation: state expected QPS/traffic and derive the number of instances/shards needed" instead of the bare label.

Include one compact worked example (a few-line skeleton design for a URL shortener) to anchor the expected depth and format of a deep-dive phase.

Dimension	Reasoning	Score
Conciseness	The body is a lean checklist that names topics without teaching them ("API endpoint design (REST, GraphQL, gRPC)", "Horizontal vs. vertical scaling") with zero padding or concept explanation, matching anchor 5's every-token-earns-its-place rather than anchor 4's minor over-explanation (there is none to trim).	5 / 5
Actionability	The numbered framework plus the Output section ("Produce clear, structured design documents with diagrams (ASCII or described), explicit assumptions, and trade-off analysis") provide real structure, but bullets like "Component diagram" and "Load estimation" are topic labels with no method, example, or template for how to execute each step — analogous to anchor 3's incomplete concrete guidance with missing key details.	3 / 5
Workflow Clarity	A clear coherent five-phase sequence (Requirements Gathering through Trade-off Analysis) culminating in a deliverables section fits anchor 4's clear sequence with minor gaps; it falls short of anchor 5 because there is no iteration guidance and "Output" sits outside the numbered flow, and no validation checkpoints are relevant since no destructive or batch operations exist.	4 / 5
Progressive Disclosure	The skill is under 50 lines, has no bundle files and no need for external references, and is organized into a clean Framework/Output section structure, satisfying the simple-skill exception for a top score.	5 / 5
	Total	17 / 20 Passed

Description

78%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 well-formed description that explicitly covers both what the skill does and when to use it, with natural quoted trigger phrases. Its main weakness is that the capability statement relies on a single broad verb plus topic areas rather than enumerating concrete deliverable actions.

Suggestions

Enumerate concrete outputs in the first sentence, e.g. "Design systems and services, producing component diagrams, data models, and API contracts" — this turns topic areas into specific actions.

Add one or two more natural trigger variations users commonly say, such as "scalable design", "high-level design", or "is this architecture right for".

Dimension	Reasoning	Score
Specificity	"Design systems, services, and architectures" uses one broad generic verb, but the concrete sub-domains "API design, data modeling, or service boundaries" name specific areas, matching anchor 3 (domain plus 1-2 concrete actions) rather than anchor 2's bare domain label or anchor 4's several distinct concrete actions.	3 / 5
Completeness	It clearly answers both "what" ("Design systems, services, and architectures") and "when" ("Trigger with... or when the user needs help with...") with concrete trigger phrases, matching the anchor-5 example pattern exactly rather than anchor 4's less explicit 'when'.	5 / 5
Trigger Term Quality	The four quoted phrases ("design a system for", "how should we architect", "system design for", "what's the right architecture for") are natural user utterances with good coverage, but common synonyms like "scalability", "high-level design", or "system architecture" are missing, so it falls short of anchor 5's comprehensive coverage.	4 / 5
Distinctiveness Conflict Risk	The core triggers ("system design for", "what's the right architecture for") carve out a distinct niche, but "API design" and "data modeling" carry minor overlap risk with dedicated API or database skills, fitting anchor 4 rather than anchor 5's minimal conflict risk.	4 / 5
	Total	16 / 20 Passed

Validation

100%

Warnings & errors only

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: anthropics/knowledge-work-plugins
Path: engineering/skills/system-design/SKILL.md
Revision: c75fda0

Reviewed: 15 days ago

Discovery Implementation Validation

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.

system-design

Table of Contents

Is this your skill?