CtrlK
BlogDocsLog inGet started
Tessl Logo

clean-up-comments

Use when reviewing templates, rendered HTML, or shared components related to Remove comments and debug code in production. Validate the final browser-facing markup, not just the source framework abstraction.

56

Quality

63%

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/clean-up-comments/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

65%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 content is a lean, well-structured overview that correctly offloads detail to a real one-level reference, but it lacks executable specifics and any verification step for the destructive cleanup it directs. Adding a concrete validation checkpoint and tool-specific guidance would most improve it.

Suggestions

Add an explicit validation step after Fix (e.g., re-render the page and confirm no TODO/FIXME/DEBUG/console output remains and accessibility/legal comments are intact) to lift workflow clarity past the destructive-op cap.

Replace 'Configure build tools to strip comments automatically' with a concrete example (e.g., a Terser/PostHTML config snippet or a build flag) to raise actionability.

Include one short before/after HTML snippet inline so the Check/Fix sections are immediately executable without requiring the reference.

DimensionReasoningScore

Conciseness

The body is efficient: short sections, a four-bullet Quick Reference, and single-sentence Check/Fix/Explain/Code Review blocks with only a brief introductory rationale. It is below 5 because the opening sentence restates why cleanup matters (mild context Claude already knows) and above 3 because there is no significant padding or over-explanation.

4 / 5

Actionability

It names concrete targets (TODO/FIXME/DEBUG comments, console logs, accessibility/legal comments to keep) but provides no executable commands or code, and 'Configure build tools to strip comments automatically' is vague about which tools or how. It is below 4 due to missing execution specifics and above 2 because the targets are specific rather than purely abstract.

3 / 5

Workflow Clarity

A rough Check→Fix sequence is present via labeled sections, but there is no validation/verification checkpoint to confirm removal did not break markup or strip needed comments. Because removing comments/debug code is a batch/destructive operation, the rubric caps workflow clarity at 3 when validation is missing; it sits at 3 rather than 2 because the Check then Fix ordering is explicit.

3 / 5

Progressive Disclosure

The body is a concise overview with well-signaled one-level-deep navigation ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md'), and that reference file exists. It matches the anchor for a clear overview with appropriately split content and easy navigation.

5 / 5

Total

15

/

20

Passed

Description

62%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 well-formed with an explicit 'Use when' trigger and a clear what/when structure, but embeds the rule title awkwardly and leans on jargon ('source framework abstraction') that weakens trigger-term naturalness. Specificity and trigger coverage are adequate rather than comprehensive.

Suggestions

Reword 'related to Remove comments and debug code in production' into a natural clause (e.g., 'Use when reviewing rendered HTML for leftover comments, console logs, or debug code before production deployment') to improve trigger-term quality and specificity.

Add concrete action verbs beyond 'reviewing'/'validate' (e.g., 'strip', 'remove', 'flag') and natural synonyms users say to lift specificity and trigger coverage.

Replace 'source framework abstraction' with plain language to reduce jargon and broaden the natural keyword set.

DimensionReasoningScore

Specificity

The description names the domain ('templates, rendered HTML, or shared components') and two concrete actions ('reviewing' and 'Validate the final browser-facing markup'), but coverage is not comprehensive. It is below 4 because only two generic actions are given with no enumeration of distinct capabilities, and above 2 because at least two concrete actions are named rather than a single generic verb.

3 / 5

Completeness

It explicitly answers both 'what' (review/validate rendered HTML markup for comments and debug code) and 'when' via an explicit 'Use when reviewing templates, rendered HTML, or shared components...' clause, matching the anchor where both are present but the 'when' could be more specific. It is below 5 because the trigger guidance is somewhat generic and not above 4 because both halves are clearly present.

4 / 5

Trigger Term Quality

It includes relevant keywords users might say ('templates', 'rendered HTML', 'shared components', 'browser-facing markup') but relies on jargon like 'source framework abstraction' and misses common synonyms/variations a user would naturally utter. It is below 4 due to the missing natural variations and above 2 because several genuine domain terms are present.

3 / 5

Distinctiveness Conflict Risk

The niche (production HTML cleanup, validating browser-facing markup) is mostly distinct with minor overlap risk against general frontend-review skills. It is below 5 because 'reviewing templates, rendered HTML, or shared components' could overlap with adjacent HTML review skills, and above 3 because the rule focus on comments/debug code gives it a clear niche.

4 / 5

Total

14

/

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.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
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.