CtrlK
BlogDocsLog inGet started
Tessl Logo

system-design

Use when designing system architecture, integrations, tech specs, technology choices, or evolving an existing system where FR/NFR, constraints, scale, reliability, or current product capabilities materially affect the design. Triggers include design, architecture, how to build, integration, spec/ТЗ, спроектируй, архитектура, интеграция, как построить. NOT for routine implementation, debugging, or code edits when no architectural decision is at stake. This is the PRIMARY entry point for design requests; a knowledge-grounded design skill is used as an independent grounding track when available (discovered by role), never the entry point.

60

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/system-design/skills/system-design/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

47%Scale 1-3

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

This is a thorough, well-structured system design process skill with excellent workflow clarity and explicit gates, but it suffers significantly from verbosity — the same core principles (especially 'no hidden defaults') are restated in multiple forms across principles, rationalizations, gates, and red flags. The referenced bundle files (nfr-checklist.md, sizing-thresholds.md, output-format.md) are missing, which undermines both actionability and progressive disclosure. The skill would benefit greatly from aggressive trimming and ensuring referenced files exist.

Suggestions

Cut content by 40-50%: the 'no hidden defaults' principle is stated in principle 6, the rationalizations table, the gate description, and the red flags — consolidate to one authoritative statement and brief references elsewhere.

Provide the referenced bundle files (references/nfr-checklist.md, references/sizing-thresholds.md, references/output-format.md) or inline their essential content — without them, key actionable details are missing.

Add a concrete example of a Stage 1 requirements document output (even a brief one) so Claude has a tangible template, not just abstract descriptions of what it should contain.

Move the red flags table and rationalizations table into a separate reference file (e.g., references/red-flags.md) to reduce the main SKILL.md to a scannable process overview.

DimensionReasoningScore

Conciseness

The skill is extremely verbose at ~350+ lines of dense prose. It extensively explains meta-process concepts, rationalizations, anti-patterns, and principles that Claude could infer from much shorter instructions. Tables of 'rationalizations that mean STOP' and lengthy red-flag tables repeat concepts already stated in the principles. Many paragraphs restate the same 'no hidden defaults' rule in slightly different ways.

1 / 3

Actionability

The skill provides a clear multi-stage process with defined gates and outputs, and references specific tools (AskUserQuestion, planning mode, WebSearch, Context7). However, it lacks concrete executable examples — no sample requirement documents, no example gate questions, no template artifacts inline. It references external files (references/nfr-checklist.md, references/sizing-thresholds.md, references/output-format.md) that are not provided in the bundle, making key details unresolvable.

2 / 3

Workflow Clarity

The 5-stage workflow is clearly sequenced with explicit hard gates between stages. Stage 1 has a binary gate with clear pass/fail criteria. Stage 3 has a detailed dual-track process with fallback paths. Validation checkpoints are explicit throughout (e.g., 'while ANY item is unconfirmed... the gate does NOT pass — full stop'). Feedback loops for error recovery are well-defined (iterative sync blocks, re-validation rounds, max 2-3 convergence rounds).

3 / 3

Progressive Disclosure

The skill references three external files (references/nfr-checklist.md, references/sizing-thresholds.md, references/output-format.md) which is good progressive disclosure structure, but none of these files are provided in the bundle, making the references unverifiable. The main SKILL.md itself is monolithic — the red flags table, rationalizations table, and detailed Stage 3 branching logic could be split into reference files to reduce the main file's length.

2 / 3

Total

8

/

12

Passed

Description

89%Scale 1-3

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is a strong skill description with excellent trigger term coverage (including bilingual terms), clear 'when to use' and 'when not to use' guidance, and good distinctiveness through explicit exclusions. Its main weakness is that the capabilities described are somewhat abstract—it names domains (architecture, integrations, tech specs) rather than listing concrete actions the skill performs. The description is functional and well-structured for skill selection purposes.

Suggestions

Add more concrete action verbs describing what the skill produces, e.g., 'Produces architecture diagrams, evaluates technology tradeoffs, writes technical specifications, designs API contracts' rather than just naming domains.

DimensionReasoningScore

Specificity

The description names the domain (system architecture, integrations, tech specs) and some actions (designing, evolving), but doesn't list multiple concrete actions like 'create architecture diagrams, write tech specs, evaluate technology tradeoffs'. The actions remain somewhat abstract.

2 / 3

Completeness

Clearly answers both 'what' (designing system architecture, integrations, tech specs, technology choices) and 'when' (explicit 'Use when' clause plus 'Triggers include' list plus 'NOT for' exclusions). The explicit trigger guidance and negative boundaries are strong.

3 / 3

Trigger Term Quality

Excellent coverage of natural trigger terms in both English and Russian: 'design', 'architecture', 'how to build', 'integration', 'spec/ТЗ', 'спроектируй', 'архитектура', 'интеграция', 'как построить'. These are terms users would naturally use when requesting architectural help.

3 / 3

Distinctiveness Conflict Risk

Very distinctive with clear boundaries: explicitly excludes 'routine implementation, debugging, or code edits when no architectural decision is at stake' and clarifies its role relative to a knowledge-grounded design skill. The niche is well-defined and unlikely to conflict.

3 / 3

Total

11

/

12

Passed

Validation

100%

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

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
yushkevichv/awesome-system-design-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.