CtrlK
BlogDocsLog inGet started
Tessl Logo

review-frontend-races

Review a code change for frontend timing and lifecycle bugs, including listeners, timers, observers and async work that outlive their component, missing effect cleanup, Turbo/Stimulus/React lifecycle mistakes, overlapping interactions, and stale promise or animation work. Use when reviewing frontend code for race conditions, cleanup, or UI state consistency.

73

Quality

92%

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

SKILL.md
Quality
Evals
Security

Quality

Content

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

A tight, well-structured review-lens skill: every token encodes scope, method, decision threshold, or output format, with no concept over-explanation and no padding. The only meaningful gap is the absence of a worked example showing the method applied to a real diff and the resulting finding.

Suggestions

Add a short worked example in Method or Reporting: a small diff (e.g. an interval started in a Stimulus connect()) paired with the finding it should produce, demonstrating the report format end-to-end.

In Threshold, give one concrete counter-example of a reportable vs. non-reportable race (e.g. 'report: second click can start before the first fetch resolves; don't report: animation might theoretically stutter') to sharpen the boundary for borderline reviewers.

DimensionReasoningScore

Conciseness

The 39-line body is lean and assumes Claude's competence: it never explains what React, Turbo, or Stimulus are, and every sentence encodes a review rule or heuristic ('For each listener, timer, observer, script, or async call the change starts, find where it is stopped'). Stylized phrases like 'slightly hostile' and 'frontend superstition' are brief and carry real judgment meaning, not padding.

5 / 5

Actionability

Concrete, executable review procedures are given ('list the mutations performed before each return and confirm a matching cleanup exists on that path', 'Ask what happens when the user triggers the same interaction twice') plus concrete finding examples ('a `setInterval` with no `clearInterval` on disconnect'). It falls short of the top anchor only because no worked example — a diff plus the finding it should produce — demonstrates the method end-to-end.

4 / 5

Workflow Clarity

The Method is a clearly ordered procedure (enumerate resources, trace stop paths, audit useEffect exits, probe re-entrancy, check project rules), the Threshold section acts as an explicit validation gate against speculative findings, and Reporting defines the output. As a single-purpose, under-50-line skill with an unambiguous sequence, it meets the simple-skill exception; no destructive/batch cap applies.

5 / 5

Progressive Disclosure

The skill is self-contained with no bundle files (references/, scripts/, assets/ absent), under 50 lines, and organized into clear Scope / Method / Threshold / Reporting sections — meeting the rubric's exception that short, reference-free skills score 5 on well-organized sections alone. The AGENTS.md/CLAUDE.md mention is a runtime project-file instruction, not a bundle reference.

5 / 5

Total

19

/

20

Passed

Description

88%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 strong description that clearly states what the skill does and when to use it, with a comprehensive enumeration of the bug classes it covers. Trigger terms are good but miss a few natural synonyms (e.g. 'memory leak'), and the broad 'review a code change' opener creates slight overlap risk with general code-review skills.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete capability categories — 'listeners, timers, observers and async work that outlive their component, missing effect cleanup, Turbo/Stimulus/React lifecycle mistakes, overlapping interactions, and stale promise or animation work' — giving comprehensive coverage of the frontend race domain, matching the top anchor rather than the 'several actions with minor gaps' anchor below it.

5 / 5

Completeness

It explicitly answers both questions: the 'what' is 'Review a code change for frontend timing and lifecycle bugs, including...' and the 'when' is a concrete trigger clause — 'Use when reviewing frontend code for race conditions, cleanup, or UI state consistency.'

5 / 5

Trigger Term Quality

Good natural-term coverage ('race conditions', 'cleanup', 'lifecycle', 'UI state', 'timers', 'listeners', 'React', 'Turbo'), but common user phrasings like 'memory leak', 'event listener not removed', or 'double-click/duplicate request' are absent. It sits noticeably above anchor 3 ('some relevant keywords, missing variations') but short of anchor 5's comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

The niche (frontend timing/lifecycle races) is clear and mostly distinct, but the broad opener 'Review a code change' means it could be pulled in for any frontend code review, giving minor overlap risk with a general code-review skill — anchor 4 rather than 5's 'minimal conflict risk'.

4 / 5

Total

18

/

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
perihelionhq/perihelion-platform-context
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.