CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

node-inspect-debugger

Debug Node.js via --inspect + Chrome DevTools Protocol CLI.

54

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 ./skills/software-development/node-inspect-debugger/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%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 strong, dense, highly executable debugging guide whose real value is the non-obvious material: Hermes-specific attach flows, sourcemap/child-process/port pitfalls, and the verification checklist. Its weaknesses are structural: reference-grade content (REPL table, CDP driver, profiler recipes) is inlined in a ~300-line single file with no external references, and the REPL table plus one-shot recipes restate knowledge Claude already has.

Suggestions

Move the REPL command table, the full CDP driver script, and the heap/CPU-profile recipes into references/ files (e.g. references/repl-commands.md, references/cdp-driver.js) and keep SKILL.md as a lean overview with one-level-deep pointers.

Delete or compress the One-Shot Recipes section — it restates flows already covered by Quick Reference and Attaching sections — and trim the REPL table to only non-obvious commands (sb, repl, exec, watchers).

Fix the non-executable snippet detail: writeFileSync('~/...') does not expand '~' in Node — use os.homedir() or a literal path so the profile/snapshot recipes are copy-paste ready.

DimensionReasoningScore

Conciseness

The body is mostly lean commands and code with high-value non-obvious material (Hermes-specific attach flows, pitfalls, sourcemap warnings), but it includes unnecessary known-material padding: the ~25-line `debug>` REPL command table restates standard Node-documented commands Claude already knows, and the One-Shot Recipes section largely restates earlier flows. This fits 'mostly efficient but includes some unnecessary explanation or could be tightened' — not anchor 4, since the redundant material is more than minor.

3 / 5

Actionability

Nearly everything is concrete and executable: copy-paste bash (SIGUSR1 attach, pgrep/curl/jq WS-URL lookup, vitest single-file debug) and a complete CDP driver script covering the common scenarios. It falls short of fully copy-paste-ready anchor 5 on small gaps: `require('fs').writeFileSync('~/.hermes/...')` will not expand the tilde in Node fs, and `<uuid>`/`<hermes-agent-repo>` placeholders need manual substitution — 'concrete code or commands with minor gaps', i.e. anchor 4.

4 / 5

Workflow Clarity

Multi-step processes are clearly sequenced (numbered launch → SIGUSR1 → WS-URL → attach; build → inspect-brk → sb/cont → repl), and the Verification Checklist plus pitfall-driven recovery ('if the first breakpoint doesn't hit, you likely missed --inspect-brk') provide real validation and feedback loops. Not anchor 5 because validation sits in an end-of-file checklist rather than being integrated into each workflow, and the vitest/heap-snapshot workflows carry no verification steps; no destructive/batch cap applies since operations are read-only debugging.

4 / 5

Progressive Disclosure

No bundle files exist (no references/, scripts/, assets/); the entire skill is a single ~300-line file. Internal section headers are good, but reference-grade material that clearly belongs in separate files — the REPL command table, the full CDP driver script, and the heap/CPU-profile recipes — is inlined in SKILL.md. This matches 'some structure but... content that should be separate is inline' (anchor 3); it is not anchor 2 since the sections are well-organized and navigable, and the under-50-line exception does not apply.

3 / 5

Total

14

/

20

Passed

Description

61%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 tight, specific one-liner that clearly names the niche and tooling, but it is a 'what'-only description: it lists a single broad capability and omits any explicit 'use when' guidance or common trigger synonyms like 'breakpoints' or 'step through'. Adding a 'when' clause and one or two concrete capabilities would lift it substantially.

Suggestions

Add an explicit trigger clause, e.g. 'Use when a Node.js test or process fails and console.log is insufficient, or when the user mentions breakpoints, stepping, or inspecting a running Node process.'

Enumerate 2-3 concrete capabilities instead of the single verb 'Debug', e.g. 'set breakpoints, step through code, inspect paused-frame and closure scope, capture CPU/heap profiles in Node.js via --inspect + Chrome DevTools Protocol CLI.'

Include natural synonyms users say — 'breakpoints', 'step through', 'debugger', 'paused frame' — to improve trigger matching.

DimensionReasoningScore

Specificity

The description names the domain ('Debug Node.js') and concrete tooling ('--inspect', 'Chrome DevTools Protocol CLI'), but enumerates only one broad action rather than several specific capabilities (breakpoints, stepping, scope inspection). It matches the anchor for 1-2 concrete actions without comprehensive coverage — not anchor 4, which requires several listed actions, nor anchor 2, whose actions are generic with no concrete mechanism.

3 / 5

Completeness

It clearly answers 'what' (debug Node.js via --inspect/CDP from the CLI) but contains no 'Use when...' clause or equivalent explicit trigger guidance, so completeness is capped at 3 per the rubric guideline. It is not a 2 because the 'what' is concrete and specific, not vague.

3 / 5

Trigger Term Quality

'Debug', 'Node.js', 'inspect', and 'Chrome DevTools Protocol' are natural phrases a user would say when needing this skill, giving good keyword coverage. Common variations users actually say — 'breakpoints', 'step through', 'debugger', 'paused' — are missing, which keeps it below the comprehensive-synonym coverage of anchor 5 but above the thin keyword set of anchor 3.

4 / 5

Distinctiveness Conflict Risk

The trigger terms ('Node.js', '--inspect', 'Chrome DevTools Protocol') carve out a clear niche that would not fire for PDF, git, or docx skills, and only minor overlap risk exists with closely related general-debugging skills. It falls short of anchor 5 only because 'debug Node.js' could still collide with a sibling JS-debugging skill and no 'use when' scoping distinguishes it.

4 / 5

Total

14

/

20

Passed

Validation

81%

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

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

13

/

16

Passed

Repository

NousResearch/hermes-agent

Path

skills/software-development/node-inspect-debugger/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.