CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

modular-code-enforcement

Enforces strict modular code architecture: SRP, no monolithic index files, no catch-all utils, 200 LOC hard limit. This rule is NON-NEGOTIABLE. Violations BLOCK all further work until resolved.

Quality

70%

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 ./skills/modular-code-enforcement/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%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 well-structured and actionable with concrete rules, signals-to-actions tables, and clear numbered workflows including a verification checkpoint. Its main weaknesses are mild verbosity from repeated emphatic framing and the absence of an explicit feedback loop for repeated refactoring.

Suggestions

Tighten conciseness by collapsing repeated emphatic framing ('NON-NEGOTIABLE', 'SPLIT NOW') into a single stated posture and trimming the line-by-line LOC annotation.

Add an explicit validate->fix->retry feedback loop (e.g., 'if the file still exceeds 200 LOC after extraction, repeat the split until it passes') to strengthen workflow clarity for batch refactors.

Consider moving the detailed LOC-counting methodology into a references file, keeping SKILL.md as a concise overview with a one-level-deep pointer.

DimensionReasoningScore

Conciseness

Mostly efficient and free of basic-concept padding, but repetitive emphasis ('NON-NEGOTIABLE', 'SPLIT NOW' across multiple table rows) and the lengthy line-by-line LOC-counting example could be tightened.

3 / 5

Actionability

Concrete, specific guidance throughout: banned file names with refactor targets, a one-phrase self-test, a 200 LOC threshold, and an executable LOC-counting method with a worked example — only minor gaps for an instruction-only skill.

4 / 5

Workflow Clarity

Clear numbered sequences in Rule 4 (STOP/Identify/Extract/Verify/Resume) and 'How to Apply', with a 'Verify' checkpoint; the only gap is no explicit validate->fix->retry feedback loop for repeat refactors.

4 / 5

Progressive Disclosure

No bundle files exist; the skill is self-contained and well-organized into clear sections (Rule 1-4, How to Count LOC, How to Apply) with good navigation, though the detailed LOC-counting methodology could arguably live in a reference file.

4 / 5

Total

15

/

20

Passed

Description

58%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 is specific and distinct, clearly stating what the skill enforces, but it lacks an explicit 'Use when...' trigger clause which caps completeness. Trigger terms are relevant but somewhat jargon-heavy and miss natural synonyms.

Suggestions

Add an explicit 'Use when...' clause naming the situations that should trigger this skill (e.g., 'Use when creating or editing source files, reviewing code architecture, or refactoring large/catch-all files').

Expand trigger terms with natural synonyms users would actually say, such as 'single responsibility', 'split files', 'refactor monolithic code', and 'file size limit'.

Soften or clarify jargon like 'SRP' and 'LOC' so the description is readable to users who don't know the abbreviations.

DimensionReasoningScore

Specificity

Lists several concrete rules (SRP, no monolithic index files, no catch-all utils, 200 LOC hard limit) under the action verb 'Enforces', giving specific rather than vague coverage with only minor gaps.

4 / 5

Completeness

Has a clear 'what' (enforces modular code architecture with the listed rules) but no explicit 'when'/'Use when...' clause; per guidelines a missing trigger clause caps completeness at 3.

3 / 5

Trigger Term Quality

Relevant terms are present ('modular code architecture', 'monolithic index files', 'catch-all utils') but lean on jargon ('SRP', 'LOC') and omit natural variations a user might say like 'single responsibility' or 'split files'.

3 / 5

Distinctiveness Conflict Risk

The modular-code-enforcement niche is mostly distinct with specific triggers (200 LOC, monolithic index, catch-all utils), with only minor overlap risk against other general code-quality skills.

4 / 5

Total

14

/

20

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

ArabelaTso/Skills-4-SE

Path

skills/modular-code-enforcement/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.