CtrlK
BlogDocsLog inGet started
Tessl Logo

comment-checker

Use when Codex needs to understand or respond to automatic comment-checker feedback emitted after an edit-like PostToolUse hook.

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 ./packages/omo-codex/plugin/components/comment-checker/skills/comment-checker/SKILL.md

The canonical home for this skill is comment-checker in code-yeongyu/lazycodex

SKILL.md
Quality
Evals
Security

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.

The body is an exemplary lean overview: it states exactly what the plugin hooks, what the feedback means, and its boundary conditions in eight lines with no filler. Its only weakness is that the fix-or-explain directive lacks supporting detail — no example of the warning format or guidance on choosing between fixing and explaining.

DimensionReasoningScore

Conciseness

The body is 8 lines with zero padding: every sentence states a fact Codex could not infer (which tools are hooked, that feedback is blocking, the no-MCP/no-output edge cases). It assumes reader competence and matches anchor 5 ('lean and efficient; every token earns its place').

5 / 5

Actionability

The core directive — 'fix or explain the flagged comment before moving on' — is concrete behavioral guidance, but there are no examples of what the feedback looks like, what kinds of warnings occur, or how to structure an explanation. Per the code-vs-instruction note the absence of code is not penalized, yet the guidance stops short of being fully actionable, placing it between anchors 2 and 4.

3 / 5

Workflow Clarity

As a simple single-purpose skill under 50 lines the sequence is unambiguous (patch succeeds → warning fires → fix or explain → proceed), which would merit 5 under the simple-skill exception. It falls to 4 because 'fix or explain' leaves the decision point implicit — there is no guidance on when fixing is appropriate versus explaining.

4 / 5

Progressive Disclosure

The skill has no bundle files (references/, scripts/, assets/ are absent) and is under 50 lines, so per the rubric's guideline for simple skills, well-organized sections alone justify anchor 5. The '## Scope' section cleanly groups the edge cases and nothing that belongs in a separate file is inlined.

5 / 5

Total

17

/

20

Passed

Description

48%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 has an explicit, well-targeted 'Use when' trigger scoped to a distinct niche, but it never states what the skill concretely does — the actions ('understand or respond') are generic and no natural trigger synonyms are covered. It reads as a trigger clause without a capability statement.

Suggestions

Add a concrete 'what' clause naming the actual actions, e.g. 'Interpret comment-checker warnings after patch edits and fix or explain the flagged comment before proceeding.'

Broaden trigger terms with natural synonyms users would say, such as 'comment warnings', 'comment feedback', or 'comment lint results after an edit'.

Avoid vague verbs like 'understand or respond to' — replace with specific verbs (fix, explain, resolve) that describe observable behavior.

DimensionReasoningScore

Specificity

The description names its domain ("comment-checker feedback", "PostToolUse hook") but the only actions offered are the generic "understand or respond", which are not concrete. It fits anchor 2 ('names the domain but actions are minimal or generic') better than anchor 3, which requires 1-2 concrete actions such as 'fix the flagged comment' or 'explain the warning'.

2 / 5

Completeness

The 'when' is explicit ("Use when Codex needs to...") but the 'what' is only weakly stated — "understand or respond to... feedback" does not say what the skill actually does. This sits between anchor 2 (only 'when' present) and anchor 4 (both present with 'when' improvable); the vague 'what' pulls it to the midpoint.

3 / 5

Trigger Term Quality

Relevant keywords exist ("comment-checker", "feedback", "edit", "hook") but coverage is partial — missing natural variations users would say like 'comment warning', 'code comment lint', or 'comment feedback after a patch'. Not score 2, since more than one or two generic keywords are present; not 4, since common synonyms are absent.

3 / 5

Distinctiveness Conflict Risk

The niche is clear — 'comment-checker feedback emitted after an edit-like PostToolUse hook' is unlikely to trigger for unrelated skills. Not 5 because 'edit-like PostToolUse hook' is somewhat broad and could overlap with other edit/post-tool skills; not 3 because the core trigger term is distinctly branded.

4 / 5

Total

12

/

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
code-yeongyu/oh-my-openagent
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.